Build versus buy in the age of AI

Build versus buy seems to be on a lot of people's minds these days. After months of everyone declaring SaaS dead and burning millions of tokens recreating well-established software (or at least claiming to), the online discourse has predictably swung to the other side. The new "hot take," which is where we all started so many years ago before LLMs, is that maybe you shouldn't just build everything.

And of course building everything was never something serious companies considered. Even the frontier labs, with seemingly unlimited tokens and asymptotically-increasing headcount, buy plenty of things rather than spend the time and energy to build and maintain them. Yes, you can pretty easily vibe code your own basic issue tracker. Over the course of a few days or even a week you can probably even create something pretty compelling! And then, as always, the question that looms ahead of you is who is going to maintain it. Even if you overcome the switching costs to get widespread adoption, do you want to be responsible for maintaining software that plays a critical role in your company's day-to-day workflows? If not you, then who?

So the same rules still apply. Don't build software you have no interest in maintaining. Pay someone else for maintenance when the burden of maintenance is high or critical to your business. This of course was always the real calculus for build versus buy, but as with so many things code being cheap to produce has thrown it into stark relief.

Of course this doesn't mean you should never build things. The combination of it being easier than ever to explore the build side of the equation alongside the value of having something tailor made for your needs is pretty powerful. Here are a few cases where we think building makes sense.

Dashboards and analytics. Okay, so maybe you don't want to vibe code your full product analytics suite that a third of your company relies on to pull data about how your product is used (see the critical workflow maintenance argument from earlier). But something like DORA metrics? Zach spent two years leading a team to build out an engineering efficiency metrics product, and he thinks the answer is clear: with today's tools, build it ten times out of ten. The data is readily available (usually Jira and GitHub, or similar), most orgs are only going to look at it once a week (at the most), and the value of customization is high (you can more easily answer the questions that are important to you). The tradeoff makes sense.

Developer experience and AI enablement tooling. This is a more controversial one, and several of our readings for the week are going to make the case in the opposite direction. We certainly don't think you need to build everything here; we often advise companies we work with to buy things like background agents off the shelf. But there are some factors at play which tilt things in favor of build. First and foremost, the number one difference we see in companies who are getting real value out of AI and the companies that are floundering with it is investment. If you're not willing to dedicate real engineering headcount to enabling your org in a first-class way, then simply put you're not going to get the leverage you claim to want. Giving a dedicated team space to build where they think it makes sense, even if you shift to buy later, is worthwhile experience right now (and they'll challenge and improve other systems and processes along the way). Second, the value of customization is often high, and maybe even necessary. Building for your workflows and your toolchains can be the difference between ho-hum adoption and true inflection, and even buying off the shelf will still require you to invest and customize for your needs.

Augment, don't replace. You can often get the best of both the build and buy worlds by building on top of existing systems rather than seeking to outright replace them. This affords you the safety of someone else being responsible for maintenance, updates, and so forth, while you get to customize to your company's needs (which is easier and more justifiable than ever before). We still wouldn't necessarily recommend building your own full custom UI on top of Jira APIs just because you don't like the Jira interface, but it's possible. More practically, you can build a custom dashboard on top of Jira, or a custom connector between systems. We discussed building our own AI-powered meeting transcription solution because there are some things we don't like (the old trap of "how hard can it be?"), but ultimately felt like it would make more sense to just build on top of the capabilities of our existing solution of choice (Granola).

Here's what we're reading this week.

Stripe and Sierra built their own coding agent systems. You probably don't need to.

David Pan is Field CTO at Cursor. For the last few weeks we've been lauding Sierra's fantastic blog series as a roadmap for how to build your own in-house agent. Pan makes the argument that you don't need to. And he's not wrong, you don't need to, but you might still want to. If your company is early in the AI enablement journey, don't start by trying to replicate Sierra's Pinecone agent. Absolutely buy something off the shelf (or more likely, multiple somethings). Use a well-established coding harness. Buy a background agent solution. Don't try to buy a company brain, nobody we've seen has figured that out yet.

Even a working internal build rarely gets the attention to detail that makes people actually use it. An internal tool that's 80% as good gets 20% of the usage. Most teams ship a Slack bot and stop there, because integrating the same agent into the IDE, CLI, web, mobile, Jira, etc. is way too much surface area. And then there's governance: user management, token analytics, budget controls, audit trails. All of it is mandatory, none of it is differentiating.

If your company is further along in the AI transformation journey and you don't want to sit and wait for the tools to catch up (and remember, if you can buy then they'll catch up for everyone at the same time), there can be a lot of leverage in building something yourself that's tailored to your company's needs. And your team is going to learn a whole lot getting there, which may or may not be a valuable competitive advantage depending on your particular situation.

Replacing Jira: how's it going

quick update on how this is going: they have gone back to linear because maintaining their internal tool that they vibecoded was taking away from their actual work’s bandwidth.

In March someone tweeted about a QA engineer at a startup who built their own issue tracker that had replaced other tools ("It's faaar better than JIRA and is just as detailed"). This week they followed up with a good reminder of the real burden of software development.

software factories aren't cracked yet

Geoff Huntley (@GeoffreyHuntley), inventor of the "ralph loop," works on AI verification at Antithesis. Geoff provides a reality check on all the companies selling a solved "software factory," and some perspective on what it's going to take to get there.

i must stress that factories is not a token or llm problem. it’s a systems engineering and corporate culture problem.

How Anthropic secures its AI-native SDLC

Jason Clinton, Anthropic Deputy CISO. Anthropic does a really nice job of regularly sharing useful insight into how they work at enterprise scale. This one covers the security angle, something that doesn't sound as exciting but is critical for any serious large business.

The article echoes some points we've made the last few weeks: with the right workflows and infrastructure in place, software is often more secure with AI, not less.

• After they added automated, multi-layer AI review, the share of pull requests getting real feedback jumped from 16% to 54%
• A third of past claude.ai bugs would have been caught by the checks they have in place now
• Claude found and helped fix over 500 serious open-source security bugs in one month

Two things to try this week

How to Get a 100 PageSpeed Score

After seeing this article in his X feed, Zach spent about 30 minutes with Codex (on Terra no less) getting cxo.dev to all 100s in Lighthouse. Do you have 30 (or even 10) minutes to spare for performance?

Make Claude make sense

One of several tricks people are sharing to get the latest Anthropic models to not be infuriatingly obtuse. This one is the simplest we've seen because it's based on a real existing standard ("Simplified Technical English").

Thanks for reading with us!

— Claire + Zach