Product · Mar 6, 2026
Why We Build a Prototype Before a Proposal
What you see after the first call, and why the first thing you say about it is usually "that part is wrong".
By Jakob · 4 min read
We build a prototype before a proposal. After a first conversation, we turn the one workflow your business depends on most into something you can click, usually within 24 hours, and it runs on the real logic of how you work.
The Problem With Proposals
A proposal is a document about confidence. It says what we will build, what it will cost and how long it will take. What it rarely shows is proof that we understood you.
- Beautifully formatted
- Cites a methodology
- Includes a project timeline nobody opens after week two
- Asks for the money now and promises clarity later
- Leaves you judging us from a document
- Something you can click and try right away
- Built on your own business logic
- Rough design, real sequence
- Gives you clarity before you pay anything
- Turns a sales meeting into a working session
A proposal asks you to pay for clarity that arrives later. We put the work first, so you can see whether we understood you before any money changes hands.
What Happens After the First Call
Once the call ends, we go away and build. We listen for what we call the Red Line. It is the one workflow that would make everything else run smoother if it worked better.
That Red Line becomes something you can click through and try. There is no real data yet and the design is rough. The steps and decisions are real, and those are what you are judging at this stage.
You see your own process reflected back as a tool, with the steps, decisions and outputs your team deals with every day. Then, usually within thirty seconds, someone points at the screen and says "that part is wrong."
Why "Wrong" Is the Goal
When a client tells us part of the prototype is wrong, three things happen at once: they show that they understand what we built, they name a part of their process nobody mentioned in the meeting, and they start working on it with us. The third change matters most, because a client who is correcting our work has stopped judging us from the outside.
By the time we send a proposal, the client has clicked through the software it describes. The proposal summarises decisions we made together.
What a Prototype Before a Proposal Costs Us
Building first costs us time up front, and we don't always get it back. Some clients take the prototype, thank us and disappear. We've made peace with that.
The other path worries us more. There, a client pays for months of development on a foundation nobody tested, because everyone was too polite to question the logic before the contract was signed.
The prototype is how we protect both sides of the table.
Added in October 2026. Building first is now the sales step of Competify, our own software for running awards programmes. An organiser describes the competition in a few sentences, we build a first version of their portal in which every role works, and they decide whether to go on after they have seen it. How we ship describes the ready-made parts every project starts from, and what we built since March covers the rest of the year.
If your last software project started with a proposal and ended with something your team barely uses, the gap most likely opened before the work began. It sits between what was written down and what your team needed.
If that sounds like a conversation worth having, tell us what you need built. We'd like to have it before anyone writes a line of a proposal.
Stay in the loop
Don't miss the next one.
One email when we publish something worth your time.