working draft — gets better as I learn

Is it even
worth solving?

Before you build anything, run the audit: is this a revenue problem or a cost problem, where’s the real bottleneck, what breaks if you get hit by a bus, and does the user ever feel the machinery? These are the exact four passes I run on my own portfolio before I let myself build — and the ones I once ran for a friend who thanked me and built anyway.

This is the “bottleneck audit” that was on the coming shelf — it grew up into the whole audit.

A friend asked
what I thought.

A friend — sharp, capable, someone I genuinely like — came to me wanting to build something. Custom infrastructure, from scratch, for a project the market had almost certainly already solved for a few dollars a month. He asked what I thought.

So I walked him through the audit below: the same four passes I run on my own portfolio before I’ll let myself build anything. It’s not a “no” machine — it’s a “where does the money and the risk actually live” machine. This guide is that audit. What happened after him, I’ll tell you at the end.

Where the money
and the risk live.

1 · Revenue problem or cost problem?

They look identical from the inside and need opposite fixes. If a unit of work already clears $40 net, you don’t scale it by burning twenty unbillable hours to shave $2 off the cost — you scale it by running more units. And the real arbitrage in service work was never reselling raw compute or raw hours; it’s the authority, trust, and managed convenience you stack on top of cheap, boring, reliable infrastructure. Buy the dependable commodity. Sell the judgment.

2 · Where’s the real bottleneck?

A workflow moves at the speed of its narrowest point and nowhere else. Most over-engineering is someone lovingly rebuilding a part that already works while the actual gridlock sits untouched. Rule: build custom only where the market genuinely fails your specific bottleneck. If your output queue is choking, writing software to clear that exact chokepoint is worth every hour. Standing up a custom server just to host a brochure site is a hazard cosplaying as an upgrade. Then contain the input — batch it, box it, set the operating windows — so the engine never stalls waiting on you.

3 · What breaks if you’re hit by a bus?

Anything live, commercial, or load-bearing has to survive a bad day. A system with a bus factor of one — it halts the instant the only person who understands it is unavailable — is fundamentally unsellable, because clients aren’t buying compute, they’re buying insurance. The most effective setups are boring and modular: legible under pressure, offline-capable, repairable by someone who isn’t you. Push the fragile, baseline-stability liability onto enterprise failovers, and save your cleverness for the part that’s actually yours.

4 · Does the user ever feel the machinery?

The infrastructure should be invisible to the person on the other side. They don’t care about the purity of your tech stack; they care that the storefront never went down and the music never dropped out during the transition. Every crash, cold-start delay, and moment of dead air spends trust you can’t easily earn back. Judge the whole system by one question: does the audience ever feel the machinery? If they do, the machinery lost — no matter how elegant it was to build.

Run the audit
on your thing.

the cheapest build is the one the audit talks you out of

Pass 1 · Arbitrage

Find where the money actually lives.

  • Name it in writing: is this a revenue problem or a cost problem? What’s the evidence?
  • Find the net margin per unit — and be honest about whether you’re protecting it or chasing pennies
  • Locate the real arbitrage: what authority, trust, or convenience could you stack on cheap, reliable infrastructure?
  • Kill any plan to “scale” by shaving unbillable hours off a baseline that’s already fine

Pass 2 · Bottleneck

Only the narrowest point matters.

  • Find the single narrowest point in the workflow — the thing everything else waits on
  • Ask honestly: is anything you want to build just re-solving a part that already works?
  • Draw the build-vs-buy line: custom only where the market fails THIS bottleneck
  • Contain the input — batches, windows, scope — so the engine never stalls on you

Pass 3 · Bus factor

Clients buy insurance, not compute.

  • Run the bus test: what halts tomorrow if the one person who understands this is gone?
  • Flag every fragile, network-dependent, clever-but-brittle dependency in the system
  • Move baseline stability onto enterprise failovers you don’t have to babysit
  • Make it legible: could someone who isn’t you operate it under pressure, from the labels alone?

Pass 4 · Experience

The machinery should be invisible.

  • Walk the end-user path and mark every crash, cold start, and moment of dead air
  • Cut anything the audience can feel — nobody claps for the elegant backend
  • Choose tangible outcomes over stack purity; the user never asked what it’s built on
  • Confirm the system grows the pie — uptime, momentum, trust — not just your pride in it

He thanked me.
Then built it anyway.

Here’s the honest ending. I ran the audit clean. He listened, thanked me — and built the custom thing anyway.

That’s allowed. It’s his business, his money, his reps to buy, his version of the story to write. “Ask someone who’s done it” was never the same as “do what they say.” An audit is a gift, not a verdict, and the person holding it always gets the last word.

It’s also, I’ll admit, frustrating — because I could see the bottleneck from across the room, and watching someone spend months clearing a chokepoint a nine-dollar tool would’ve handled has its own small ache. But that frustration is mine to manage, not his to absorb. Maybe he learns something I couldn’t have taught him. Maybe he’s right and I’m wrong. Either way the map was the gift; the walk was always going to be his.

So: if you run this audit and it tells you not to build — sit with that before you build anyway. And if you build anyway? Come tell me what I got wrong. I mean it.

Or skip the
expensive drafts.

Every box above is doable solo — I’m not gatekeeping, the whole guide is free on purpose. But solo means you pay full tuition on each lesson: the wrong first hire, the package priced from fear, the move made a year too late. Fail-fast keeps the tuition survivable; it never makes it free.

A mentor doesn’t do the work for you. They’ve already eaten those mistakes, so you get to skip the drafts that only teach you what not to do. The guide hands you the map; someone who’s done it hands you their reps.

That’s the oldest shortcut there is — ask someone who’s been down the road before. Me, or anyone in your corner who has. (No one on your bench yet? Guide No. 6 is about building it.)

the checklist is free. the reps behind it weren’t.

Ask someone who’s done it

Not sure it’s
worth building?

That’s the best possible time to run the audit with a second set of eyes. If you want to pressure-test a build before you sink months into it — revenue or cost, the real bottleneck, the bus factor — that’s a conversation I’m always glad to have.