On September 27, Jason Lemkin posted a simple observation: he replaced a $4,000-per-year email marketing tool with something he built himself on Replit in under an hour. The replacement is, by his description, better — more AI-native, better integrated, more useful. He shared it not as a product launch or a tutorial but as a signal: a lot of software is about to become cheap or free.
He’s not wrong. The question is which software, and for what kind of organization.
quadrantChart title Build vs. Buy in the AI Era x-axis Low Integration Complexity --> High Integration Complexity y-axis Low Compliance Burden --> High Compliance Burden quadrant-1 Enterprise SaaS still wins quadrant-2 Evaluate carefully quadrant-3 Build it yourself quadrant-4 Custom build: watch the maintenance Internal dashboard: [0.18, 0.12] Single-user automation: [0.22, 0.18] CRM for five users: [0.65, 0.32] HRIS: [0.62, 0.78] Healthcare billing: [0.78, 0.92] Customer analytics: [0.48, 0.38]
The rundown
Lemkin’s September 27 post lands in specific context. Two days earlier, DHH declared at Rails World 2026 that 37signals is going pencils down on hand-written code — directing AI agents to produce 150,000 lines per month. Pieter Levels and others have been vocal for months about canceling SaaS subscriptions in favor of AI-built replacements. The signal from multiple directions is consistent: the cost of writing software has dropped substantially, and the economics of certain categories of SaaS are eroding.
Lemkin’s example is well chosen. A $4,000-per-year email automation tool, serving a single user, without complex compliance requirements, with minimal integration points — that is exactly the category being disrupted. Build it in an hour, own it, customize it, replace it if it breaks. The math works.
The part that needs examination is what happens when the same logic gets applied to software that isn’t in that category.
For engineers: the category matters more than the price comparison
For engineers evaluating a build vs. buy decision in 2026, the first question is no longer “how much does the vendor charge.” The build cost is now low enough for a wide range of tools that the per-seat price alone doesn’t settle the question.
What actually settles it is the total cost of ownership across the full lifecycle. A tool built in an hour takes some number of hours per year to maintain — updating it when a dependency breaks, adding the feature someone realized they needed, reviewing it when your security posture gets audited. That maintenance overhead is fine if the tool stays simple. What changes the calculation is whether the tool will stay simple, and whether the organization can absorb the risk if it doesn’t.
The practical filter: single-user, low-compliance, lightly-integrated tools with acceptable failure tolerance are the realistic build candidates. Multi-user systems, compliance-exposed workflows, and deeply-integrated platforms where failure has operational or legal consequences are a different category entirely. The per-seat savings from replacing those with custom builds tend to be smaller than the hidden costs that accumulate over time.
One thing that doesn’t go away when you build instead of buy: the security obligation. A custom-built tool that handles customer data or financial transactions still has to be reviewed, maintained, and audited. The vendor isn’t doing that work for you anymore.
For business owners: audit your stack before acting on the signal
The mistake Lemkin’s observation invites — and I don’t think he’s making this claim — is applying the same logic across an entire software stack. The economic case that is correct for a single-user email tool is not correct for your HRIS, your financial reporting system, or your customer data platform.
A useful audit: go through your software spend and categorize each tool across two dimensions — integration complexity and compliance burden. Tools in the low-low quadrant are realistic candidates for AI-generated replacements. Tools in any other quadrant are not, and pretending otherwise just shifts the cost from the vendor invoice to your engineering team’s backlog.
The second thing worth examining: the true cost of the tools you’re thinking about replacing. The real number is not the annual subscription fee. It is the subscription fee plus the internal time to manage the vendor relationship, train new employees, handle edge cases the tool doesn’t cover, and absorb the risk when the tool is temporarily unavailable. AI-generated replacements carry the same total cost — it just distributes differently across line items. Sometimes that distribution is favorable. Often it isn’t, and the difference shows up 18 months after the build.
My take
I worked at First American Title starting in 2009, when the company had completed more than 80 acquisitions over the previous decade and accumulated 770 applications across 15 subsidiaries. My role was enterprise architecture — auditing what existed, understanding how it integrated, and identifying what could actually be consolidated.
The number that stayed with me from that engagement was 770 applications. Not because the company had been reckless, but because every acquisition came with software that looked locally useful and proved globally expensive. Each application made sense to someone at the point it was created or acquired. The collective cost — maintaining all of it, integrating all of it, dealing with overlapping functionality and the security obligations across a sprawling footprint — was enormous. It was a significant driver of the technical debt we spent years working to remediate.
The software commoditization signal is real. But the lesson from that engagement is that the question “can I build this cheaper” is not the same question as “what does this cost the organization over time.” Lemkin’s email tool will probably stay simple. The temptation is to assume the same economics apply to everything on the stack.
They don’t. And the difference between those two categories — what should be built and what shouldn’t — is exactly the judgment that a technology leader is there to provide. At 37signals, it’s DHH. At First American, we had an enterprise architecture board to make those calls. The tool economics are changing. The need for someone to evaluate them clearly is not.
