Scoping Workshop

Yes, for a defined build. Product discovery is the thinking done before code: who the product is for, what it must do first, and what it will cost. The scoping workshop does that work and ends with a costed, prioritised spec your team can act on. If the problem itself is still unclear, start with the Rapid Insight Workshop instead.

That workshop is a strategic entry point: two sessions that map the operational picture and identifies where the highest-value opportunities are. It is designed to answer "where should we start?" for organisations with multiple moving parts. The Scoping Workshop is for a specific project that has already been identified — it produces the full requirements documentation needed to build that project to a fixed price. They serve different purposes and are not substitutes for each other.

It depends on project complexity. Simpler projects typically require two to three workshop sessions over one to two weeks. Large, complex builds — multi-role platforms, significant integrations, or products with many edge cases — may require four to six sessions over three to four weeks. We scope the workshop itself before we start so you know what is involved.

The project sponsor, the people who will use the system day-to-day, and anyone who owns a system or process the product will need to connect to. Decision-makers need to be available — not for every session, but at key points where scope decisions need sign-off. We will tell you who we need and when.

A requirements document that defines every feature, user role, integration, and edge case in the agreed scope. A fixed-price quote based on that document. And a clear picture of what is in scope, what is out, and what assumptions we have made that need validation before build begins.

Yes. The requirements document belongs to you and is written to be development-team-agnostic. In practice, the majority of clients who complete a scoping workshop proceed with us for the build — but it is not a condition. The document is yours regardless.

Yes, outright. The requirements document is yours to keep and to take to any developer you like — including out to tender against us. It is written to be built from by anyone competent, not as a lock-in device.

A scoping workshop is priced to the size of the build, and you get that price before it starts. The cost depends mostly on how many sessions the project needs, which follows from how many user roles, integrations and edge cases it has. A simple internal tool needs fewer sessions than a platform used by staff, customers and suppliers. We scope the workshop itself first, so you know how many sessions, who needs to attend and what it costs before you commit. If a short conversation shows you need less, or that you are not ready to scope yet, we will say so.

If scope changes after sign-off, the change is written up against the requirements document and priced before any work on it starts. Because the document defines every feature and its edges, it is clear whether a request is new scope or something already agreed. New scope gets its own estimate, and you decide whether to add it, swap it for something of similar size, or hold it for a later phase. Nothing is added quietly and billed at the end. That is the point of fixing the scope first: changes still happen, but they are visible, priced and your decision.

The requirements document is detailed enough that a developer can estimate and build each feature without coming back to ask what it means. Each feature is written as what it does, who uses it, how it behaves and what happens at the edges, such as a missing field, a duplicate record or a user without permission. Integrations name the system, the data and the direction it flows. It does not include finished visual design or code. Where a decision cannot be made yet, it is listed as an assumption with an owner, rather than left as a gap to be argued about mid-build.

Yes. Scoping only the first phase is often the right call when budget, timing or uncertainty make a full build hard to commit to. We scope phase one in full detail, to the level needed for a fixed-price quote, and record the later phases at a high level so the first phase is built in a way that will not have to be torn out later. That gives you a working release, a known cost and real use to learn from before deciding what comes next. When you are ready for the next phase, it is scoped on top of the same document.

You do not need a finished brief before the scoping workshop, but a little preparation makes the sessions faster. Bring any existing documents, such as a brief, process notes, sample reports or screenshots of the tools your team uses today. Make a list of the systems the build will need to connect to and who looks after each one on your side. Most importantly, confirm who will attend and when your decision-makers are free to sign off. We send a short checklist before the first session, so nobody arrives unsure what is expected of them. If something is missing on the day, we note it as an open question with an owner and keep going.

A brief is a good start, but it is rarely detailed enough for a fixed-price quote on its own. Briefs usually describe what the software should achieve, while a developer also needs to know how each feature behaves, who can do what and what happens at the edges. The scoping workshop uses your brief as its starting point, so the work already done is not thrown away or repeated. We test it with the people who will use the system, fill the gaps and turn it into a requirements document. If your brief already covers most of that, the workshop is shorter and costs less.

If the quote comes in over your budget, you find out before any build money is spent, which is the point of scoping first. Because every line of cost traces back to a line of scope, you can see exactly what is driving the price. You can then cut or simplify features, move some to a later phase, or build a smaller first release and grow it from there. We will show you where the cost sits and suggest what to trim without breaking the core of the product. Changing the plan on paper costs very little compared with changing it halfway through a build.

No. If we build the project, the build starts from the requirements document and does not repeat the discovery you have already paid for. The scoping workshop is the discovery stage, so the team moves straight into design and development using the document you signed off. Some detail is always confirmed during the build, such as small layout choices, but that is part of normal delivery rather than a second round of discovery. The same applies if you take the document to another developer, since it is written for anyone competent to build from. Either way, the work you paid for carries forward.