How to scope a build without getting fleeced.

Most prospects who arrive at this practice arrive with a scar. The story is the same shape every time: a previous vendor was hired to build something, the price seemed reasonable, the engagement felt promising, and then six months and a multiple of the original quote later, the prospect was left holding a half-finished system, a maintenance bill, and the dawning recognition that the firm they hired never had any intention of finishing on the original terms.

This is not a rare failure mode. It is the failure mode of the software-services industry, and it has its own grammar — a specific set of words, phrases, and contract clauses that show up almost every time the engagement is going to go sideways. If you learn the grammar, you can read the proposal in front of you with the kind of clarity that makes the rest of the conversation honest.

What follows is the list. Read it before you sign anything; bring it to the next conversation.

Red flag: "We bill time and materials." Translation: we do not know how much this will cost, you will find out as we work, and we have no incentive to be efficient. T&M is the right billing model for a tiny number of engagements — usually long-term retainers with mature client relationships and shared risk. It is the wrong billing model for the first build with a new vendor. If the firm cannot quote a fixed price for a fixed scope, the firm does not understand the scope well enough to be hired for it.

Red flag: "Scope is flexible — we'll figure it out as we go." Translation: scope is upward-flexible; we will figure out how much more to bill you as we go. Flexible scope sounds like a feature ("agile! responsive! collaborative!") and is in practice the leading cause of the doubled-quote ending. Push back: ask for a written scope before the engagement begins, with explicit assumptions, explicit non-goals, and an explicit change-control process that triggers re-scoping (in writing) before any out-of-scope work begins.

Red flag: milestone payments triggered by deliverables. This one is a whole essay on its own — we wrote it [here](/notes/why-we-don-t-do-milestone-payments) — but the short version: the contract structure rewards the firm for calling something done and rewards you for withholding approval until the next thing also lands. Either way, the engagement becomes adversarial at every milestone. Replace milestones with a booked deposit (credited toward the project total) plus a fixed engagement fee that adjusts only via written revisions.

Red flag: "The team will be assigned at kickoff." Translation: you are buying from one person and getting another. The person who pitched you the engagement, with all the experience and the trustworthy demeanor, will hand you off to a junior on day one. Ask in writing, before signing: who specifically will be on the engagement, what is their level, who reviews their work, and what happens if they leave the firm mid-engagement. If the answer is vague, do not sign.

Red flag: no written architecture document before the build phase. "We build agile" is being deployed here to mean "we will start coding without knowing what we are building, and we will discover the architecture as we discover the requirements." This is the surest way to end up six months in with a half-finished system that has to be partially rewritten because the early choices boxed in the later ones. Demand a written architecture document — framework, database, deploy target, integration plan, security posture — before any code is committed to the repo you own.

Red flag: "The dependencies are our standard stack." Translation: we have a default set of libraries we use, we have not re-evaluated them in years, and you are inheriting whatever technical debt and security exposure that stack carries. A senior firm explains its toolchain decisions per engagement, with reasons tied to your build's specific constraints. If the answer is "this is what we always use," ask why; if the reason is "it's what the team knows," ask what happens when the team changes.

Red flag: the maintainability story is "we will hand off documentation." Documentation that gets written at the end of an engagement is the kind of documentation that gets skimmed once and never touched again. The real maintainability artifact is the code itself — its structure, its tests, its commit history, and the names on the commits. Ask to see a sample of the firm's recent code from a delivered engagement (with the client's permission, redacted if needed) before you sign. If the firm cannot show you the code they would write for you, they are not the firm you want writing it.

Red flag: no offramp. Every engagement should have a written offramp — what happens if you decide partway through that the engagement is not working, who owns the IP, who can transition the work, what the refund/credit posture is. Firms that refuse to write down the offramp are firms that have used the absence of one to lock prior clients into bad engagements. Walk away.

Green flag (rare, valuable): the firm tells you what they will not do. Senior firms have positions — billing models they refuse, engagement sizes they decline, technical patterns they consider malpractice. The presence of explicit non-goals in the conversation is one of the strongest positive signals you can get. It means the firm is choosing engagements on fit rather than chasing every dollar.

Green flag: the engagement portal exists and you can see it before signing. Some firms operate out of email and Slack threads. Senior firms have a working surface — a portal, a project tracker, a shared workspace — where the engagement actually happens and is visible to you in real time. Ask to see the surface before you sign. If the answer is "we'll set you up on Tuesday," you are signing into a black box.

Green flag: the firm will walk away from your engagement. This is the strangest signal but the most diagnostic. A firm that has the capacity and the cash-flow flexibility to decline an engagement that isn't a fit will tell you so during discovery, with a referral if they have one. A firm that takes every engagement that walks in the door is a firm that desperately needs the next dollar — which means they will keep the engagement past the point where they should have walked away.

The compressed version of all of this: scope is a control surface, not a marketing word. The vendors who do this well treat scope as a piece of engineering — written, reviewed, version-controlled, change-managed — and the vendors who do it badly treat scope as a vibe. You can tell which one you are sitting across from inside the first hour.

If you read all of this and decide you want to bring the list to a conversation with us, we welcome it. We answer every one of the items above the same way, and we put the answers in writing.