Blueprint
Internal Workflow
Systems that do the work without anyone opening a page.
Systems that run without anyone opening a page. They pull data, move it between services, and do work on a schedule.
Most of these have no screen at all. Nobody logs in, nobody clicks anything, and the only evidence they exist is that the thing you used to do by hand is already done. That is the point of them, and it is also why they are invisible in a portfolio in a way the other three are not.
The largest one I run is my own: a substrate holding the context of both my businesses, connected to everything I use, running the recurring work of each. It is the reason this blueprint exists, and a proper breakdown of it needs more room than a stack list.
How I orchestrate the build
Editor
Where I sit. Claude Code runs inside it, so the work and the code are in one window.
Orchestration
Does the actual building. I describe the change, it writes it, I review it.
Building from my phone
Same project, away from the desk. Useful more often than it sounds.
Input (I don't type)
I talk, it types. Dictation that keeps up with a train of thought.
What it's built with
Language
Boring on purpose, and the deterministic half of the job. The model decides, then something predictable does the actual work. Every service has a library for it and the code still runs in five years.
Judgment inside the run
Not just for building it. Some jobs call the model while running, when a step needs a decision rather than a rule. Reading a transcript and naming the chapters is a decision.
Talking to other services
A thin client for each API, written once and reused everywhere. The API is the surface, never a browser automation pretending to be a person.
Where the code lives
The working copy
The real one. A directory in my projects folder on this computer, where the work actually happens.
Version control
Every version of every file. Also how the cloud half of this gets deployed.
Where the data lives
The master
One file. No server to run, no connection string, and it opens in anything. For a single-operator system this is the right size, and almost nobody believes that until they try it.
The cloud mirror
The same data pushed up so anything hosted can read it. The local file stays the source of truth, which keeps the sync one-directional and therefore debuggable.
Off-site backup
The whole thing on a schedule, somewhere that is neither this computer nor Cloudflare.
Where it runs
On the desktop
Unglamorous and completely reliable. It wakes the machine, runs the job, and logs the result. Anything needing local files, local models, or a session I am already signed into runs here.
In the cloud
For anything that has to run whether or not this computer is awake, or that needs to answer a request coming from the internet.
How it reaches me
When something needs a person
A direct message, not another dashboard. The whole point is that I do not go looking, so when a job genuinely needs a decision it comes to where I already am.
For anything that should be a record rather than a ping. Failures, digests, and things worth searching for six months later.
The questions that come up
The least glamorous of the four blueprints and the one that changes a business the most, which is roughly the inverse of the attention it gets.
- Q Why not Zapier, Make, or n8n?
- They are genuinely good at the first version, and I stop reaching for them the moment the logic gets real. Three reasons. Pricing is per task, so success gets expensive at exactly the wrong moment. Branching and error handling in a visual builder is harder to read than the equivalent twenty lines. And you cannot diff a canvas, so you give up version control, review, and any ability to see what changed. Plain code costs nothing to run and every tool already knows how to read it.
- Q Isn't this just cron jobs?
- The scheduling part is, and that is a feature rather than an insult. What makes it more is the layer around it: one reusable client per service instead of a script that knows how to log in, a shared store every job reads and writes, and an explicit rule about what each job may do alone. The schedule is the least interesting part.
- Q Why does it run on your desktop instead of a server?
- Because a lot of it needs to be me. Local files, local models, a browser already signed in, a subscription tied to this machine. Renting a server would mean recreating all of that badly and paying monthly for the privilege. The parts that genuinely cannot depend on one computer being awake run in the cloud instead, which is the split above.
- Q How do you know when one breaks?
- Every job reports whether it finished and what happened, and a failure reaches me instead of sitting in a log I would have to remember to open. That is the part people skip, and it is the whole difference between automation you trust and automation you quietly stop believing.
- Q How much of this decides things on its own?
- Less than people assume, and deliberately. Recording something that already happened is safe, so it happens silently. Preparing something, like drafting the reply into the thread, happens automatically but waits for me. Sending anything outward, or making a judgment call, does not happen without a human. Writing that line down explicitly is what makes it safe to let everything else run unattended.
- Q Do you need a whole system before you can build one?
- No. A single script that does one job on a schedule is worth having by itself. But the order is worth knowing, because mine did not happen the way people assume. I did not accumulate automations until they turned into a system. I built the system first, because my context was scattered across a dozen tools and I wanted one organized place to run the business from. The automations came after, and they are better for it: a job that already knows where the clients, the projects, and the history live can do far more than one that has to be handed everything every time it runs. You can absolutely build these without that. They are just smaller.
- Q Can a client have one of these?
- It is usually the most valuable thing I build for anyone, and the hardest to sell, because there is nothing to look at. No homepage, no screenshots. Just work that used to take somebody four hours a week and now takes nobody any time at all.