About Us

LabFolio is a 501(c)(3) non-profit dedicated to advancing scientific productivity. After you sign up and connect your tools — like reference managers, coding environments, and writing software — we automatically organize your work project-by-project, making your research easily portable and shareable. In practice, this means you can automate a lot of busywork to organize, synchronize, and share your work with others. Finally, when you publish you can share your research log alongside your manuscript, helping with reproducibility and the study of metascience.

FAQs

1. What problem are you trying to solve?

Today, scientific tools are mostly unconnected, making it difficult for scientists to organize, sync, and share their work across the research lifecycle.  For example, a typical computer scientist’s workflow might involve:

• Conducting a literature review using Mendeley, or Zotero
• Writing down early experiment designs in Microsoft Word
• Sharing those Word documents to coauthors with Dropbox, Sharepoint, or Google Drive
• Conducting small-scale experiments with Python code on a local machine
• Sharing experimental code with coauthors using Github
• Running large-scale experiments in Java on their university’s cluster
• Writing up results in Overleaf

The basic problem is that the tools in these various steps do not all talk to each other, leaving the scientist with a lot of manual work to keep their projects organized, synchronized, and shareable.

First, it is difficult to keep the project organized because there is no connective tissue between the files in each step: the scientist has to keep track of where every relevant file is located (e.g. 3P cloud server vs. local vs. university cluster vs. another 3P cloud server), which files represent the latest version of the work, and distinguish between multiple projects in each filesystem.  More advanced tasks like reverting a project to an earlier state (e.g. last month’s literature review, code, and paper) are practically beyond reach.

Second, it is difficult to synchronize work across tools because for every minor change in one tool, the scientist has to manually update files in several places.  For example, suppose that “Figure 4” is a graph in a research paper on Overleaf, and stems from Python code run on a local machine; as the scientist incrementally runs slightly different versions of the code on their local machine, they have to manually copy the file over to Overleaf’s cloud-storage, and ensure that “Figure 4” refers to the latest copy/pasted .jpg.  Synchronization involving natural language text is significantly more difficult, e.g., a scientist might change their intended experiment design in a Word document from “infinite horizon” to “finite horizon,” which then requires changes on a specific line of code in Python, and also requires updates to the experiment description in Overleaf.

Third, it is difficult to share the state of a given project with coauthors, advisors, grant makers, or other stakeholders, because scientists have to manually aggregate information from several different file types and systems.  For example, PhD students might check-in quarterly with their advisors about progress on their thesis; or PIs might biannually submit status updates to grant makers.  Doing so however takes more manual work than just sharing an existing artifact, as the scientist has to summarize progress made across the literature review, experiment design, experiment execution, and paper writing itself.  Sharing progress updates at a more frequent cadence (e.g. weekly) with coauthors or lab managers tends to be conducted verbally, if at all, and is likely to miss details because the information is scattered.

In addition to this set of problems faced by scientists and labs, the scattered and siloed data also limits formal study by metascience researchers (typically either academic economists, or sociologists), who want to better understand how labs run day-to-day, and how we can improve them over time.  At present, most metascience research relies on completed research publication data, or patent data, since these are well-structured and widely available.  However, very few studies address the day-to-day activities of scientists or labs, given the fragmented and private nature of these data.  Consequently, science today has very little to say about how scientists themselves can better do their work, or how labs can operate to greater effect.

2. At a high level, how do you plan to solve this problem?

We build research portfolios on behalf of scientists, connecting up all of their existing tooling (like Zotero, Overleaf, or GitHub) with a shared backend.  Scientists can then plug their research portfolios back into the tools they use, enabling simple but useful automations

We visualize the flow of data in the figure below, which illustrates how different parts of a scientist’s workflow can add metadata to their portfolio, use the aggregated metadata to power new applications/tools, or do both:

Note that the portfolio itself is a non-functional, backend database – scientists will only interact with applications built on top of their portfolios.  For example, by linking a code repository like GitHub with a LaTeX editor like Overleaf, scientists can automatically sync their latest experimental results with figures/plots/tables in their paper.  By linking together even more of their tools, scientists can create a comprehensive picture of their ongoing work, helping entire labs stay on the same page (e.g., with automated weekly summaries, suggested next tasks, etc.).   

Finally, we will work with publishers like arXiv to allow scientists to publish portfolio data alongside manuscripts, to help with reproducibility and so that academic metascience researchers can more easily study how labs run today, and how they can improve in the future.

3. How do you plan to make this financially sustainable?

While we are relying on grants to fund early development, our long-term plan is to expose a paid API/MCP endpoint/server to 3P developers who want to build new features and applications for scientists using the organized data from a given scientist’s portfolio (and conditional on that scientist’s permission to do so, via the normal API auth process).  In this way, we can cover the costs of developing, maintaining, and running the infrastructure as it scales with usage.

4. Why not charge individual scientists directly for the portfolio manager service?

The portfolio manager itself does not hold any value, only the 3P applications built on top of the portfolio deliver value to scientists. In order to maintain a stable price for users, we would naturally either overcharge them (as users’ dollars would go to fund integrations for applications they don’t use), or undercharge them (as we wouldn’t want to keep increasing the price as more and more 3P applications become available).  Instead, by running a paid API to the 3P developers themselves, we can cover the costs of the service in exact proportion to the value being delivered to end-users.

5. Why operate as a non-profit, rather than a for-profit?

Our mission is to advance scientific productivity in the public interest, not to maximize profit for personal gain.  We can already foresee multiple strategic forks where profit maximization would be incompatible with our public service mission.  First, we are designing our architecture from the start to be open-source rather than proprietary, to align with core principles of scientific openness and to ensure LabFolio’s specific implementation does not become a single point of failure for the scientific community.  Second, one of our core goals is to make scientists’ portfolio data public for study by academic metascience researchers, conditional on scientist consent.  Third, we will explore decentralizing our architecture over time as edge computing costs decline, such that individual scientists can create their own portfolios on their local machines rather than rely on LabFolio’s centralized infrastructure – in effect allowing us to sunset the organization.  In each case, the logic of our mission compels us to take these strategic actions, but the logic of profit maximization would require that we don’t.  Consequently, we are trying to align our organizational structure with our mission to guard against mission-drift.

6. Why haven’t these tools (e.g., Overleaf, GitHub, etc.) already integrated with each other?

To a limited extent, some of them have already integrated 1:1 – for example, Overleaf has 1:1 integrations with Zotero, Dropbox, and GitHub.  However, there are two ways in which an open-source portfolio manager will add value to this existing ecosystem: (1) The basic task performed by the portfolio manager, which is to distinguish which files belong to which project, across tools (which usually host multiple projects at once), gets more accurate with more integrations – today, existing 1:1 integrations require users to manually identify which files belong to which project, in each system, (2) The standardization of the portfolio management layer reduces the integration complexity from O(n^2) to O(n).  Consequently, we believe that such a portfolio manager will enable more scientific tools to achieve the benefit of integration with each other, and work seamlessly together in a way that they do not today.

7. Who is involved with this project?

Our board of directors is currently comprised of five people: Jordan Bell-Masterson, Siyi Gu, Neil Lawrence, Abby Stevens, and Bharathan Balaji. Jordan and Siyi are working on LabFolio full-time, as of January 2026; Jordan is the operational lead, and Siyi is the technical lead.