From idea to MVP in 8 weeks: our development process

Eight weeks is not a marketing number. It is roughly what it takes to get a focused product idea into the hands of paying users, provided the scope is held honestly. Here is how the weeks actually break down.

Weeks 1–2: Discovery and definition

We define the single job the product does, identify who pays, and write the shortest possible list of features that makes that job possible. Everything else goes onto a "later" list that we keep visible rather than pretending it does not exist.

Output: a scoped feature list, a data model sketch, wireframes for the core flow, and a fixed delivery plan.

Weeks 3–4: Design and foundations

Interface design for the core flow only, alongside the technical foundation — authentication, database schema, deployment pipeline, environments. By the end of week four there is a deployed application that does one real thing end to end.

Weeks 5–6: Core build

The main functionality lands in two sprints, each ending with a demo you can click through. This is where scope discipline earns its keep: every request gets triaged against the launch date, not silently absorbed.

Week 7: Payment, polish and instrumentation

Billing, transactional email, analytics, error tracking. The unglamorous layer that turns a demo into a business. We also fix the ten worst rough edges found in internal testing.

Week 8: Beta and launch

A small group of real users, a feedback loop measured in hours, then public launch. Not a soft launch that never ends — a date, with a plan for what happens the week after.

What we deliberately leave out

• Admin tooling beyond the minimum — early on, a database client and a developer are faster than a half-built back office.
• Edge-case handling for scenarios that need a thousand users to occur.
• A second platform. Web first; the mobile app waits for evidence.
• Micro-optimisations of infrastructure that costs €40 a month.

An MVP is not a smaller version of the final product. It is the smallest thing that proves someone will pay.

What makes it fail

Three things, consistently: a scope that keeps growing, a client-side decision maker who is unavailable for two of the eight weeks, and a dependency on a third party whose access has not been arranged in advance. All three are manageable — but only if they are named at the start.