How much does an MVP cost?

It depends entirely on scope, which is exactly why the first conversation is about cutting scope rather than pricing a feature list. We price each stage before it starts, so you are never committing to an open-ended project.

Will we have to rebuild it later?

Not if it is built properly. A first version should be small, not shoddy. We deliberately leave things out; we do not deliberately build them badly, because the rebuild tax lands exactly when you can least afford it.

What if the idea does not work?

Then you found out in four months for a known cost, which is the point. A staged approach means you can stop at the end of any stage, and you own everything built so far.

Do we need funding first?

No, though it obviously helps. Plenty of good products are funded from an existing business or from the first customers. What matters more is that somebody has confirmed they will pay for it.

The first version should answer a question, not implement a wish list.

MVP Development in Gloucester

MVP development for Gloucester businesses, from Cube Systems. UK-built, UK-supported, and configured around your process. Serving Cheltenham, Stroud and Tewkesbury too.

Product development
Gloucester, Gloucestershire
01234 672 617

Talk about your product All product development

We support businesses in Gloucester the way we would want to be supported ourselves: someone who knows the account, on the end of a phone, and on site when being on site is what the job needs. Gloucester is comfortably within a morning’s drive of our Olney office.

Most first versions fail for the same reason: they were too big. Six months of building to a feature list assembled before anybody had used anything produces a product nobody asked for, delivered too late to change course cheaply. A minimum viable product is not a cheap product or an unfinished one - it is the smallest thing that lets real customers do the valuable part of the job, built well enough that you can keep going from it rather than throwing it away. Cube Systems helps decide what that smallest thing is, builds it properly, puts it in front of paying customers, and then works out what the second version should be based on what actually happened.

4 months
A realistic target for a focused first release
Priced by stage
Agreed before each stage starts, never open-ended
Built to keep
Small on purpose, not unfinished

What it involves

Inside MVP development

The parts of the job that decide whether a product can be sold at scale, rather than only delivered once.

Scope decided by what it proves
Every candidate feature is judged against one question: does leaving it out stop a customer getting value? Most of them do not, and the ones that do become the first release.
Built to keep, not to demo
A throwaway prototype is fine for a pitch and a disaster as a foundation. The first version is built on the same architecture the real product will use, just with far less of it.
Charging from the first release
Signup, plans and payment included from day one. An idea that people will pay for behaves very differently from one they will merely sign up to for free.
Instrumented to learn from
Activation, drop-off and feature usage tracked from launch, so the second version is designed from evidence rather than from the loudest customer conversation.
An interface people can use unaided
A first version that needs a walkthrough is a first version that will not convert. Onboarding is treated as part of the product rather than as documentation.
A path to version two
Where the product is likely to grow is designed for even when it is not built. The parts that are deliberately simple are the parts that are cheap to replace.

In practice

Where this usually starts

Anonymised, but not invented. These are the situations people describe to us before anything gets built.

An idea from inside an industry
The situation
Someone who had worked in an industry for twenty years knew exactly which administrative problem everybody in it had. They had a very clear idea, no software background, and a list of forty features.
What changed
The list was cut to four. The first version launched in under four months, converted its first paying customers from the founder’s own network, and the roadmap was rebuilt from what those customers actually did with it.
A prototype that had run out of road
The situation
A team had validated demand with a no-code prototype, but it could not handle their data volumes, could not be secured properly and could not take payments the way they needed.
What changed
The validated workflow was rebuilt as a real application with the same behaviour, then extended with the two things the prototype could never do. No user had to relearn anything.
A new line inside an existing business
The situation
An established company wanted to launch a subscription product adjacent to their main business, but could not justify a full internal team before knowing whether it would sell.
What changed
A first version was built and launched by our team while the business tested the market. Once retention proved the model, the platform and the knowledge were transferred to an internal team.

Local coverage

MVP development across Gloucestershire

We cover Gloucester and the surrounding area, including City Centre, Kingsholm, Barnwood, Quedgeley and Hucclecote, across the GL1, GL2, GL3 and GL4 postcode districts. We also work with businesses in Cheltenham, Stroud, Tewkesbury and Cirencester and elsewhere in Gloucestershire.

Postcode districts

Areas we cover

City Centre, Kingsholm, Barnwood, Quedgeley, Hucclecote, Abbeydale, Gloucester Business Park and Gloucester Quays.

Getting to you

Roughly 68 miles from our office in Olney, Buckinghamshire. Discovery, training and go-live are done on site as standard - not because it looks good on a proposal, but because most of what a system needs to know is learned in the building.

MVP development elsewhere in Gloucestershire

All of Gloucestershire

How it happens

How a build actually runs

The same process wherever you are, and for Gloucester the sessions that benefit from being in a room are held in one.

Shape
A few sessions working out what the product is, who pays for it and what the first version has to do. You leave with a written scope and a price, whether or not you go further.
Design
Screens, flows and the data model behind them, agreed before anybody writes production code. Changing a decision here costs an afternoon rather than a month.
Build
Two-week cycles with something working at the end of each one, in an environment you can log into. No six-month silence followed by a reveal.
Launch
Billing live, onboarding tested, monitoring in place, and the first real customers on the platform with somebody watching closely.
Run
Hosting, support and continued development for as long as you want it - or a clean handover to your own team, with everything documented.

You might call it something else

MVP development goes by a lot of names - if you searched for any of these, this is the page you wanted.

Minimum viable product development
Prototype to product
Startup software development
Proof of concept development
First version development
Product discovery and build

Questions

The things people ask first

It depends entirely on scope, which is exactly why the first conversation is about cutting scope rather than pricing a feature list. We price each stage before it starts, so you are never committing to an open-ended project.
Not if it is built properly. A first version should be small, not shoddy. We deliberately leave things out; we do not deliberately build them badly, because the rebuild tax lands exactly when you can least afford it.
Then you found out in four months for a known cost, which is the point. A staged approach means you can stop at the end of any stage, and you own everything built so far.
No, though it obviously helps. Plenty of good products are funded from an existing business or from the first customers. What matters more is that somebody has confirmed they will pay for it.