Product Development Plan

Who it is for

The Product Development Plan fits when you know roughly what you need built and want to know what it will cost and how long it will take before you commit to it.

• You have a portal, booking system, web application or integration in mind and need a price you can take to the board.
• You hold quotes that differ by a factor of three and cannot tell which one is realistic.
• A build has stalled and somebody needs to write down what is actually there before deciding what to do with it.
• You are moving onto a headless CMS and need the content model and the redirect map settled before anyone writes code.

If you only want a number to start a conversation, the project cost estimator is free and takes two minutes. If you are taking over a platform another team built, start with a Platform Health Check. If several systems need rationalising and the order is the question, the Technology Roadmap settles the sequence first.

What you get

Two facilitated workshops and a written pack, delivered about a week after the second workshop.

• The scope: what the product has to do, for whom, and what is deliberately left out of the first release.
• The architecture and the data model.
• An inventory of every integration, with the constraints each system actually imposes.
• A phased delivery plan and a risk register.
• A fixed quote in MVP and full options.

Then an hour walking through it. The pack is written so that another development team could build from it.

How it runs

1. A 30-minute call. We confirm what the plan covers, agree who needs to be in the workshops and book them. Nothing is invoiced before this call.
2. Workshop one: what it has to do. Two hours with the people who will use the product, on requirements and priorities.
3. Workshop two: what it has to talk to. Two hours on the systems the product depends on and what those systems will really allow, which decides much of what the build costs.
4. The pack, about a week later. Scope, architecture, integration inventory, delivery plan, risk register and the fixed quote.
5. The walkthrough. An hour on the reasoning, and one round of revision after it.

Why we charge for planning

Free scoping is paid for somewhere, usually inside a build quote padded against the unknowns nobody had time to resolve. Charging for the planning separately is what lets us resolve them, and it is how you find out what something costs before you commit to it.

If we build it, the fee is credited in full against the first build invoice, so the planning costs nothing on top. If someone else builds it, or nobody does yet, you keep a document that makes every later conversation with a developer shorter and cheaper. If we are not the right team for the build, the pack still works with whoever is.

Headless CMS builds and migrations

A move onto a headless CMS is planned through the same engagement, with the first workshop run as a content model and URL audit rather than a requirements session. The questions that decide a migration are what the content actually is, how it should be modelled, and which existing URL has to keep working after cutover. The pack that follows carries the content model, the redirect map and the fixed quote.