About the Project
We built this project to help answer one of the most important questions for any startup: how long can we survive before we run out of money? Early-stage teams often make decisions quickly, but without a clear picture of burn, growth, and risk, it is easy to underestimate how fragile runway can be. That problem inspired us to create a tool that turns basic financial inputs into a forward-looking view of a startup's cash health.
At its core, the project calculates a startup's burn rate and uses it to estimate runway. In simple terms:
$$ \text{Burn Rate} = \text{Monthly Expenses} - \text{Monthly Revenue} $$
and
$$ \text{Runway (months)} = \frac{\text{Cash on Hand}}{\text{Burn Rate}} $$
But real startups are rarely that simple. Expenses change, revenue grows unevenly, and major projects can increase risk. To capture that uncertainty, we built a simulation-based system that models multiple future cash paths instead of relying on a single fixed estimate. This gives users a more realistic picture of what might happen under different scenarios.
What Inspired Us
The inspiration came from how uncertain startup planning can be. Founders often know their current cash balance, but not the real effect of future spending, delayed revenue, or new projects. We wanted to build something that goes beyond a static spreadsheet and instead helps teams explore questions like:
- What happens if expenses grow faster than expected?
- How much does a new project reduce runway?
- When should we raise funding before the risk becomes too high?
That pushed us toward building a tool focused not just on calculation, but on decision support.
How We Built It
We built the project as a full-stack application:
- A FastAPI backend powers the financial simulation and exposes APIs for runway analysis and scenario comparison.
- A Next.js frontend provides an interactive interface where users can enter startup data, adjust assumptions, and visualize results.
- We used Monte Carlo simulation to generate many possible cash outcomes over time, which helps estimate uncertainty instead of just one deterministic number.
- The system also includes policy logic to recommend when a startup should consider raising funds based on risk thresholds.
This structure let us separate the analytical engine from the user interface, making the project easier to test, extend, and present.
Challenges We Faced
One of the biggest challenges was balancing simplicity with realism. A basic runway formula is easy to understand, but it is too limited for real startup behavior. Once we introduced changing expenses, revenue growth, and project-level costs, the logic became much more complex.
Another challenge was modeling uncertainty in a way that is useful, not overwhelming. We wanted the simulation to feel data-driven and practical, while still being understandable to someone without a finance background. That meant thinking carefully about how to present results such as median outcomes, risk curves, and scenario comparisons in a way that supports fast decision-making.
We also had to make sure the frontend and backend worked smoothly together, especially when sending simulation inputs and rendering results clearly.
What We Learned
This project taught us a lot about both engineering and product thinking:
- How to turn a financial concept into a working simulation engine
- How to design APIs that support analytical workflows
- How to communicate uncertainty through clear visual outputs
- How important it is to make technically complex tools feel intuitive for end users
More broadly, we learned that startup finance is not just about tracking numbers, it is about understanding risk early enough to act on it.
Why It Matters
This project matters because it gives startup teams a clearer way to plan ahead. Instead of guessing how long their cash will last, they can model possible futures, compare decisions, and act earlier. In short, it helps transform burn rate from a simple metric into a smarter planning tool.
Built With
- and-numpy-power-the-backend-simulation-engine
- and-pytest-plus-ruff-for-testing
- and-tailwind-css-drive-the-frontend-experience.-we-used-recharts-for-data-visualization
- fastapi
- formatting
- next.js
- numpy
- python
- react
- recharts
- tailwind
- typescript
- uvicorn
- uvicorn-to-serve-the-api
- while-next.js
Log in or sign up for Devpost to join the conversation.