MVP Development Services

Desenvolvimento web Escalável Seguro Desempenho Fiável Suporte a longo prazo

Desenvolvimento web

An MVP is not a cheap version of the product. It is an experiment with a question attached, and the only thing that makes it minimal is knowing which question.

Most of the value of this work happens before any code: deciding what would count as an answer, and what will be deliberately left out until there is one.

Naming the question

Whether people will use it is not a question a build can answer. These are:

Will these particular customers pay for this, at this price?
Can this process actually be automated, given how messy the real inputs are?
Does the integration we are betting the product on give us the data we think it does?
Will our own team use it instead of the spreadsheet they use now?

Each of those implies a different build, and some of them can be answered without software at all - which we will say if it is true.

What we cut, and what we never cut

Cut without argument

The things a first version can live without:

Admin screens for anything that can be done directly in the database by us, for now
Every role except the one being tested
Settings, themes, and anything configurable that could be a constant
Scale - it does not have to serve a thousand people to answer the question

Never cut

The things that turn a successful MVP into a rewrite if they are missing:

A sane data model, because that is what a second version has to live with
Authentication that is real, not a hardcoded password
Anything touching personal data or payments, done properly the first time
The repository, the pipeline and the environments - so version two starts where version one stopped

How it runs

Short cycles with something working at the end of each, and a fixed date at which the question gets answered whether or not everything on the list is built. An MVP with no end date stops being an MVP within about six weeks.

Perguntas frequentes

How long does an MVP take?

Most of the ones worth doing are six to twelve weeks. Longer than that usually means the question is too broad, and narrowing it is cheaper than building for six months to find out.

Will we have to throw it away?

Not the parts that matter. We cut scope, not foundations - the data model, the authentication and the deployment are built as though it will succeed, because when it does, that is the difference between continuing and starting again.

Who owns the code?

You do, from the first commit, in your own repository. This matters more for an MVP than for anything else, because the whole point is to be able to keep going without us if you want to.

What if the answer is no?

Then it cost weeks instead of a year, which was the point. We would rather run a project that ends in a clear no than one that ends in an expensive maybe.

What are you trying to find out?

Tell us the question rather than the feature list. If the question is sharp, the build is usually smaller than expected; if it is not, that is the first thing worth working on together.

Comece o seu projeto