— Field Notes No. 08
Build, Buy, or Partner
Some shops rent everything and bend the operation around someone else's tools. Some build everything and quietly become software companies with one customer. Both are defaults. The skill is the call: build, buy, or partner, one system at a time.
Every publisher runs on a stack of software, and almost nobody decided what's in it.
Walk into enough shops and you meet the same two operations. The first one builds nothing. Every system is rented, every workflow is somebody else's template, and the place has spent years quietly bending itself around tools built for other businesses. The second one builds everything. Somewhere along the way it decided it was secretly a software company, and it has been staffing that decision ever since.
Neither shop made a decision. One outsourced its judgment to vendors, the other to pride. And both are paying for it every month, in different currencies.
Someone else's suit
Start with the shop that builds nothing, and walk the software bill line by line. A CRM priced per seat and built for software sales teams. An email platform priced for e-commerce. A project tool nobody has opened since the onboarding call. A CMS built for marketing sites that fights the newsroom every night at deadline. Add it up and the stack costs more than a junior hire, and not one line of it was built for how a local shop sells, renews, and publishes.
The subscription bill is the visible cost. The invisible one is worse: the operation bends around the tools. The renewal motion gets flattened into whatever the CRM thinks a pipeline is. The local sales process, the one part of the business that actually works differently here, gets squeezed into fields designed for somebody else's deal. Nobody can even say what the stack costs all-in, because it grew the way these stacks always grow: a seat at a time, a module at a time, a renewal nobody questioned at a time.
It fits the operation like someone else's suit. And the shop has worn it so long it's forgotten the fit is optional.
A software company with one customer
The second shop usually started with a good reason. A vendor that failed them, a talented developer in the building, a real need no product on the market met. So they built. And then they kept building, until the place ran on a custom CMS from 2014 that three people understand and one person maintains.
Now every fix waits in a queue behind that one person. The upgrades never quite happen, the integrations break when the world changes around them, and the person who holds it all can never take a real vacation, never mind quit. The maintenance quietly eats more every year than the licenses it was supposed to replace.
Here's the math that shop refuses to do. The platforms spread their engineering across a million customers. You can't staff a team to maintain bespoke everything, so the build-everything shop ends up running a software company with exactly one customer. And the customer can't leave.
The first shop pays for software that doesn't fit. The second pays for fit it can't afford to keep.
Every system gets one of three calls
Here's the discipline that beats both defaults. Every system in the building gets one of three calls: build, buy, or partner. Not a philosophy applied to everything at once. A call, made on purpose, one system at a time.
The sorting question is the same one that runs this whole series: does the system touch the asset? The asset is the audience and its trust, and the read of the market that comes from holding both. Some systems carry that. Most just carry the building.
Buy what doesn't touch it. Payroll is payroll in every business in America. Accounting, file storage, the boring backbone every company shares: good enough for everyone is good enough for you. Buying isn't surrender. It's focus. Spend no creativity here, and save it for the calls that matter.
Partner on what's heavy and shared. Ad ops, delivery, the subscription plumbing: real costs, zero differentiation, and the publisher one county over is carrying the exact same load. The cooperation note already made this argument, so here it's one sentence: none of it is why a reader picks you, so pool it, split the bill, and stop paying retail for plumbing.
Build what runs your difference. The pipeline shaped like how local advertising actually sells. The renewal calendar with the thirty-day call built in. The archive made answerable, the market brief, the client report that drafts itself from numbers you already have. These are the systems where the workflow is the edge, and a generic tool flattens exactly the part that makes it yours.
Now run the rule on the systems publishers sweat. The CMS feels like the heart of the shop, which is what makes it the most dangerous call in the building: it carries the journalism, but it isn't the journalism, and no reader ever subscribed for the publishing tools. Partner on it, or buy it. That's the call the 2014 shop got wrong, and it cost them a decade. The paywall splits in two. The meter, the billing, the password resets: those ride with the rest of the plumbing. What goes behind the glass is the second note's whole argument, and that judgment never gets handed to a vendor's defaults. Analytics splits the same way. The dashboard that counts pageviews is a commodity: buy it and move on. The layer that turns a century of archive and a day of reader behavior into a read on your market is the data note's product line. Buy the counting. Build the read.
Build what touches the asset. Buy what doesn't. Partner on what's heavy and shared. Sort honestly and the build list comes out short. It just doesn't come out empty, and each default gets one half of that wrong.
Where AI earns its place
Every note in this series carries this section. This is the note where it stops being a section, because the tools are the reason the build call just came back on the table.
For twenty years, buy-everything was the rational default. Bespoke meant a dev team, and a dev team was a payroll no local shop could carry, so you rented someone else's software and bent around it, because the alternative was the one-customer software company down the road. That was the right call. It's just no longer the math.
The newest tools don't suggest code while a developer types. Handed a defined job, they do the job: build the system, test it, fix what breaks, and explain what they did in plain English. The renewal calendar, the pipeline shaped like your actual sales motion, the report that assembles itself: a competent operator stands these up in weeks now, not quarters, for less than the annual bill of the subscriptions they replace. And the same tools carry most of the upkeep, which was always the real cost hiding behind the build.
Possible is no longer the question. Wise still is.
Cheap to build is not cheap to own
The new math is a gift with a trap in it. When building was expensive, the expense was the discipline: nobody built ten internal tools, because nobody could afford to. Now you can. So the restraint has to come from somewhere else, and it comes from rules like these.
Build less than you can. "Can we build this?" is a dead question: the answer is yes to almost everything now. The only question left is "should we own this?", because everything you build, you own, and everything you own bills you for the privilege.
Treat every build like a unit, the same way the stack note treats every revenue line. An owner, a backup who can actually run it, a line in the budget, and a job it has to do. If nobody owns it, you didn't build a tool. You took in a stray.
Build it like software, not like a science project. Versioned, documented, handoff-able, even when the tools did most of the typing. The test is simple: if the person who built it left tomorrow, does it survive the month?
Count the upkeep before you build. The day a system ships is the cheapest day of its life. The tools carry most of the maintenance now, but most is not all, and "a little upkeep" across a dozen builds is a job nobody hired for.
And don't build alone what the network already built. The council summarizer one shop stands up works in every town with a council. Before you build, ask the publishers who were never your competition. Half your list is already running somewhere, and the playbook is tradable.
A name, not a category
The framework is the easy half of this note. Build what touches the asset, buy what doesn't, partner on what's heavy and shared: it fits on an index card. The hard half is the map underneath each call. Which of the forty vendors in a category was built for a shop your size, and which is two renewals from sunset. Which co-op two states over actually shares plumbing, and which one is a booth and a brochure. Who already built the thing you're pricing, what it really cost, and what broke first. None of that is on anybody's website.
That map doesn't come from research. It comes from the rooms: the demos on both sides of the table, the contracts, the renewals, the promises you watch survive or quietly break. I've spent twenty years collecting mine, and it taught me what a real recommendation looks like. A buy call arrives with a name: a product somebody has seen from the inside, and an operator in a market like yours already running it who will tell you the truth about it. A partner call arrives with a person, and an introduction. A build call arrives with a precedent: the shop that already built it, and the bill.
So hold every recommendation you get to that bar, mine included. A category is a guess. A name attached means somebody did the work. The call is too important to make from a brochure.
The call is the skill
Step back and the pattern is the one this series keeps finding: the failure modes are defaults, and the fix is a decision made on purpose. The shop that builds nothing never decided. The shop that builds everything decided once, years ago, and never looked back. The shop that wins sorts the stack system by system, and rereads the calls every year the way it rereads the budget.
The software was never the asset. It never will be. The asset is the audience and the trust that holds it, and every system in the building either serves that or bills against it. Sort them like you'd sort anything else you pay for: what earns, what protects, what quietly eats.
Then comes the part that decides whether any of it matters: running the whole thing, units and tools and people, like you mean it. That's the last note in this series.
Built Revenue · Field Notes No. 08 · https://www.builtrevenue.com/field-notes/build-buy-or-partner
— Get the next note
The full essay, by email, when it publishes. No filler, unsubscribe anytime.