The Challenge
Somewhere in most growing companies, someone asks the same question: should we just build this ourselves?
At Born West, it came up over something as ordinary as email. The team had used Superhuman since 2018. It cost $30 a seat, did nothing but email, and did that one thing close to perfectly. The keyboard shortcuts were fast. It rarely broke. For years, that was worth paying for.
Then the math stopped making sense. The team went looking for something cheaper. Spark, Apple Mail, a handful of others. None of them fit the way Superhuman had. That left an honest, uncomfortable question on the table: pay for something that almost fits, or build something that fits exactly?
That question used to have a fairly stable answer. Buying was usually cheaper unless your needs were genuinely unusual. AI has quietly changed that assumption, and not everyone on the team agrees on how much.
Why the Comparison Isn't as Simple as It Looks
On the surface, AI should make this an easy call. Code that used to take a week can now get a rough version done in a day. If writing software is cheaper, building should be cheaper too, and the old buy versus build math should tilt further toward building.
That's the argument Achal Aggarwal made on a recent team call. The price dynamics have shifted, and building is closer to buying than it used to be, especially once you're building at a scale where per-seat licensing gets expensive. Siddhaarth Verma pushed back on the same call. Building was never just about the code. It's about who hosts it, who runs it, and who reviews it once it's live, and none of those costs move just because the first draft got faster.
Key Decisions
1. Match the tool to how you actually work, not to its price tag
Achal's test for Superhuman was simple: does it fit completely. If a tool matches how you already think and work, paying for it is usually the right call, even if it's expensive. If it doesn't fit, no amount of money fixes that, because you're not paying for the missing piece. That's the first filter, before cost even enters the conversation.
2. Separate the cost of writing code from the cost of owning it
AI lowers the cost of a first draft. It doesn't lower hosting costs, and it doesn't reduce the time someone has to spend reviewing what got built. Siddhaarth's pushback matters here: the host doesn't change. A faster first pass can create the feeling that a project got cheaper overall, when really only one part of it did.
3. Let scale change the math
A $30 seat license is nothing for 10 people. It's a different conversation at scale. The team's own example: building custom software makes far more sense for a 1000-person team than it does for a five-person one. At that size, owning the workflow and the IP can outweigh what you'd pay in licensing, because you stop bending your company's process to fit someone else's software.
4. Watch for scope creep disguised as productivity
AI doesn't just make the same project cheaper. It tempts teams into attempting more inside the same budget and timeline. Achal described it directly: what used to be a fixed scope becomes “x plus ten” because AI made the extra ten features feel free. They weren't free. They still need review, and that review time didn't shrink just because the build time did. That's where maintenance debt usually gets created without anyone deciding to create it.
What This Means for Growing Teams
There's no clean formula here, and pretending otherwise would be dishonest. A few real questions are worth asking before choosing build over buy: does the existing tool fit how you already work, or are you fighting it every day? Who owns the build in a year, and have they agreed to that? Is the extra scope AI makes possible actually needed, or just easier to say yes to now? At your current size, does owning the workflow outweigh what you'd pay to license it?
AI can shrink the cost of a first draft. It cannot shrink the cost of someone owning it after you ship.
If your team is weighing build versus buy right now, we're glad to compare notes. Book a 15-minute intro
