// let's build it
Send a brief — you'll hear back the same business day.
Tell us what you're building and what it has to do. That's genuinely all we need to start a useful conversation, and you'll be talking to the person who would do the work.
// what to put in it
A useful brief is about five sentences.
Not a specification — we'll write that with you. Enough for us to tell you honestly whether we're the right team.
What you're building
The system and the business it serves. One paragraph is plenty.
What it has to do
The two or three things that would make it a failure if they didn't work.
What exists today
A running system, a prototype, spreadsheets, or nothing yet. All four are normal.
Constraints that are real
A date, a compliance regime, an incumbent stack you have to live with, a budget shape.
Who we'd be working with
Whether there's an in-house team, and whether they'll own it afterwards.
You get a reply the same business day from a senior engineer, not a form response. If we're not the right fit we'll say so in that first reply rather than booking a call to find out.
// straight answers
Before you write it.
- Do you take small projects? Yes, if they're real. One service end to end is our preferred way to start with a new client — see how an engagement begins.
- Can our team own the code afterwards? That's the intended outcome. The specification is the handover artefact, and it's readable by people who didn't write the system.
- Do you work with an existing in-house team? Regularly. We work behind your gates, in your process, on your infrastructure.
- Why don't you name your clients? Most of our work is under NDA and we'd rather respect that than trade it for a logo wall. The work is published with its architecture and its numbers, which is the part that tells you something.
- Is there anything we can actually try? Yes — Mines is ours, it's on the App Store, and it's the same team.