The question, on one page
A written statement of what this build is meant to prove, what result counts as a yes, and what result counts as a no.
Web apps
Find out if it works before you build all of it
One real question, one narrow build, one straight answer. We put the shortest usable version in front of actual users so the decision to go further is made on evidence rather than on how much has already been spent.
Who this is for
For founders and product teams who need evidence before committing a full budget. If you already know exactly what you need and simply want it built well, skip this and go straight to a full application build.
What you get
What we deliver
A scope with an out list
The shortest set of screens that can answer the question, plus an explicit list of what is deliberately not being built, so nothing looks forgotten.
A working build, not a clickable mockup
Something real people can use on their own phone with their own data, deployed somewhere you can send a link to.
Instrumentation from the first day
Events on the handful of actions that matter, so the answer comes from what people did rather than what they said in a call.
A way to get the first users in
A short plan for the first group, whether that is a Facebook group, a Viber community, a list you already own or a room you already stand in front of.
An honest read at the end
A write-up of what the build showed, including the case where the answer is no and the recommendation is to stop.
Finding the first users, and the paperwork behind the payments
A first version here rarely finds users through a launch page. It finds them in a Facebook group, a Viber community, an alumni or industry chat, or a room somebody on your team already speaks in front of, and those channels reward a link you can send with one sentence of explanation. So the build has to survive being opened cold by a stranger with no onboarding call, and the recruitment plan is part of the scope, not an afterthought. The other local timing trap is paperwork. If the question is whether people will pay, the build needs a real gateway, and gateway onboarding asks for your SEC or DTI registration, your business permits and a review that runs on their calendar, not yours. We start that in the first week, because a finished MVP waiting on merchant approval is a test that has not begun.
Questions
What people ask before they buy this
What is the difference between a prototype and an MVP?
A prototype is clickable and fake, and it tests whether people understand the idea. An MVP is real and narrow, and it tests whether they will use it or pay for it, because the thing genuinely works. Which one you need depends on the question you are asking, and choosing the cheaper one is often the right answer.
What happens to the code if it works?
It carries on. We build the first version as a small real application, not a throwaway, so the parts that were validated get extended instead of rewritten. What we deliberately do not do is engineer for a scale you have not proved you need, which means some pieces are meant to be replaced later. We tell you which ones those are at handover, so the decision is yours and not a surprise.
Can an MVP take payments here?
Yes, and if willingness to pay is the question then it has to, because a free signup measures curiosity rather than demand. The methods matter: a card-only checkout tests who owns a card, not who wants the product. What usually decides the launch date is not the code but the merchant approval, which is why the gateway application goes in at the start of the build.
How do we know the scope is small enough?
If you cannot say in one sentence what the build is meant to prove, it is not scoped yet. We write that sentence first and cut everything that does not serve it. The cut items go on a written list, so the team can see they were a decision and not an oversight, and so the obvious second version is already half planned.
What if the answer comes back no?
Then you have that answer for the cost of a small build instead of a full one, and it gets said plainly rather than dressed up as a case for phase two. A clear no is a legitimate result and often the most useful one, because it frees the budget for the next question. The closing write-up covers what the build showed either way.
Web apps
Related services
Ready when you are
Tell us what you are building and we will tell you honestly how we would approach it.