Contact
One address, read by the people who do the work.
There is no form here, no routing, and nobody in between. Email arrives with the people who would build the thing you are writing about.
Write to us
We reply to everything, usually within a couple of working days. If we are not the right studio for what you need, we will tell you plainly and point you somewhere better where we can.
Making it a useful first email
Four things worth including.
None of these are required. All of them save a round trip.
- The problem, not the solution. What is going wrong today, and for whom. If you already have a specification we will read it, but we will still ask this.
- Who it is for. Internal team, customers, or both — and roughly how many of them.
- What has been tried. The spreadsheet, the previous vendor, the off-the-shelf tool that did not fit. Knowing what failed is worth more than a requirements list.
- Timing and constraints. A real deadline, a budget range, a regulation, a system that cannot be replaced. Constraints make an estimate possible.
What are you writing about?
You have something to build
A product, an internal tool, a platform, or a problem you suspect is a software problem. Send what you can — a specification is not required and is often less useful than a description of what is currently going wrong.
Subject: Project enquiry →You are not sure what to build yet
This is the most common and most useful place to start. A discovery sprint is fixed in scope and fee and ends in a written recommendation, occasionally including a recommendation not to proceed.
Subject: Discovery sprint enquiry →You want to work here
No roles are posted, and applications are still read. One email, a link to something you made, and one decision you would defend.
Subject: Application →Something else
Press, partnerships, a correction to something we wrote, or a disagreement with an essay. All of it reaches the same place.
Subject: Hello →Ways to work together
Three shapes an engagement takes.
Discovery sprint
Fixed scope, fixed feeYou have a problem and competing opinions about the solution.
Build partnership
Milestone-basedYou know what needs building and need a team that will finish it.
Product ownership
OngoingYou need the product to exist and run, without hiring a team to do it.