Most software agencies build products and hand them over. We build products and then run them — including our own. ChiliAuto, Billwaze, MoonBeauty, MoonLinks and four others. All live. All maintained by the same engineers who will work on your product. This is a deliberate choice, and it changes everything about how we build.
The 2am test
When you build a product and hand it over, you never have to deal with what happens at 2am when it breaks. The client deals with it. The support team deals with it. You move on to the next project.
When you operate the product yourself, 2am is your problem. And the way you respond to that reality changes every decision you make during the build: the monitoring you set up, the alerts you configure, the runbooks you write, the architecture choices you make to avoid the 2am call in the first place.
We've had the 2am call. It makes you a better architect than any methodology.
What operating our own products teaches us
Every assumption you make during the build gets tested in production. Some of them are wrong. The ones that are wrong become expensive — in engineering time, in user trust, in the 2am call you have to make.
Lessons from operating ChiliAuto (our moving marketplace):
- Push notification timing is a product decision: our 5-minute accept window was too short for field crews. We extended it to 10 minutes and acceptance rates increased 40%.
- The first dispute teaches more than the first 100 bookings: we rebuilt the evidence upload flow after the first disputed job revealed gaps in our assumptions.
- Supply density is an operational metric, not a launch metric: we use the admin heatmap weekly to identify thin coverage areas before customers notice.
Lessons from running Billwaze (our billing SaaS):
- Billing errors are existential: a wrong invoice in a billing platform destroys trust. We added a staging preview email to every MSP before invoice delivery.
- Churn interviews are more valuable than active user feedback: the users who left told us what the users who stayed had adapted around.
- Multi-currency is never done: every new country reveals a tax or format edge case.
How it shows up when we build for you
We write runbooks because we've needed them. We configure monitoring before launch because we've been the ones without it. We set up staging environments from week two because we've learned what happens when QA only happens in production.
We push back on features that seem reasonable but introduce operational complexity — because we've supported those features at 2am and know what they cost. We design for the support engineer as well as the user.
Most agencies give you software. We give you software we'd be willing to put our own name on and run ourselves. The bar is different.
The skin-in-the-game argument
There's a simple filter for evaluating a software agency: would they be willing to operate the thing they're building for you? Not maintain — operate. Handle incidents, manage deployments, be responsible for uptime.
If the answer is no — and for most agencies it is, because operating software is hard and ongoing and exposes every shortcut taken during the build — that tells you something about the quality of the decisions that will be made during the engagement.
We operate eight products. The team that will build yours has been paged at 2am for their own code. The standards are not theoretical.
Want to see what we operate? Look at our products — every one of them is live and maintained by the same team that will work on yours.
See our products