Build it, then run it.
Most studios hand over a repository and a login, and walk away from the consequences of every decision they made. We keep the pager instead - and it changes the work long before launch.
- Written by
- Synodic Studio
- Published
- 2 min
There is a moment in most agency projects where the work changes hands. The final invoice clears, a repository is transferred, someone is added to a hosting account, and the people who made every decision walk away from the consequences of all of them. We have been on both sides of that handover. It is the reason we stopped doing it.
Synodic builds products and then runs them. Not as a support retainer bolted on at the end, but as the assumption the project starts from: whatever we ship, we are the ones awake for it.
Shipped is not the same as running
A launch is a single day. Running is the eighteen months after it, and that is where the actual cost of a decision shows up. A dependency stops being maintained. Traffic arrives in a shape nobody modelled. A third-party API changes a response format on a Friday afternoon. None of that is visible in a design review, and all of it is visible at three in the morning.
When the team that wrote the code is the team that gets the alert, those failures stop being someone else's problem to document and start being your own weekend. That is a remarkably effective design constraint.
What it changes before launch
Knowing we will operate something makes us build it differently, and almost always more plainly. Cleverness is expensive when you are the one paying the maintenance on it.
- Every stack choice is one we have run in production ourselves. We are not interested in finding out what a database does under load for the first time on a client's traffic.
- Monitoring and alerting go in before the first real user, not after the first outage. If we cannot see a system, we do not consider it launched.
- Fewer moving parts beats a more elegant architecture. Each service we add is another thing that can be down at three in the morning.
- If a feature can only be explained by the person who wrote it, it is not finished. Code that cannot be handed to the person on call is a liability with a nice interface.
Production is the design review. Everything before it is a rehearsal.
The trade
This model does not scale the way an agency is supposed to. We take on a small number of projects at a time, we stay with them for years, and we say no far more often than we say yes - usually because we cannot responsibly add another product to the ones we already keep alive.
What you get in return is a studio with no incentive to leave something half-finished. There is no point where our interests and yours come apart, because the thing we built is the thing we have to live with.
Working on something that fits? Tell us about it.
