Small teams

Move fast, and still know what your product does.

A five-person startup does not need a requirements process. The developers know what to build and they ship every day. What the rest of the team needs is simpler: to know what changed, and whether the product still works the way everyone thinks it does.

21 October 2026 · 5 minute read

A team that moves fast on purpose

Picture a startup of five. Two developers, a salesperson, a CEO who is also the product owner, and founders who share the rest. The developers are deep in the product. They know what the customers need, and they write a great deal of code. What they know lives in Slack threads and in Zoom meetings that nobody wrote down. Some changes come with a ticket. Some come without one. Some tickets are opened by the developer afterwards, so that there is a record.

That is not a problem to fix. It is a large part of why a team this size moves faster than a company ten times its size. Nobody has to write requirements for people who already know what to build, and asking them to would cost more than it returns.

The gap is not in the code

The code is in good hands. What is missing is a view of the product for everyone who is not reading the code, and in a small company that is most of the company.

The CEO owns the product and wants to know that it is going where they intend. Changes reach them at stand-up, or when a customer mentions one.
Sales needs to know what is new and what can be promised on tomorrow’s call. Today that means clicking around the product, or asking a developer in the middle of their work.
The founders need to know that everything works as expected, and to be able to say what the product does when an investor or a customer asks.

Tickets opened afterwards help, but they record what a developer remembered to write down. They are a diary of the work, not a map of the product.

A change nobody announced

A small change in a big commit

A developer cleans up the billing code and, on the way, shortens the free trial from 14 days to 7. There is no ticket. It is a few lines in a larger commit.
Two days later, sales promises a 14-day trial on a call.
The customer signs up expecting 14 days, and gets 7.

Nobody was careless. The developer made a reasonable call, sales shared what they knew, and the customer trusted what they were told. What was missing was one place where the product’s behaviour is written down and kept current, so the change could be seen when it happened.

A specification that nobody has to write

SpecTrail reads the repository and writes the specification in plain language: user stories with acceptance criteria, grouped by epic and feature. Each statement carries small marks for the code behind it and the tests that cover it. Nobody on the team writes it, so it costs the developers nothing.

From then on, each merged pull request is compared with the specification by meaning, not by lines. When a change alters what the product does, SpecTrail flags it soon after the merge, with the change itself in plain words: the free trial lasts 14 days became 7 days. A person looks at one card and decides to accept it, reword it, or deny it and ask for a fix. Changes that leave the product as it was pass quietly, so a day of commits does not turn into a day of notifications.

What each person gets

The CEO, who owns the product
A short list of the changes that alter what the product does, each one to accept, reword or deny. You stay the owner of the product without reading code or joining every review.
Sales
The product described in plain words, with what is new and what changed. Demos and promises match the product that is actually running.
The founders
A map of what the product does today and which behaviours have tests behind them, ready for the next customer, investor or hire who asks.
The developers
Nothing new to write. Keep shipping the way you do now, with tickets, without them or with tickets opened afterwards. The specification follows the code.

Knowing that it works as expected

The marks beside each statement show which behaviours are built, which are covered by tests and which only partly. For a team without a QA role, that is a quick answer to a question that is otherwise asked by feel: which parts of the product can we change with confidence, and where should the next test go?

When the team grows

The same specification is what a new hire reads on their first day, what the first QA engineer starts testing from, and what a customer’s security team or an auditor asks for later. The habits that make a small team fast stay in place, and the record of the product grows alongside them. See how this plays out in startups that are growing up.