A picture is worth a thousand words. A prototype is worth a hundred slides.
I have worked in software for more than 25 years. For most of that time, every feature started with an SRS, a software requirements specification.
This week I decided to start a project without one.
A coherent document takes time
The idea behind an SRS is sound. Write down what you want before engineers spend months building it. Changing a document is cheap; changing code is expensive.
In practice, a good SRS takes a lot of time. The bigger it gets, the harder it is to keep it coherent: one section says one thing, another says something slightly different, and sometimes we found the conflict only when the code was already written.
So on later projects we stopped relying on words alone. We drew wireframes and made PowerPoint presentations, because some things were simply too complex to explain in text. Then Figma let designers link screens into a clickable prototype.
What I did instead
I'm working on a new business process at Onix that needs support in our internal ERP.
We had a short discussion in Slack and in a Google Doc. The next step, the way I have done it for 25 years, would have been an SRS.
I decided not to write one.
I opened Claude Code and dictated what I wanted. In about an hour and fewer than ten prompts, I had a working prototype on a server.
My colleagues are already testing it, and they'll give me feedback in two days. Instead of discussing what the system should look like, I get real results from my "customers", the people who will use it. The conversation is about where it conflicts with how people actually work, and how we fit it into the process. I hope it also shortens the integration.
Last week I wrote that a manager can build the prototype and a software team can finish it. This is the first half of that, from my own week.
I don't care if it goes into the trash
Speed is only half of it.
The most important part of delivering something new is explaining the idea: why we need it and how it will affect the business. From a specification, that is often not clear. From a working prototype, people see it.
I haven't spent days or weeks coding this. So if we throw the code away, I won't miss it. I have no personal attachment to it.
That changes the conversation. When a team has spent three weeks building something, every comment feels like criticism of their work, and the first version tends to survive because of the effort already spent on it. When a prototype costs an hour, nobody defends it. People argue about the process, which is what we actually need to decide.
So are specifications really dead?
The prompts I dictated were a kind of specification too. The difference is who reads it. The machine reads my words. People look at the result.
Of course, I'm exaggerating. A large project that needs work from several teams and has to comply with different standards still needs a document to build the product roadmap on.
But the industry is changing, and it's more than the tools. The way we build software today is different. This is where experience comes in. If I hadn't been in this industry for so long, I couldn't have prompted the system this precisely and got it live this quickly.
The engineer's mind is still needed. The tools are different.
Who builds the first prototype in your company today: the manager, the designer, or the engineers?
First published on LinkedIn. Discussion on LinkedIn