
Build vs. Buy Isn't a Hard Decision. It's a Symptom.
When the choice feels impossible, the problem is almost never the vendors. It's the requirements you never wrote down.
View entry→October 15, 2026
When the core isn't finished, a big build-out doesn't speed you up. It burns what's done and leaves the raw part raw. Match the fuel to the stage you're actually at.
Joe Guster
October 22, 2026 · 5 min read

I learned to grill on charcoal. On charcoal, heat is something you build and then manage. When the coals start going gray and a couple of pieces still aren't done, you don't start a new fire. You push a few fresh coals under the pieces that need them and let the rest of the grill coast.
The first few times I used a gas grill, that instinct had nothing to hold on to. Heat was a knob. I wasn't ready for the flare-up, and I charred the food.
I think about that grill whenever I watch a startup hit its first stall. There's a product, a handful of early users, and a core that isn't quite finished. Momentum goes soft, and the move that feels right is the big one: more people, more workstreams, a bigger build-out. That's gasoline on a grill that needed three well-placed coals.
Match the fuel to the stage you're actually at. Early on, a small push in exactly the right spot beats a big dramatic pour almost every time, because the pour doesn't just waste fuel. It burns the food.
The case for the big move is real. A stall is scary. Investors want to see motion, the team wants to see commitment, and adding people and parallel workstreams looks like both. Once the core of a product works, it's often the right call. Fuel is how you scale something that's already cooking.
The problem is the order. I've seen it up close on a platform I've been building. A few months back, we brought on more developers, each with a single workstream of their own, while the core services every one of those workstreams depended on were still in flux. On paper it was parallelism: more people, more fronts, a faster path to launch.
In practice, every new workstream was a new dependency on a core that hadn't finished its main job. The premise of the whole product, pulling in customers' data from the systems they already use, wasn't done yet. Now it had a growing line of consumers waiting on it.
That's the flare-up. Gasoline doesn't heat the one piece that's still raw. It heats everything at once, including the parts that were already fine.
A dependency on a moving core works the same way. Every workstream that leans on something unfinished needs answers the core can't give yet: what the data looks like, which pieces are stable, what's about to change. Each answer is a guess the core then has to honor or break. So the one piece that was still raw spends its heat serving everything around it instead of finishing, and the work that matters most gets slower, not faster.
Then the burst dies down, and you're back to cooling coals with less fuel and food that's charred outside and raw in the middle. In a startup that's runway spent, a team sized for a product that doesn't exist yet, and a core that still isn't done.
AI makes the knob easier to turn. Every workstream is cheaper to start than it was two years ago. But as I wrote last week, cheap to build is not cheap to own, and each new workstream on an unfinished core adds weight to the one thing that can't carry it yet.
The fix on that platform wasn't dramatic, which is the point. We reduced the number of workstreams going into the MVP and put the heat back where the product was still raw: the core, and the connection the whole thing is premised on.
The rest of the MVP plan follows the same rule. The onboarding JotForm I mentioned a couple of posts back is a coal. So is billing the first customers by hand. Neither is impressive. Both keep fuel off the parts of the grill that don't need it yet.
Choosing your coals comes down to three questions.
What's actually on the grill? Be honest about the stage. A handful of users and an unfinished core is early, whatever the deck says. The fuel that's right for a product that works is wrong for one that doesn't yet.
Which piece is still raw? There's almost always one: the core loop that doesn't quite close, the integration that's half done, the step where early users drop off. That's where the heat goes. Everything else can coast.
What's the smallest fuel that finishes it? Not the most impressive, the smallest. One more developer on the core instead of three on the edges. A manual process instead of a system. A conversation with five users instead of a launch.
On Monday, write down everything you're planning to add this quarter: hires, workstreams, features, launches. Next to each one, write the piece of meat it cooks, meaning the unfinished part of your core that it gets done.
Some lines will have a clear answer. Those are your coals. Some will say "everything," or "growth," or nothing at all. Those are gasoline, and they wait until the core is cooked. Anything that adds a new dependency on something unfinished waits twice.
If you know a founder who's reaching for the can right now, send this their way. And if you're not subscribed yet, that's the smallest fuel there is.
Practitioner Circle
Get a weekly deep dive into UI architecture and practitioner workflows. No fluff, just craft.

When the choice feels impossible, the problem is almost never the vendors. It's the requirements you never wrote down.
View entry→October 15, 2026

The person who should own your product decisions isn't a senior PM or an architect. It's someone who knows what each decision costs to build, because they still build.
View entry→October 9, 2026

An idea is still an idea, even with good formatting. The question isn't whether your spec is detailed, it's whether it's decided.
View entry→October 5, 2026