Every build vs. buy decision gets made on two numbers: how long and how much. They're the two least important numbers in the room.
Every consultant gives you the same rule: build what differentiates you, buy everything else.
By that rule, we should have bought. We built. It was the right call. And we got there the wrong way.
Plumbing, by the book
We ran a suite of enterprise applications, and every one of them handled its own security. Its own login, its own authorization, its own control pages. Most used ordinary role-based access. A few went all the way down to permissions on individual fields. Customers' IT departments hated it. Nobody wants to manage security for a third-party app, one app at a time. About 10% of the calls into our support team were about authorization and access.
We were moving everything to SaaS, and that mess couldn't come with us. We needed one entitlements service across every product, built on Zanzibar, the model Google published for how it runs permissions across its own products.
Nobody bought our software for its permission model. An entitlements service is plumbing. The rule says buy.
How the decision actually got made
The evaluation had been done once, three years earlier: what's on the market, what it costs, what we need, what a build would look like, how long each would take. The answer then was build. A prototype got stood up, and then the whole effort was parked behind higher priorities.
When it came back, it came back as a build. The prototype existed, so the decision was treated as made, and there was a lot of pushback on re-running it. The numbers at restart looked close to even: three to five months to build with our own people, or three to four months to buy and integrate at $0.50 to $0.75 a user. Our edge cases were what made buying that slow and that expensive.
I owned the product side, and the first thing I did was throw out the edge cases. Field-level access control was used by a literal handful of customers, and it carried a lot of code and slowed performance for everyone else. We cut it. One lightweight app granted permissions on the fly with no setup. Building that behavior into the shared service for every other app wasn't worth it, so that one app kept its own authorization. What was left was a consistent feature set, and a consistent feature set is exactly what off-the-shelf products are built for.
So in parallel, without slowing the build, our dev lead went back to the market. He found a great fit at $0.25 a user, a third to half of the earlier quotes.
That should have triggered a real comparison of both options at the new scope. Instead, a partially cooked idea went up the chain. By the time it reached the C-suite it had been through a game of telephone, and what came back down was a mandate: build it, and stop looking at other options.
It worked
The team had zero experience with Zanzibar. Zero. Most engineers only know it from Google's paper. The build took six months against an estimate of three to five. For a first-time team on a hard problem, that's a respectable miss.
And it paid off in a way nobody had predicted. Our customers' IT groups now handle almost all of their own security, mapped straight into our applications. Very little integration. Minimal troubleshooting. Access calls went from about 10% of our support volume to near zero.
Why the rule was wrong
The differentiation test asks what the thing is. It should ask where the time goes. The how-long number counts the months until go-live. Where the time goes counts every month after.
Build spends time once: six months of engineering, paid up front. Buy saves those months, then charges you on everything after. The per-user fee, every year. The integration with every app. Every workaround where the product doesn't quite fit. Every issue that now has a vendor in the middle.
What we built wasn't really an authorization system. It was a way out of managing our customers' security. That's the trade nobody weighed: one build, against every access call that now never reaches us. In board terms, the build was a one-time project cost. Buying would have been a permanent operating line, and so would the support load it left behind. The cost we did take on is a team that owns that service for as long as the products exist. That belongs on the page too.
Plumbing that touches every customer, every day, doesn't belong in the buy-everything-else pile. It's where your time goes.
Save this: download the full-size image.
Why that should scare you
We got the right answer. Now look at how.
A three-year-old prototype counted as a decision. Sunk cost argued for the build. The buy option went up the chain half-argued, next to a build with three years of momentum, and never got a fair hearing. The final call was a mandate to stop looking. If the answer had been wrong, not one step in that process would have caught it.
And nobody wrote down why the build won. The reason it worked wasn't the reason it was chosen. Run that same process on the next decision and you'll get an answer just as confident and maybe dead wrong, and nobody will be able to say why.
We didn't make a good decision. We made a lucky one, and the process that made it is still running.
Start Monday
First, set a threshold for which decisions get this treatment: a dollar figure, a headcount, anything customer-facing. It's different for every company. Pick one, write it down, and stick to it.
Then the CEO or operating partner picks the next build vs. buy decision over that line, or the biggest one made in the last two years. The IT lead and the business sponsor coordinate five questions, and the result goes to whoever approves the spend within 30 days. For an upcoming decision, the output is a one-page comparison. For a past one, it's one sentence: why it actually worked, and whether that's the reason it was chosen.
- What are we trying to stop doing? Not what system we need. What work, what calls, what manual steps go away if this succeeds. The business sponsor answers it in writing before anyone prices anything. If the answer is nothing, neither option is worth funding.
- Where does each option's time land after go-live, whose time is it, and what doesn't get built in the meantime? Engineering, support, operations, the customer. Then the other half: every month your engineers spend building this is a month they don't spend on something else, so name what slips. Finance and the IT lead put both on the comparison as their own lines, hours per year by team for three years. Rough ranges are fine. This is the line that decided our outcome, and it wasn't on anyone's slide.
- What did we cut before we compared? Edge cases decide fit. The process owner lists every requirement next to how many users, sites, or customers depend on it, and cuts or carves out anything fewer than 5% need. Then price the blend: buy the core, keep the exception, the way we kept one app on its own authorization. The cut list goes on the page with the comparison.
- Who owns it in year three, and what will a buyer see? For a build, name the two people who can run it. One is a key-person risk, and a buyer's diligence team will find it. For a buy, read the change-of-control clause, the price escalators, and how you get your data out if the vendor fails or you leave. If either answer is "we'll figure it out," that is the answer.
- Did both options arrive at the same depth, and what would change the answer? One page, same scope, same horizon, sunk cost listed and labeled as not a reason, written by someone without a stake in the outcome: the CFO's team, or the operating partner's bench. If one side shows up thinner than the other, it doesn't go up the chain. Whoever makes the call writes what would change the answer at the bottom. If it's nothing, you didn't make a decision. You issued a mandate.
How long and how much will always be in the room. They just shouldn't be the ones deciding.