MVP development
MVP development is a working version of a product built small, made for one purpose: to test demand on real people rather than in a presentation. Finding out in a few weeks that the hypothesis does not work is cheaper than finding out after a year of full development.
An MVP is not a stripped-down product and not a cheap version of a good one. It is the shortest working chain that answers one main question. Usually the question is whether people will use this and whether they will pay. Everything that does not help get that answer is taken out of the first version, even if it will obviously be needed later.
Cutting the unnecessary is the main body of the work. A client usually arrives with a list of thirty features, every one of which seems essential. We work through which of them test the hypothesis and which merely postpone the moment of truth. Usually five out of thirty remain, and that is the most useful part of the project.
The answer an MVP brings can be negative, and we deliver that answer too. It is unpleasant, but it costs one small version of a product rather than a year of development and a launch nobody was waiting for. Sometimes the result is a third thing: the hypothesis was not confirmed, but conversations with people surfaced a different one. That is how SignItNow came about. We ran the technical side of an advertising campaign together with the client marketing director, talked to entrepreneurs, and from those conversations it turned out that notarising a document and signing a document are different needs, and nobody was covering the second. The product grew from there rather than from somebody else hypothesis.
And separately about quality. The word minimal refers to the scope, not to how the code is written. We do not build an MVP that has to be thrown away whole: the architecture is set up so that a successful version can be developed further. If we deliberately write part of it to be discarded for the sake of speed, we say so in advance and explain what it will mean later.
Before an MVP it makes sense to build a prototype: it is cheaper and removes some of the questions before development. After that come design, web development or a mobile app and the backend, and once the first version confirms demand the product turns into a full online service. If the question is broader still and sounds like whether to take this on at all, start with business consulting.
What the service covers
Any combination of the items below can be taken on its own.
What exactly we are testing, on whom, and by which signs we will know the answer has arrived. Without this an MVP turns into merely a small product.
Which scenarios go into the first version and which do not. Contested features are deferred in writing, so they can be returned to.
The key screens as a clickable prototype, then the styling. At this stage another couple of features usually fall away.
Frontend, server side, integrations and everything without which the scenario does not work end to end.
We ship to real users, watch behaviour and gather feedback and metrics.
A review of the result and an honest answer: develop, rebuild or close. Plus an estimate for the next step.
How we work
What we are testing, on whom, and which numbers measure success.
What goes into the first version, what is deferred, an estimate by stage.
A clickable version and styling of the key screens.
Two-week iterations with a demo, each of which can be opened and walked through as a scenario.
Real users, observation, metrics, a decision on the next step.
Stack and tools
Cases for this service
Frequently asked questions
There is no code behind a prototype, it is a set of linked screens for checking logic and usability. An MVP is a working product with a server side and real data, used to test demand and money.
A cheap version does all the same things, only worse. An MVP does little but does it fully, and answers one specific question. These are different things, and confusing them is expensive.
It depends on how many scenarios go into the first version and whether it needs its own server side. We give an estimate by stage after working out the hypothesis, and that is where it becomes visible what exactly you are paying for.
Then you find that out in weeks and for modest money. That is the point. We deliver a negative answer plainly rather than suggesting you refine it a little further.
Not in full. The architecture is set up so that a successful version can be developed further. If part of the code is deliberately written to be thrown away for speed, we name that before the work starts.
Everything is set by the contract, and we put it in writing at the specification stage, before the work starts. During the project the team works either on our infrastructure or on yours: the choice depends on the complexity of the project and on whether you already have infrastructure in place. Every approved stage is transferred to your servers and your repository, so the work accumulates on your side rather than ours. Once the project is closed, all code, materials and documentation are handed over to you together with the rights to them.
Yes, under a separate agreement: on-call duty, refinements and the move from a first version to a full product.
Related services
Shall we discuss your task?
Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.