Build the boring pipe first

Every product has an interesting part — the model, the algorithm, the insight, the thing you'd put on a slide. And every product has a boring part: getting data in, moving it between steps, handling the cases that don't fit, getting results back out to a human, recording what happened.

Teams start with the interesting part. It's why they took the job, it demos well, and it's the part that feels like the actual product.

I've come to think that's backwards, and I've paid for the lesson enough times to say it plainly: build the boring pipe first, with a placeholder where the interesting part goes.

What "boring pipe first" means concretely

Week one, the system does something end to end. Real input arrives through the real intake path. It moves through every segment. A result comes out and reaches a human in whatever form they'll actually receive it. Every step logs what it did.

The interesting segment is a stub. A rule of thumb, a lookup table, a hardcoded response, a human doing it by hand behind an API. Whatever's fastest.

You now have a complete pipe with one segment that's obviously bad — and that is a dramatically better position than a brilliant segment with no pipe around it.

Why it wins

You find out what the interesting part actually needs to do. Requirements written before anything runs end to end are guesses. Once real inputs flow through, half the assumptions collapse — the data is dirtier, the cases are weirder, and the output has to fit a workflow nobody described. Every hour spent perfecting a model against imagined requirements is an hour at risk.

The stub is often good enough for longer than you'd think. I've shipped stubs that stayed in production for months because the rest of the pipe delivered most of the value. That's not a failure of ambition, it's the correct allocation of effort — and you only discover it by running a complete system and watching where the value actually comes from.

You get gauges before you get results. A complete pipe can be instrumented at every joint on day one. So when the real segment goes in, you have a baseline to compare against. Teams that build the interesting part first ship it into a dark pipe and then argue about whether it helped.

Integration surprises arrive while they're cheap. The auth quirk, the rate limit, the format nobody documented, the compliance step nobody mentioned. These always exist, they always take longer than expected, and finding them in week one is very different from finding them in week ten with a launch date.

Why teams resist

Because the boring pipe is unrewarding to build and impossible to demo. "We wired up the whole flow and the core logic is a lookup table" is a terrible standup update. "We got the model to 91%" is a great one, even when it's a model that will never see real data in the shape it was trained on.

There's also a status dimension. The interesting part is the part that requires expertise. Plumbing feels like work anyone could do — which is exactly wrong, since designing the fittings between segments is the highest-leverage design work in the system, and it's the work that determines whether the interesting part can ever be replaced.

The version I've settled on

Two weeks, three rules:

Every segment exists, however stupidly. No gaps, no "we'll add the intake later."
Every joint is instrumented. Throughput, latency, quality. Even if the numbers are meaningless at first — especially then, because you're establishing the plumbing that will carry the meaningful numbers.
One real user runs one real unit of work through it. Not a test fixture. A person, with a thing they actually needed, receiving a result they actually use.

If you can do those three in two weeks, you have a business you can improve segment by segment, forever, with a gauge telling you whether each improvement helped.

If you can't, you've learned something important about where the hard part really is — and it's almost never where you thought.