5 things that go wrong when you build software without a spec

“Let’s just start and figure it out as we go.” Almost every project we’ve had to rescue started with that sentence. The problem isn’t ambition or speed — it’s the missing document. A spec doesn’t have to be sixty pages. Even one page saves months.

Here’s what breaks when the spec is missing.

1. Scope creep with no ceiling

Without a written scope, every conversation adds a feature. “Can we also add…” becomes a habit, not a decision. Three weeks in, the build is 40% larger than the budget assumes and nobody remembers when it happened.

The fix: A one-page scope brief listing what’s in, what’s out, and what’s deferred to v2. Reviewed once, signed by both sides. Every “can we also add” now has a place to go — the v2 list, not the current build.

2. Design that ships twice

Without a spec, designers build to their best guess. Engineers build to their best interpretation of the design. Halfway through, someone realizes the designer assumed a login flow and the engineer assumed a magic link. Both are half-built. Neither is right.

The fix: One sentence per screen in the spec. “User signs in with email + OTP. Success takes them to the dashboard. Failure shows the same screen with an inline error.” Not prescriptive. Just decided.

3. Backend rewrites in week 4

Data model decisions made in week 1 based on “we’ll figure it out” become the reason nothing works in week 4. Schema changes, migration scripts, half the frontend rewired to fit. Two weeks lost.

The fix: A single-page data model in the spec. Not full ERD — just the top 6-8 entities, what fields, what links. A junior engineer should read it in three minutes and know how the app thinks.

4. Missing user roles

Almost every rescue project we take on has the same crisis: “we forgot that admins need a different view than users.” Rebuild half the app, or bolt on hacks that break auth six months later. Both bad.

The fix: A one-line role table in the spec: what roles exist, what each can see, what each can do. Enforced at the API layer from day one, not tacked on when someone remembers.

5. No definition of “done”

Without a spec, “done” is a moving target. The founder demos it to a friend, the friend suggests something, the friend’s suggestion becomes work. The team ships, then keeps shipping, and nobody agrees on when we cross the finish line.

The fix: A written definition of done. “This feature ships when: X works end-to-end, tests exist, monitoring is on, docs updated.” Sounds fussy. Isn’t. Saves the last two weeks of every project.

The one-page spec

If we had to pick a minimum-viable spec template, it’s these six sections:

1. Problem — one paragraph on what the user’s current pain is
2. Users + roles — who uses this and what they can do
3. Core flows — one sentence per screen, in order
4. Data model — 6-8 entities, key fields, key relations
5. Out of scope — what we’re deliberately not building this round
6. Definition of done — how we agree it shipped

An hour to write. A month saved.

When you actually can skip the spec

Two situations:

• Genuine research prototype — you’re finding out if the tech works. Nobody’s paying you for it. Ship POC-quality, don’t call it MVP.
• True rebuild of a live product — the existing app is the spec. Ship a design doc that maps old to new instead.

Everything else — even three-week engagements — deserves a one-pager. The team that writes the spec ships two weeks faster than the team that “just starts.”