How we turned Emma’s idea into Coratelle, and became the team that develops it
Knowing a market and knowing what to build from it are two different jobs. Emma had the first. We did the second, released it in stages, and develop it with her now.
Most people who come to us know their market better than we ever will. Emma works in illustration, and has been on both sides of the same problem — sharing her own work when she’s applying for jobs, and looking through other people’s when she’s hiring.
Whether a problem is real, and worth solving, is something you learn by working in a market rather than by building software. Emma had already checked it wasn’t just her.
What almost nobody arrives with is a product. Knowing what should exist is not the same as knowing what to build first, how it should work, or how it gets in front of anyone. That’s what she came to us for.
Nobody should be asked to specify a product they’ve never built. We worked through it with Emma session by session — which parts of the idea mattered, which were assumptions, and what someone would actually need in front of them to do the thing she was describing. Each decision was talked through as we made it, so the product was decided with her rather than for her.
The decisions that matter most are the ones a client has no way of raising. Whether it holds up once real people are using it. Whether it can be added to later, or has to be rebuilt around. Those were settled first for Coratelle, because they’re the decisions that can’t be revisited cheaply.
A first release is the version that proves an idea in real use, not the finished product, and knowing where that line falls is most of what protects a budget. What Coratelle’s first release would contain, and what would follow it, was agreed with the reasoning behind it before anything was built. The scope she agreed to is the scope that got built.
None of that counts for anything until there’s something people can use. Coratelle lets people put their work together as proper pages, share them with named people in confidence, and see exactly who has looked at what.
What’s left out of a first release only stays cheap if the product was built expecting it. Coratelle’s later releases have somewhere to go, because the decisions underneath them were made with those releases in mind.
A build finishing is not the same as a product launching, and the second half of that is usually handed back to the client. We planned Coratelle’s release with Emma: rather than opening to everyone at once, it goes out in closed rounds — a controlled group at a time, with register-interest open publicly for the next intake. Anything wrong is found by a small number of people who expect to be finding it, and fixed before the next group arrives.
Owning what you paid for should be the default, and often isn’t. Emma owns Coratelle outright — the product, the code, and the accounts it runs on. We built it and hold no stake in it.
Coratelle’s first release was delivered and is in use. It has run [X] rounds of closed testing, with [Y] registered for the next.
What each round shows decides what goes into the release after it, so the product grows on evidence rather than on guesses.
Emma has a development team, which is the part most people find they need only after the handover. The people who worked out what Coratelle should be are the people developing it.
“I’d never had software built before, so I didn’t really know what to expect. Nathan took me through every decision as we made it and explained what each one meant in plain terms, so I always knew where the project was and why we were doing things a certain way. It never felt like I handed it over and hoped. They’re the team developing it now, and it works the same way.”