Most of the people who reach out to us don’t have a spec. They have a problem, a deadline, and a vague sense that software could fix it. “We’re drowning in spreadsheets.” “Our booking flow loses people.” “I have an idea but I don’t know if it’s a two-week job or a six-month one.”
That last one is the question we actually answer.
One call, thirty minutes, no deck
We’re not on that call to sell you a process. We’re there to find out what the software has to do and who has to use it, which takes about three questions.
- What does the person using this need to get done, and how do they do it today?
- What’s the one thing that, if it worked, would make this worth building?
- What’s already in place? A CRM, a payment processor, a pile of Google Sheets, a site somebody built in 2019 that nobody has touched since?
The third answer is usually where the actual work lives. Anyone can build a booking form. Building a booking form that writes into an accounting system a bookkeeper already trusts is a different job with a different price, and you only find that out by asking early.
We’re listening for the shape of the thing, not the feature list. A feature list written before anyone understands the problem is a guess with bullet points, and estimating one is astrology.
Then we cut it
After the call the work happens on our side, and most of that work is subtraction. We take what you told us and draw a hard line through it: what has to exist for version one to be useful, and what is genuinely a later.
This is where projects go wrong, and they go wrong in a specific way. The dream version is easy to scope, because nobody in the room has to say no to anything. Everything is in, everyone leaves happy, and the estimate is a number that nobody believes, including whoever wrote it. Two months later the thing that mattered is half-built, because the thing that didn’t matter ate the sprint.
We’d rather have that argument at the start. When we cut something, we tell you what we cut and why, in writing, and you get to put it back.
The estimate itself comes from whoever would build it. Not from an account manager applying a safety multiplier to an engineer’s guess, and not from a template. If it turns out to be wrong, the person who got it wrong is on the project.
You get a document, not a proposal
What comes back is short: what we’re building, what it does, what it doesn’t do yet, and what it takes to get there. It’s deliberately unglamorous. There’s no slide with an iceberg on it.
We can skip a long discovery phase because we’ve shipped more than 100 projects and most requests rhyme with something we’ve already built. A booking system. An internal dashboard. A customer portal. An automation that deletes a job somebody hates. The details differ every time. The failure modes barely do.
The part we’ll argue about
We think most discovery phases are billing dressed up as diligence.
Weeks of workshops before anyone writes code produce a beautiful document and a project that has learned nothing, because software teaches you things by being run, not by being described. The fastest way to find out whether a scope is right is to build the smallest honest version of it and put it in front of someone who has the problem.
So the scope we send you isn’t meant to be complete. It’s meant to be decidable: yes, no, or make it smaller. All three of those are good outcomes. Drifting for a quarter without any of them is not.
If you’ve got a rough idea and want to know what it really takes, tell us about it.