How We Build
The Production Stack
The system behind the work. A framework for building automation that holds up when it actually matters.
There are two ways to build an automation system.
The first way is to connect the tools. Get the data moving from A to B. Make it work in testing, show it working in the demo, and call it done. This is how most automation work gets done. It is fast. It is cheap. And it works, until it does not.
The second way is to understand the system underneath the tools. To think through what happens when two events arrive simultaneously. What happens when the API is down for four minutes. What happens when someone renames a field in the CRM without telling anyone. What happens when a bulk import fires 200 webhooks in three seconds and they all hit your endpoint at the same time.
We build the second way. Always.
This is not a checklist or a set of templates. It is a way of thinking about automation that changes every decision we make, from how we scope a project to how we hand it off.
The Foundation
Three beliefs. Every build.
Most automations fail in one of three ways: silently, loudly, or slowly. These beliefs are our answer to all three.
We never open a tool until the problem is completely mapped. The right system for the wrong problem is still the wrong problem. Most automation failures begin here.
Every piece of a system is designed in relation to every other piece. We never build a node in isolation. We build a chain, and we know what happens at every link when something goes wrong.
We do not ship prototypes as finished systems. Error handling, retry logic, and edge cases are designed in from the start. Not added later. Not skipped under deadline pressure.
The Principles
Five things we do not negotiate on.
Not when the deadline is tight. Not when the client says it does not matter. Not when skipping it would save three hours.
Before we write a single node, we map out what can break. API timeouts. Duplicate events. Missing or renamed fields. Bulk imports. Network interruptions. We build explicit handling for each one. A system that breaks under real conditions is not a finished system. It is a prototype with a launch date.
Real systems receive the same event more than once. Webhooks get retried. Imports run twice. Users click buttons at the wrong moment. Our systems produce the same result whether they process an event once or a hundred times. This is not optional complexity. It is the baseline for anything that touches real data.
Processing events inline breaks under load. A sudden spike, a slow API, a bulk operation: any of these can overwhelm a system that was never designed for volume. We use queue systems so that nothing gets dropped, nothing arrives out of order, and the system stays stable regardless of how much comes at it at once.
Every handoff includes documentation that explains what the system does, how it runs, and what to check if something unexpected happens. We write documentation while we build, not as an afterthought before delivery. When we hand something off, the client owns it completely. That is only possible if they understand what they own.
The measure of a finished system is whether it runs without anyone having to think about it. Not whether it impresses in a demo. Not whether it requires a specialist to explain it six months later. A system that runs quietly, correctly, indefinitely. That is what done looks like.
In Practice
The principles in the actual work
Every engagement runs through this framework before a single tool gets opened. These are not aspirational. They show up in the builds.
Building the billing automation for Notionology meant handling multiple currencies, different subcontractor splits per project, and simultaneous payment events, without ever processing a payout twice. Principles 01 and 02 in production.
See the Notionology case study →Building the CRM sync for a Smoothops client meant receiving hundreds of Attio webhook events simultaneously during bulk edits, processing every single one in order, with no duplicates and no dropped events. Principle 03 in production.
See the Smoothops case study →Every system we have handed off includes documentation detailed enough that the client could explain it to a new team member without contacting us. Principle 04, every time.
See all our work →This approach is not a feature list. It is not a justification for a higher price.
It is the honest answer to one question we ask ourselves before accepting any engagement: if this system runs in production for twelve months with nobody watching it, what breaks?
If we cannot answer that completely, we do not start building. When we can, we build something that holds.
That is what it means to build the second way.
The Principles in Production
Ready to build the right way?
Book a discovery call. We will scope the system properly before anything gets built.