You don’t need a 40-page spec to start

You don’t need a 40-page spec to start a SaaS or ops build with a serious partner. What you need is a clear problem, who has it, and what “working” would mean for a first release. A novel BRD often delays that clarity and locks in the wrong assumptions before anyone has clicked a real screen or watched a real user fail.

Why the big spec fails early

Early-stage UK founders and SMB buyers get stuck polishing Notion docs and RFPs because someone said no agency will talk without a full requirements pack. I’ve seen 40-page specs that were already wrong by week three: workflows nobody uses, integrations that can wait, and must-haves that were really nice-to-haves in a suit. Writing becomes a substitute for deciding. Meanwhile the spreadsheet or agency handoff keeps costing money, and the document gets another polish pass nobody will read on day one of build. Procurement theatre feels safe. It rarely makes the first release sharper.

The other extreme is “just build something” with no user in mind. That burns calendar too, and you still discover the real requirements only after something is live enough to hate. “No spec” is not “no thinking.”

What to bring instead

Bring the problem in a few sentences. Who pays or who uses it. What happens today without the software. What would count as it working for a first release. Rough timing and budget if you know them. Missing half of that is fine; we will ask the awkward questions on the call. A good partner’s first conversation is half the value: turning a vague idea into something specific enough to price.

That is the Eight Mile SaaS line in practice: you do not need a spec; you need someone who has done this before. Soft path when the work is a slice of a larger build: software development. Path is short email, conversation, survey, fixed written price for the first release. You own code, accounts, and data from the first commit, not after a handover ceremony.

What is still not optional

Ruthless must-haves for v1. One primary user. One core workflow. A boundary for what waits until release two. If everything is priority one, you do not have a first release; you have a wishlist. Name the scary bits early (payments, permissions, data that must not be wrong) so they sit in the price, not in a surprise change request. Leave the UI novel and the edge-case catalogue for after there is a link to argue with. That is when the real requirements show up.

From a few sentences to a fixed price

We shape screens and the data model in plain English, name the risky parts, and give a fixed price for the first release before an hourly meter runs. Then a working link you can open, usually early enough to steer, on your own accounts. No process essay required. No 40-page gate between you and a number you can say yes or no to. If the budget and the product do not meet, we say so early rather than build two-thirds of something.

Start without the novel

If you have been waiting until the document is perfect, you don’t need a 40-page spec to start. You need a partner who will make the idea priceable on the first call.

Describe the problem. Name who has it. Draw a hard line for v1 and leave the rest for later.

If you want that conversation, contact Eight Mile and send three or four sentences about the problem and who has it today.