Building the first version of your software product (MVP) without overspending

You have an idea for a software product. Maybe it is a tool for coaching centres, a booking system for clinics, or software you built for your own business that others now want to use. The fear is familiar: you spend months and a large part of your budget, the product stays "almost ready" for a long time, and when it finally launches, users want something different.

An MVP (minimum viable product) is the smallest version that solves one real problem for one kind of user well enough that they will use it, and ideally pay for it. Its job is to show you what to build next, not to be complete.

Decide what version one is for

Before talking to any developer, write one page that answers four questions:

• Who is the first user? Be narrow. "Owners of small coaching centres in district towns" is better than "educational institutions".
• What one job does the product do for them? For example, "record monthly fees and remind guardians when a payment is due".
• How do they do it today? A notebook, Excel, a Facebook group, WhatsApp messages. Your product must be clearly better than that, not just more modern.
• How will you know it worked? Users come back every week, a few agree to pay, or they start asking for the next feature.

Then talk to five to ten of those people before anything is built. Show them a rough sketch or a clickable mock-up. Their reactions cost far less to collect than code.

Cut the scope until it feels uncomfortable

1. List every feature you imagine.
2. Mark each one "must have for the first users", "later" or "nice to have".
3. Move part of the "must have" list to "later" anyway. For each item, ask whether you could do it by hand for the first users.
4. Keep to one user role if you can. Admin panels, several permission levels and detailed reports can usually wait.
5. Start with a web app that works well in a mobile browser, on an average phone and patchy mobile data, instead of separate Android and iOS apps.
6. Use existing services for login, email, SMS and payments rather than building your own.

Doing some work manually behind the scenes is not cheating. If setting up a new customer takes you an hour by hand, that is fine for the first ten customers, and it teaches you exactly what is worth automating.

Protect yourself during the build

• Own everything. The domain, hosting account, code repository and any app store accounts should be in your business's name, with the developer given access, not the other way round.
• Build in short milestones. Agree on a small piece, see it working, then agree on the next. Avoid one large contract where you see nothing usable until the end.
• Choose common, well-supported technology so another developer can take over if needed. The newest framework is rarely the cheapest to maintain.
• Ask for the basics that are hard to add later: regular backups, secure password handling and a way to export your users' data.
• Decide the language early. If your users are more comfortable in Bangla, plan a Bangla interface from the start. Adding it later touches every screen.

Where the money usually leaks

The most common waste is building for imagined users: features nobody asked for, polished design before anyone has used the product, and rebuilding because the first developer left without handing over the code. The second is never launching, because there is always one more feature to add first.

Your part and the developer's part

You own the problem, the users and the priorities. Nobody else can talk to your customers for you or decide what matters most. A good developer owns the architecture, security and data structure, and should push back when a feature costs a lot for little gain. If you have no technical person on your side, an experienced developer can also help you write the brief and compare quotes before you commit. You can read how I approach software and website development.

The smallest useful first step

Write the one-page brief above this week and show it to three potential users. If their answers change the brief, you have just saved money. Once the brief stops changing, get in touch and we can turn it into a build plan.