How long is a typical Specloop specification?

Most specs are 8 to 30 pages. A focused single-purpose app might be 6 pages; a full SaaS MVP is closer to 25. The goal is 'complete enough to build from,' not 'long.' Every section earns its place.

Who writes the specification?

We do. After a 30-minute scoping call (and a written brief from you), our team drafts the full document. You read it, mark it up in plain language, we revise, you approve. Two rounds is typical; the whole process takes 2–3 business days.

What if I don't know exactly what I want?

That's normal — and exactly what the spec process is for. We ask the questions that surface the decisions you haven't made yet: who the users really are, what the must-have workflow is, what AI is supposed to do when it's wrong. The spec is how you find out.

Can I share the spec with my team or investors?

Yes — it's your document. Many founders share the spec with co-founders, advisors, and early hires precisely because it's the clearest single description of what they're building. Investors find it remarkably useful.

Fig. 04 — the spec engine

SpecLoop.

Our proprietary spec generation system, built specifically for AI development. It produces the deepest spec in software — a PRD, a TDD, and a sequenced Implementation Plan where every requirement traces to a schema, every schema to a service, every service to a numbered build task. As deep as the build demands.

What a Specloop spec contains

A Specloop specification is a single document — typically 8 to 30 pages — written in plain language with technical sections where they matter. It is the source of truth for the build and the contract for delivery. Once you sign off, the scope, price, and timeline are fixed.

Every spec contains, at minimum, these sections:

§ 1 — Summary & outcomes

One paragraph that names the product, the user it serves, and the outcome it produces. If we can't write this paragraph clearly, the rest of the spec doesn't matter.

§ 2 — User roles & permissions

Every role that exists in the system, what they can see, what they can do, and what they can never do. Row-level security policies are derived directly from this section.

§ 3 — Data model

Every table, every column, every relationship, every index that matters. We sketch the schema before we sketch the UI because the data model is what the app actually is.

§ 4 — Workflows

Every meaningful user workflow described step by step, with branching for error states. This is the longest section in most specs and it's the one we revise most carefully — because workflows are where vague ideas turn into shippable behavior.

§ 5 — Pages & screens

Every page in the app, every meaningful state of every page (empty, loading, error, filled, success). What's on it, what it links to, who can see it.

§ 6 — AI behavior

For AI features: model choice, prompt shape, expected output, what happens when the model is wrong, cost ceilings, evaluation criteria. AI features that aren't specced this way break in production.

§ 7 — Integrations

Every third-party system the app touches: which endpoints, which webhooks, how auth is handled, what failure looks like, how retries work.

§ 8 — Acceptance criteria

The literal definition of done. Concrete, testable, written in advance. "When all workflows in § 4 complete end-to-end on staging and RLS is verified for each role, the build is accepted."

Why we write the spec first

Most software fails not because the team couldn't build it, but because nobody wrote down what was being built. Slack threads, Figma comments, and verbal agreements all decay; the spec doesn't.

Three direct consequences of writing the spec first:

Fixed price. We know what's in scope, so we can quote a flat number. You know what you're paying, in writing, before any code is written.
Fixed timeline. The spec is the schedule. There's nothing to discover mid-build because the discovery happened during the spec.
Lower rework. Most rework comes from misaligned assumptions. A spec surfaces those assumptions before they become code.

What the spec doesn't do

The spec is not a Figma file, not a Jira backlog, and not a one-pager. It doesn't include pixel-perfect mockups (the design system handles that), it doesn't enumerate every bug to fix, and it doesn't pretend the future is fully known. It's a written contract for the first version of a working product.

Fig. 04.02 — sample

Read a real one.

Don't take our word for it — read an actual SpecLoop deliverable. This is an abridged, anonymised blueprint from a real engagement: roles, data model, workflows, AI behavior, acceptance criteria. Page through it inline, or download the PDF and take it with you.