MVP Development: Start Small So the Second Version Is Worth Building

Someone has told you to build an MVP, and what they mean is: spend less before you know whether the software is worth having. That instinct is right, and it only pays off if the small version reaches the people who do the work, because their behaviour is the evidence you are buying.

The worry underneath the advice is usually money. Starting small costs more than one big build when the first version gets thrown away, which happens when it was a demo rather than something anyone could use, or when the code and accounts sat with a vendor you stopped working with. Keep the scope real and the ownership yours, and the second version continues from the first.

What a first version is supposed to answer

Pick one process and one group of people, put software in front of them, and see what happens to the work. Do the bookings still get double-entered? Does the person who knows the pricing rules still get called every afternoon? Those answers are worth more than any estimate of what the finished system might do.

Scope that covers one process from beginning to end gets used daily, and daily use is the only honest evidence available to you. Scope that covers several processes thinly leaves gaps in each of them, and your team keeps the old spreadsheet open next to the new software, which tells you nothing except that the build was too wide. A narrow first version done properly becomes a working part of the business, while a broad one done badly is an expensive opinion.

Picking the one process that hurts most

Choose scope from what goes wrong, not from a wishlist. The wishlist is written by everyone who was in the room and ranked by how loudly each person spoke, while what goes wrong is ranked by how often it happens and what it costs when it does.

Look for the spreadsheet that breaks when two people edit it in the same hour, or the step only one person understands, so nothing moves while they are on leave. A request that arrives by WhatsApp on a Friday and is found again on Wednesday, after the customer has followed up twice, belongs on the same list, and so does the number in the report that nobody fully trusts, the one a manager rebuilds by hand before every meeting.

One of those costs more than the others, and the operations lead can usually name it in a sentence, which makes it the first version. Everything else goes into the plan as a later stage, written down so it is not lost, and left alone until the first version has been in use long enough for people to have an opinion about it.

What gets cut, and what never does

Cut the admin screens and configure things directly for now. Cut the settings page nobody will open. Cut the second user type, the rare cases that can be handled by hand, the dashboard that summarises data you have not collected yet, and the notification rules that will be rewritten once people see how the work actually flows.

What survives every cut is narrower and less negotiable:

• Data that is correct, because wrong data burns trust faster than a missing feature.
• Access control, so the people who should not see salaries or margins do not see them.
• Export, so everything in the system can come back out in a format you can read without us.

A first version can look plain, but it cannot be a mock-up running in production, because the moment your team notices that half the buttons do nothing, they go back to the spreadsheet and you have learned nothing.

Costing it before you commit to it

Discovery is the first stage, it takes one to two weeks, and it produces a written plan with a fixed price. That plan is yours whether or not you continue, which means the cost of finding out what this would take is small and bounded, and you can take the document to anyone.

Every stage after discovery is priced and agreed in writing before it begins. You can stop after any of them without an argument, because there is nothing to argue about: the next stage was never signed. The decision to keep going then gets made with working software already in your hands and your team's reaction to it on record, rather than with a proposal and a hope. If you want the full sequence of stages that follows discovery, we have written it up in our end to end approach from idea to launch.

Watching it get built instead of waiting for the reveal

You get working software every week and a private preview link from week one. The link is live that early so you can catch a wrong assumption while it is still a week old.

Only the people who wrote a specification read it. Software gets opened by the person who has to use it, and an operations lead who opens a half-built booking screen will say straight away that two of those fields are never known at the time of booking. Fixing that in week two is cheap. The same correction after handover means rebuilding everything downstream of it.

Weekly demos also keep scope drift visible. When the work starts drifting towards something nobody asked for, you see it in the demo and say so, instead of finding it in an invoice.

Why ownership matters more on a small build than a large one

A first version is exactly where being stranded is most likely, because it is the point where either side might walk away. It is also where being stranded hurts most, since you have a half-finished asset and no way to continue it.

The code, the servers, the domain and every account are in your name from day one. Nothing about the second version depends on us continuing. If your own developer wants to extend it, they can, and if you want to hand it to another studio, you can do that without asking us for anything. Day one ownership is worth checking with any studio you talk to, because "we'll transfer everything at handover" and "it is already yours" behave very differently on the day you want to leave.

Deciding what happens after version one

There are three honest outcomes, and only one of them involves building more. You extend it, because the process improved and the next process in the queue is now obvious. The second is that you stop, because the software did what it needed to do and the rest of the wishlist turned out to be wishful. Or the assumption underneath the build was wrong, in which case you change the assumption and price a small stage to test the new one, having spent one stage to learn it rather than a whole budget.

A fourth outcome shows up during discovery rather than after the build. Sometimes the process you described is already solved by a tool you can buy, and we will say so instead of quoting you a first version of it. That conversation is short, and the comparison between custom and off the shelf software covers where the line usually falls. If you are weighing the whole commission rather than just the first stage, our guide to commissioning custom software covers what the rest of it involves.

Start with the plan, not the build

Book a first call. There is no deck, and the conversation is about the process that is costing you the most right now. If custom software is the wrong answer, you will hear that on the call.

If it is the right answer, discovery gives you a written plan and a fixed price for a first version within one to two weeks, and that document is yours to keep either way. Use the contact form, which opens WhatsApp, or email hello@arktik.id.