From bottleneck to fixed price: how a problem becomes a scope

At Cloudwerks, exactly one document stands between the first conversation and the first line of code: the written scope. It is the reason we can name a fixed price. This post explains how it comes about, what it does for you – and what happens to wishes that come up along the way.

Why we start with the problem, not the solution

Many enquiries start with a solution: “We need an app.” Or with another provider's quote that lists thirty pages of features. We start one step earlier – with the process that does not work today. An order that is typed in three times. A field team that works through paper forms in the evening. A stock count that takes a week.

The reason is simple: the MVP Sprint is fixed in time and price. Eight weeks, €9,500. The only variable is what goes in. So the work before the start is to find the smallest version that actually solves the bottleneck in daily use – not the largest one that fits the budget.

What “first version” means

A first version is the software the people who handle the process every day can work with from day one. Nothing more. The special case that occurs twice a year usually does not belong in it. Neither does the report management would like to see “at some point”.

There is also a trade-off you should know about: the eight weeks stay fixed, but every additional platform shifts the scope from depth to breadth. A web application, an Android app and an ERP connection in one sprint are possible – then each of them is leaner than if only one were built. On the MVP Sprint page you can play through that shift yourself.

What the written scope contains

The scope records what will be built: which process, for which users, on which platforms, with which connection. It equally records what is not included – the points that were classified as build-out in the conversation. Plus the fixed price and what you receive at the end: a running system in your environment, documented and ready for hand-over.

We write it so that you can read and judge it without an engineer. You have it in front of you before you pay anything. If you notice while reading that something is missing or too much, that is the moment to say so – not in week five.

What “finished” means

In many projects the argument about whether the software is finished only starts at the end. With us the question is answered before we begin: finished is what the written scope says, and it is finished when it runs in your environment. Within that scope the fixed price applies. There are no hours quietly accumulating.

When a wish comes up along the way

It happens in every project, and it is a good sign: people who see working interim versions get ideas. The rule is simple. Nothing outside the written scope is built on the quiet. The wish is noted and offered as a build-out – in writing, before it is implemented. You then decide whether it follows right after the sprint, later, or not at all.

This rule protects two things: the eight weeks and the price. But it also protects you from a project that started small and clear becoming large and vague under the radar.

What this means for your decision

Before you commission anything, you know three things: what you get, when you get it, and what it costs. That makes a quote comparable – including the one that may already be on your desk. For orientation, the MVP page has an overview of what a comparable scope typically costs with agencies, freelancers or an in-house hire.