Design
We redesigned Vela four times before writing a single line of code
Most teams rush to build. We spent three months designing — and throwing away — the product. Here's every version, why each one failed, and what we finally got right.
Zoe Dabere
7 min read
•
There's a version of this story where we moved fast, shipped early, iterated in public, and got to a great product through sheer velocity. That's a good story. It's also not ours.
Our story is messier. We designed Vela four times before we felt confident enough to build it. Each version taught us something the previous one couldn't. And looking back now, every scrapped design was necessary — not a failure, but the only honest path to the one that finally felt right.
Here's the full breakdown. Version by version.
Version 1 — "The everything app"
The first version of Vela tried to do everything. One unified workspace with a notes panel, a task panel, a calendar view, a document editor, a communication layer, and an AI sidebar that could answer questions about any of it. Ambitious. Technically coherent. Completely wrong.
The problem wasn't the features. The problem was that we'd built a solution and then tried to find a user for it. When we put V1 in front of five founders, the feedback was consistent: it felt like a tool built for a concept of productivity rather than the actual experience of being a founder trying to think clearly.
"This is impressive. I would never open it in the middle of a busy day."
That line — from a founder in Lagos who runs a 12-person fintech startup — ended V1. The worst thing a productivity tool can be is the tool that requires you to be productive before you can use it. V1 was exactly that.
Version 2 — "The minimal core"
We overcorrected. V2 stripped everything back to a single input field and a list. Inspired by the tools we actually kept open — a plain text editor, a running list in Apple Notes — we built the most minimal version of Vela we could imagine. One text box. Hit enter. It becomes an item in your list. That's it.
It was fast. It was frictionless. And it was completely indistinguishable from a notes app. There was no reason to choose Vela over the tool someone already had. We'd removed so much that we'd also removed the point.
The lesson: simplicity is not the same as purposelessness. A product can be minimal and still have a clear reason to exist. V2 was minimal and shapeless — and those are very different things. |
Version 3 — "The smart inbox"
V3 is the version we were most excited about and most wrong about. The idea: a single inbox where everything comes in — thoughts, tasks, links, voice notes, emails forwarded from your work account — and Vela uses AI to sort, categorise, and prioritise it all automatically. You just review and action. The AI does the cognitive labour.
We built a working prototype. We were genuinely proud of it. Then we watched seven people use it.
Problem 1 |
People didn't trust the AI's categorisation. Even when it was correct, they wanted to verify it — which eliminated the time saving entirely. |
Problem 2 |
Mixing emails, tasks, and thoughts in one inbox created a new kind of cognitive overload. Instead of reducing noise, we'd just moved it. |
Problem 3 |
The forwarded email integration broke twice during the prototype sessions. When a productivity tool stops working, trust collapses faster than it was built. |
V3 taught us the most important lesson of the whole process: AI assistance needs to feel like it's working with you, not for you. The moment a user feels like they've lost control of their own information, they stop using the product. Full stop.
Version 4 — "The processing layer"
By V4, we had stopped trying to solve everything. We had one specific question: what is the single moment in a founder's day where the most thinking goes to waste?
The answer, from everything we'd observed across three failed versions, was always the same: the moment between having a thought and doing something with it. Capture is easy. Processing is where the wheels come off.
V4 was built around that one moment. You write or say something raw. Vela asks one clarifying question — sometimes zero questions. Then it structures it: what kind of thing is this, what needs to happen, when, in what context. It doesn't take over. It takes the structural load off your brain so your thinking can stay where it belongs.
This version we didn't want to throw away. For the first time, every person who used the prototype said some version of the same thing: "When can I actually use this?"
What the four versions actually cost us
Month 1–2 |
Version 1 — Built and scrapped |
Six weeks of design and prototyping. Five user sessions. One brutal piece of feedback that changed everything. |
Month 2 |
Version 2 — Built in one week, scrapped in two |
Fast to make, fast to kill. Learned what "too minimal" actually means. |
Month 2–3 |
Version 3 — The exciting wrong idea |
Four weeks. Seven prototype sessions. The most painful scrapping — because we were so convinced it was right. |
Month 3–4 |
Version 4 — The one we're building |
Still in progress. Finally feels like the product we were trying to make all along. |
Why we're telling you this
Because the startup narrative — move fast, ship early, fail fast — is true and also incomplete. Sometimes the fastest path to the right product is the slow path through the wrong ones. Not because failure is romantic, but because there are things you genuinely cannot know until you've built something and watched a real person try to use it.
We could have shipped V1. We'd have gotten users. We'd have gotten data. We'd also have gotten users habituated to a product we already knew was wrong, building a company on a foundation we'd have had to demolish eventually anyway.
The four versions cost us three months. They saved us, we think, from years of building in the wrong direction.
V4 is what Vela is now. It's what you'll get access to when the waitlist opens. And if we've learned anything from this process — it'll probably still need to change. We'll tell you when it does.
