How do you build an MVP on a small budget?

Pick one user, one problem and the shortest path that solves it. Build only that, in the simplest technology that works, and put it in front of real people quickly. The budget is saved by what you deliberately leave out.

By Nazar Kashuba · Reviewed

An MVP is not a bad version of the finished product. It is the smallest thing that can show whether the idea is worth building further. Budget problems usually come from treating it as a finished product with fewer polish passes.

A sensible way to scope it

  1. One person. Who exactly is this for? If the answer is “everyone”, narrow it.
  2. One problem. What do they struggle with today, and how do they cope without you?
  3. One path. The shortest sequence of steps from their problem to a solved one.
  4. Everything else on a later list. Settings, multiple roles, polished reporting, extra integrations: write them down and park them.

Where the savings really are

  • Use existing services for solved problems such as payments, email delivery and sign-in, rather than building your own.
  • Do manually behind the scenes what you can: if invoices are sent by you at first, you do not need invoice automation yet.
  • Choose boring, well-known technology that someone else can take over.
  • Skip native mobile apps unless the idea depends on them; a responsive web app can test the same idea.

Where not to cut

Security basics, backups, and correct handling of the data you collect. A cheap MVP that loses or exposes user data ends the project. Keep the scope small, not the care.

Finally, decide in advance what you will learn and what result would make you continue, change direction or stop. An MVP without a question to answer is just a smaller project.

All questions