Burn Budgeter

• 

  Project documentation

Inspiration

The fastest way for a startup to die isn't a bad product; it's a surprise cloud bill. Developers are moving fast, spinning up EC2 instances, deploying AI models, and utilizing heavy infrastructure, but the financial observability usually comes as an afterthought. I wanted to bridge the gap between software engineering and financial ratio analysis by treating infrastructure burn rate as a real-time, queryable metric rather than an end-of-month surprise.

What it does

Burn Budgeter is a public, zero-friction API that delivers immediate financial observability. Instead of forcing teams to log into multiple complex billing consoles or wrestling with bloated JavaScript frontend dashboards, we provide raw, clean JSON data. Developers can pipe this directly into their CI/CD pipelines, automated Slack alerts, or custom minimalist interfaces.

It calculates real-time burn, daily averages, and projected runway. The core logic relies on tracking the change in cost over time: $$\text{Burn Rate }(B) = \frac{\Delta C}{\Delta t}$$

And forecasting the remaining runway based on current available capital (\(S\)) and the daily burn rate (\(B\)):$$\text{Runway }(R) = \frac{S_{current}}{B_{daily}}$$

How I built it

I took a backend-first approach, starting by carefully selecting the tech stack and defining the project architecture. I focused on a minimalist, highly efficient setup, opting to build the core logic in Go to ensure fast execution. Once the architecture was locked in, I wrote and iterated on a rigorous project specification.

Instead of manually typing every line of boilerplate, I used GeminiCLI to handle the bulk of the raw coding. My role shifted completely to lead architect—I spent my time doing extensive code review, providing strategic guidance to the AI, and refining the system design. Finally, I containerized the application and deployed it directly to Google Cloud Run, allowing it to scale from zero and handle incoming HTTP requests effortlessly.

Challenges I ran into

Designing a frictionless, public API that remains secure and performant is a delicate balance. Additionally, standardizing the financial data—translating varied cloud provider billing metrics into a single, unified JSON schema—required careful architectural planning.

Accomplishments that I'm proud of

Accomplishments that I'm proud of Shipping a fully working and hosted API within the short hackathon timeframe is my biggest win. I am also extremely proud of the developer experience: the documentation is built to the OpenAPI standard, looks incredibly clean, and allows users to test the API directly within the docs themselves.

What I learned

I gained deep hands-on experience in building and shipping a production-ready API under strict time constraints. It reinforced the value of a minimalist tech stack, strong project scoping, and the power of deploying containers to serverless environments like Cloud Run for maximum efficiency.

What's next for Burn Budgeter

I see immense real-world potential for this API, especially as startups increasingly diversify their infrastructure across multiple AI providers and distributed hosting platforms. Moving forward, I plan to continue development by architecting a secure authentication system to support enterprise-grade use cases. Additionally, I will focus on expanding the API's integrations to natively track and support an even wider array of cloud services, platforms, and LLM providers.

Built With

• gemini
• go
• google-cloud-run
• supabase