How to Build an MVP in 30 days Without Blowing Your Budget
How to Build an MVP in 30 days Without Blowing Your Budget

How to Build an MVP in 30 days Without Blowing Your Budget

Learn how to efficiently build a minimum viable product (MVP) in just 30 days while keeping costs low.

A while ago I’ve built Expensio, a self-hosted web application that helps people track their expenses. I was on a “self-hosted is the future” bandwagon back then.

I’ve built it in weekends and it took me about two months. I credit my speediness to a few things:

AI-powered engineering

I see two camps in software engineers regarding this. Some, like me, say AI-powered engineering is the way to go and it’s invaluable. Some argue AI is a crutch and it doesn’t work for XYZ purpose.

I’ll be the first to agree current LLMs are not good at *everything*. But they are pretty damn good at making me code faster.

I think the core problem of the people that are against it simply do not know how to use it. There are interesting prompt engineering techniques you can use.

And for when the LLM simply doesn’t know the tech you are working with. There are ways (like RAG) to fix that. I particularly like what RunLLM is doing in terms of chatbots for docs. But I also love what FastHTML did for their framework to help you add their docs within Cursor.

Cursor, if you haven’t tried it, is a wrapper on the usual LLMs (Claude, GPT). It’s an optimization on how you bridge code <> thoughts <> LLM. And it makes you observably faster vs just using the web UIs that the LLMs come with.

More people say this now than a few months ago… But, honestly, if your engineers do not use AI in any capacity? You are NOT GOING TO MAKE IT.

Clearly defined scope

Clearly defined scope

I’ve talked about my software development philosophy before, but here are a few key points.

Cut scope! Starting with a small, well-defined scope is key. Call it an MVP, prototype, PoC, MLP (Minimum Lovable Product) or whatever you want. Just make it small, build a working version and get it in front of users.

This allows you to figure out the technical unkown unknowns you couldn’t have figured out from a design doc.

It also allows you to get real user feedback which is invaluable for informing future iterations and improvements.

Sometimes, it also allows you to quickly & cheaply disqualify the idea if you see 0 interest or if you learn it’s just not what you want to build.

And, it lends itself as a great trial when hiring a new freelancer that you haven’t yet worked with (like me).

My custom self-hosted focused framework (ez-go)

My custom self-hosted focused framework (ez-go)

What’s better then writing code faster? Well, I’ve alluded to this in “clearly defined scope” but *writing less code* is what’s better.

Frameworks are not a new thing. We have a lot of them out there, each specialized to their own situation and trade-offs. Knowing when to use one or the other is imperative (which is why I like to be T-shaped as an engineer).

When it comes to an AI-powered application, I like to go with Python and FastHTML because of its extensive ecosystem regarding ML/AI. Even multi-language libraries like LlamaIndex are just better featured in Python than in other languages.

In the case of Expensio, it being a self-hosted application, I went for Go (lang). Why? Because it can easily compile into one single cross-platform binary. See? You really have to know when to use what.

Conclusion

Conclusion

It’s not easy to build an MVP in 30 days without blowing your budget. Definitely not easy.

But with the right system, and the right people, in place you can do it.

A bit of shameless self-promotion. If you like what I’m yapping on here, and feel like I could be of help with your product… I offer development and consulting services, just check out the landing page for more details.

More posts you might like

When to build an AI product

When to build an AI product

Pre-maturely building software of any kind is a waste of time and money. Here's how to know when it makes sense.

On latency and how it affects architecture

On latency and how it affects architecture

Serverless tends to push the 'edge' paradigm. The app server lives close to the user to save latency. But it's problematic if you have a database because, generally, you will have multiple db queries for each page / API request. Let's talk about that