Skip to content

Product launch

End-to-end MVP

From idea to a launched MVP in 4–8 weeks. What goes into the first version and what waits for the next is settled before the start. The architecture is built to grow after release.

Reply to your brief
within 24 hours
First call
30 minutes, no commitment
First working version
by the end of week 4

Process

What happens, and when

The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.

  1. Days 1–7

    Scope of version one

    We cut what you have in mind in two: the journey the product makes no sense without, and everything else. Everything else is not thrown away, it becomes the list for the next version — and later that list shows exactly what you did not pay for in month one.

    You get — The core journey and the next-version list

  2. Weeks 2–3

    Modules and data

    We set the module boundaries and the data model so that a hypothesis which fails changes one module rather than the whole product. This is also where it is settled what the admin panel can do and which API the client needs — web or mobile.

    You get — Module boundaries, data model and the chosen API

  3. Weeks 3–6

    The main journey

    We build the main journey whole rather than in pieces: by the end of week four you can create an account on the test server, take the journey to its end and see the result in the admin panel. Everything else is built around it.

    You get — The whole journey on the test server

  4. Weeks 7–8

    The production server

    The move to the production server: Docker and NGINX, certificate, automated builds. Logs and monitoring go on the same day — in a first version a breakage usually shows up on the error graph rather than in an email from a user.

    You get — A live environment with logs and monitoring

  5. After launch

    Rebuilding the plan

    Real users show which of the guesses held. The list parked in the first stage is rebuilt around what the logs and the behaviour show — the second version is no longer built out of assumptions.

    You get — A next-version list rebuilt from the logs

What the work covers

  • Scoping

    going through the task, clarifying the requirements and analysing the risks before the work starts

  • An architecture plan

    what the product is made of, where the boundaries between modules run, what gets added after the first release

  • The core modules

    the journey the product launches for, an API for the web or mobile client, an admin panel to run it from

  • The data model

    entities and relations shaped by what the product does, laid out to survive the changes that follow the first release

  • Going live

    Docker and NGINX, SSL, deployment to a server or to the cloud, basic CI/CD

  • Logging and monitoring

    what the server is doing, and where it stopped doing it

What we need from you

  • The idea and the journey it launches for — or a written spec, if one already exists
  • Your server and domain with credentials, if that is where the product goes live
  • Someone who watches the work as it lands and says what happens next

What people usually ask

Contact

Send a description of the task

A reply with the scope, the timeline and a budget estimate comes within 24 hours.

The first call is 30 minutes, with no commitment on your side.

  1. 01

    You describe the task

    Five questions in the form, or a plain email — whichever suits you.

  2. 02

    We answer within a day

    With the scope, the timeline and a budget estimate, based on what you told us.

  3. 03

    We talk for 30 minutes

    To clear up whatever is unclear. It commits you to nothing.