Most bad software projects aren’t broken by bad code. They’re broken by a bad scope — a document everyone signed off on that turned out to describe the wrong problem. So before we talk timelines or price, we spend time making sure the scope is describing the right thing.
Here’s what that actually looks like.
We start with the decision, not the feature list
Clients usually arrive with a feature list: “we need a dashboard,” “we need a mobile app,” “we need to integrate with X.” A feature list is a solution someone has already picked. Our first job is to work backwards from it to the decision or outcome it’s meant to serve.
If the answer to “why this feature” is “so we can see Y,” we ask what happens once you can see Y. If nobody can point to a decision that changes, the feature doesn’t belong in v1 — no matter how reasonable it sounded in the kickoff call. This isn’t us being difficult. It’s cheaper to cut scope in a conversation than in a sprint.
We separate what’s known from what’s assumed
Every scope has a mix of things we’re confident about (the data model, the auth approach, the deployment target) and things we’re guessing at (how many users will actually show up, whether a third-party API will behave the way its docs say it will). We write both down, explicitly, in the same document — not because assumptions are a problem, but because unlabeled assumptions are.
An assumption you’ve named is a risk you can plan around. An assumption nobody wrote down is a surprise waiting for week six. Concretely, our scope documents carry a short “known unknowns” section listing exactly what we’re assuming and what happens if we’re wrong. It’s usually short. It’s never empty.
We size in ranges, not points
We don’t use story points, and we don’t promise fixed-price/fixed-scope on anything with meaningful uncertainty in it. Instead we give ranges tied directly to the unknowns above: “if the payment provider’s sandbox behaves like production, this is two weeks; if it doesn’t, budget a third.” That’s a less comfortable sentence to put in a proposal than a single number, but it’s an honest one, and it means the range narrows as we learn — instead of the number quietly slipping while everyone pretends it hasn’t.
We scope the architecture decision, not just the deliverable
A build isn’t just “ship the thing.” It’s also the set of decisions that determine how expensive the next thing will be — what’s a service boundary, what’s a shared library, what data lives where. We call these out separately in scoping, because they’re where the real technical risk sits, and because they’re the decisions a client should be in the room for, not ones we make silently and explain later.
What this means in practice
A Dexorus scope document is usually three things: the outcome we’re building toward, the known unknowns and how we’ll de-risk them, and a range instead of a single number where uncertainty is real. It’s less polished than a fixed-price PDF with a table of deliverables. It’s also closer to the truth of how software actually gets built — which is the only kind of scope document worth signing.
If you’re evaluating a build and the proposal in front of you doesn’t have a “known unknowns” section, ask why not. Either the estimator is more confident than they should be, or they haven’t looked closely enough yet to know what they don’t know.