MVP
From brief to working product in six weeks.
Not a clickable prototype. A real product with real accounts, real data, and real security — because eighty percent of it was already built and tested before your project started.
Built, tested and secured before your project started
The part that makes it worth building
Conventional builds treat all hundred squares as new work.
Because most of it isn't new.
A typical MVP brief is 80% things that exist in every product — sign-in, accounts, content, file uploads, an admin panel, email — and 20% the thing that makes it worth building.
Conventional builds treat all of it as new work. Six weeks in, the demo shows a login screen.
We start from the 80% already finished at production quality, and spend the time on your 20%.
Where the six weeks actually go
Two of them are the reason you are commissioning anything at all.
- Week 1
Shape it
We take the brief apart. Which parts are configuration, which need building, and what can wait until after launch. You get a written scope with the boundary drawn explicitly.
- Week 2
Configure
Content model defined, features switched on, roles set up, branding applied. The admin panel is working and your team can log in and look around.
- Week 3-4
Build the difference
The 20% that's genuinely yours. The specific workflow, the unusual rule, the integration that matters. This is where the engineering time actually goes.
- Week 5
Front end
The public-facing layer, designed and built against a working API that's been running for three weeks.
- Week 6
Harden and launch
Real data, real load, the security pass, the launch checklist. Then live.
Roughly eleven days of that is spent on anything unique to you. The honest version of “six weeks” is: five weeks of assembly and configuration, eleven days of genuine invention, running in parallel.
What “working product” means here
In the MVP
- Real user accounts with secure sign-in
- Working admin panel your team can use
- Content and data model built for your product
- Media handling with policies
- Email notifications
- Permissions and audit logging
- Production-grade security
- Deployed and live
Deliberately after launch
- Features you're not sure you need yet
- Integrations that can wait for real usage
- Optimisation for scale you don't have
- Anything the first hundred users won't touch
The second column isn't cut scope. It's scope you'll be better qualified to specify in three months.
What determines the number.
MVP engagements are priced per project, because the honest variable is how much of your brief falls outside the 80%. Three things move it:
How much is configuration
The more your product resembles something the feature catalogue covers, the less there is to build.
How unusual the workflow is
A conventional store is faster than a claims process nobody has automated before.
How much front-end design is involved
A brand-led interface takes longer than a functional one, and is often worth it.
The three things that make this fast.
All three are yours, not ours. Six weeks fails on these far more often than on engineering.
- 01
A decision-maker who's available.
Six weeks has no room for a two-week approval cycle. One person who can say yes.
- 02
Content, or a plan for content.
The most common cause of a delayed launch isn't engineering. It's that nobody wrote the copy or took the photographs.
- 03
Willingness to cut.
Everything in the brief will not be in the MVP. Deciding that early is fast; deciding it in week five is expensive.
Have a brief?
Send it over. We'll come back with what's configuration, what's build, and roughly what it costs. Quarkino is the part that's already done.
- We reply within one working day
- No sales sequence, no drip campaign
- NDA before the call if you'd prefer