The myth of the "proper spec"
A lot of prospects apologize on the first email: "Sorry, I don't really have a spec yet. I just have an idea." Our reply is always the same. You don't need one. You never did.
The industry's obsession with pre-written specifications is a leftover from the era of waterfall consulting, when a firm needed six weeks of "discovery" before they'd quote a price. Modern build cycles are short enough that the scope emerges in the first hour of talking. If a vendor still needs a written spec before they'll return your email, that's not a scope problem — that's a vendor problem.
A scope is a decision, not a document. Twenty minutes of the right questions produces a better scope than twenty pages of the wrong ones.
The seven questions that produce a scope
These are the questions we walk through on the one-hour orientation. Answer them in your own words — don't translate to engineering language, and don't try to sound "technical." The plainer the answer, the better the scope.
- 01
What does the business do?
Describe the operation. Who works there. What comes in, what goes out. What the customer buys. If your explanation would confuse a smart 12-year-old, keep going until it wouldn't.
- 02
What's slow, brittle, or embarrassing right now?
Not what you want to build — what's actually broken. "We track contractors in a spreadsheet." "Our contact form goes to somebody who left in 2024." "Every pay run takes a full Sunday." The pain points are usually specific and small.
- 03
Who else uses this?
Employees. Contractors. Customers. Regulators. Suppliers. Family members. Each user has different needs, different permissions, different tolerance for friction. A tool for you alone is a very different tool from a tool five contractors will log into every week.
- 04
What rules do you actually have to follow?
Regulator names, compliance regimes, contract clauses, industry standards. "SCA on our USPS contract." "HIPAA-adjacent, we handle scheduling but not medical records." "California AB-5 for our tipped staff." Rules drive the schema before the schema drives the UI.
- 05
What tools do you already own that we should reuse?
Domains. Cloud accounts. CRM, accounting, or email tools that already work. Data in a spreadsheet you've been maintaining. We build around what you already own, not on top of a fresh stack.
- 06
What would make this obviously worth it?
The outcome, not the feature. "I don't have to spend Sunday on payroll." "A DOL inspector can read our records on the first request." "New contractors can sign up without emailing me." The outcome disciplines what actually needs to ship.
- 07
What's the honest budget shape?
A range is fine. "Under $10k." "Not more than a mid-market SaaS annual bill." "Whatever it takes." Knowing the shape lets us scope tighter to fit, instead of underbidding and cutting corners.
From answers to a written scope
After the seven questions, we have enough to draft a real scope. The template we use is boring on purpose — boring scopes ship on time.
Section 1 — What ships
- Named features, in plain English
- The user roles that can do each thing
- The specific tools we're integrating with
- The compliance line we're building against
Section 2 — What does not ship
- The things that would be reasonable to want but aren't in this scope
- The categories we're explicitly saying no to (tax filing, money movement, etc.)
- The "phase two" features that we'd requote separately if you want them
Section 3 — Timeline
- Start date, contingent on signed scope
- Milestone dates for the visible chunks
- Handoff date
- Buffer, if it's a build with real unknowns
Section 4 — Price
- One number, fixed
- 50% up front, balance at handoff
- What triggers a requote (scope growth, new integrations)
- What's included in ongoing support
That's the whole document. One to two pages. You read it, we clarify anything that's not clear, and you sign it or you don't. Nothing else starts until you sign.
Common scoping mistakes
These are the traps we watch for in the first conversation. If we notice any of them in what you're describing, we'll flag it out loud.
Feature list masquerading as a scope
"We want a login page, a dashboard, a settings page, a..." That's not a scope, that's a UI shopping list. What does the operator need to DO on the dashboard? What decision does it help them make? Features without outcomes always over-scope.
Scope creep by adjective
"Just make it flexible." "It should be scalable." "We want it to be intuitive." Those words each add 30% to the estimate because they mean everything to some stakeholder and nothing to the builder. If a word doesn't translate to a concrete design decision, cut it.
Solving the wrong layer
"We need a new CRM." Do you? Or do you need one specific report your current CRM doesn't produce? A $500 report often replaces a $50,000 CRM migration. We'll ask before scoping.
Compliance by rumor
"Someone told us this needs to be HIPAA compliant." Sometimes that's right, often it's not. Rules are specific: 41 U.S.C. §§ 6701–6707 governs SCA payroll; HIPAA governs Protected Health Information as the regulator defines it. If you don't know the specific statute, we'll help you find out.
Building for imaginary users
"Eventually the whole team will use this. Then subcontractors. Then customers directly. Then a partner reseller channel." That's a five-year roadmap in one conversation. Ship for the user who exists this month. Ship for the imaginary user in a phase two that costs its own scope.
A concrete example, start to finish
Here's a hypothetical (composited from real orientations we've done). Names are made up; the shape is real.
"Hi — I run a small commercial plumbing outfit in Denver. Three trucks, six plumbers. Everything is in QuickBooks and my personal email. When customers call me for an estimate I'm looking through my inbox to find similar past jobs. I don't need anything fancy. I think we need something."
After the seven questions, the scope that came out looked like this:
Written scope — plumbing operator
- Ships: a private password-gated dashboard at
yourdomain.com/opswith a searchable job history (customer, address, scope of work, final invoice, date), an "estimate this new job" form that pre-fills from similar past jobs, and PDF export. - Does not ship: a full-blown CRM, dispatching, plumber time tracking, QuickBooks sync (the operator will keep pasting into QB manually — cheaper than integrating).
- Timeline: live in ten business days.
- Price: fixed, in the $6k–$8k band. 50% at signing.
- Optional next scope: Plumber-facing mobile view; QuickBooks two-way sync; customer-facing quote acceptance. Each quoted separately if the operator wants them.
None of that requires a "spec." The conversation surfaced everything the scope needed. The operator signed it two days later; the build shipped on day 11.
What to do next
If you have a rough idea and no spec, do this:
- 01
Write a single paragraph
In your own words, describe what the business does and what you'd like to change about it. One paragraph is plenty. It's the first sentence of your future scope.
- 02
Email it to us
[email protected]. A real person replies within one business day.
- 03
Book the one-hour orientation
Zoom or phone, whichever you prefer. We walk through the seven questions in real time. If you'd rather not book yet — call us and try the first two questions right now, on the phone.
- 04
Read the written scope when it lands
One to two pages. What ships, what doesn't, timeline, price. If it matches what you actually need, you sign. If it doesn't, we iterate. Cost so far: zero.
If you'd rather see this in practice before you commit to a call, our SteadFast case study walks through a full engagement start-to-finish, including the actual scope we wrote and shipped against.