The worst moment in a web project is the surprise invoice. The work drifts, the "quick change" becomes three days, and the final bill arrives with a number nobody agreed to. Most people have a story like it. Our whole process is built to make that moment impossible. Here is how we scope a project, step by step, so the price is fixed before we start and nothing lands out of the blue.
It starts with the problem, not the feature list
Plenty of projects begin with a shopping list: we need a booking system, a portal, a redesign. We start one step back, on a discovery call, by asking what problem the thing is meant to solve. Missed enquiries? Hours lost to admin? A site that looks fine but never converts? The feature is a guess at the answer. Naming the problem first often changes what we build, and usually makes it smaller and cheaper than the list you arrived with.
We define the outcome and the smallest system that gets there
Once the problem is clear, we agree the outcome that would count as solved. Not "a new website", but "enquiries are easier to make and easier to track". Then we design the smallest system that delivers that outcome. Smaller is not a compromise. A tighter build ships sooner, costs less, breaks less, and leaves room to add the next thing once the first has earned its place. We would rather build the right small thing than an impressive large one you do not need.
We write the scope down, including what is out
This is the step most quotes skip, and it is where surprises are born. We put in writing exactly what the project includes, and just as importantly, what it does not. The pages, the features, the integrations, the number of rounds of design, who supplies the content. A clear boundary is not us being rigid. It is the thing that protects you, because everyone can see the edge of the work and nobody can quietly move it later.
A fixed figure, before any work starts
From that written scope we give you a fixed price. Not a range, not an estimate that creeps, a figure you approve before we begin. You know the full cost at the point of decision, which is the only point where it is any use to you. We can carry a fixed price with confidence precisely because we did the thinking in the steps above. The scope is the reason the number holds.
Change is a conversation, never a shock
Projects evolve, and good ideas turn up halfway through. That is welcome. What we refuse to do is absorb changes silently and bill for them at the end. If something new comes up, we tell you what it adds in time and cost before we do it, and you decide. You are never presented with work you did not choose. Change is a normal part of the process, handled in daylight, with a yes or no from you each time.
Why fixed scope protects both sides
A vague scope is bad for everyone. It lets a supplier pad the bill, and it lets a project balloon until neither side is happy. A clear one keeps us honest and keeps you in control. We know exactly what we committed to build, you know exactly what you agreed to pay, and the finish line is a line both of us can see. It is the difference between a project that ends and one that quietly never does.
The honest caveat
Fixed scope needs a clear problem. Most projects have one. Some genuinely do not yet, because the real question is still being worked out, and pretending otherwise would just move the guesswork inside a fixed price where it helps nobody. When that is the case we say so, and scope a short, paid discovery phase to find the answer first, with its own fixed cost. Then the build that follows can be priced properly. Certainty comes from clarity, so we get the clarity before we sell you the certainty.
Thinking about a project and want to know what it would actually involve? Book a discovery call. We will name the problem, sketch the smallest system that solves it, and follow up with a written scope and a fixed price, with no obligation. You can see the kind of work it produces on our work page.
Common questions
Do you really give a fixed price for web projects?
Yes, once the scope is agreed. We do the discovery and write down exactly what is included first, and the fixed price comes from that. The only time the figure changes is if you ask for something outside the agreed scope, and even then we tell you the cost before doing it, so you decide. There is no bill at the end you did not approve along the way.
What happens if I want to change something mid-project?
You tell us, and we tell you what it adds in time and money before any work happens. If you are happy, we do it. If not, we do not. Changes are expected and welcome; the only rule is that they are agreed in advance, never absorbed quietly and invoiced later. That way the project can evolve without the price ever surprising you.
How long does the scoping process take?
For most website and software projects, a discovery call and a written scope come back within a few days, not weeks. Larger or less-defined projects may need a short discovery phase first, which we price separately and keep tight. The aim is to reach a clear scope and a fixed number quickly, so you can make a confident decision without a drawn-out sales process. Scoping matters most on custom software, where the difference between a tight build and a sprawling one is usually the exceptions nobody mentioned in the first meeting.
Why is a written scope so important?
Because a surprise is only possible when the boundary is unclear. Writing down what is in and what is out gives both sides the same picture, removes the room for a bill to creep, and turns any later change into a simple, visible decision rather than a hidden cost. The document is the thing that lets us hold a fixed price and lets you trust it.
