Build vs Buy SaaS: 5 Subscriptions I Deleted This Year

The build vs buy SaaS question everyone gets wrong

Most build-vs-buy SaaS advice is dogma wearing a suit.

One camp says "just buy it, never build, your time is too valuable." The other says "build everything, own your stack, control your destiny." Both are wrong in opposite directions. The buy-everything people ignore the places where SaaS quietly bleeds you. The build-everything people ignore that you'd be reinventing Stripe and embarrassing yourself in the process.

Here's the position the whole article rests on. This year I deleted five SaaS subscriptions from the DTC apparel brand I run in San Diego. Combined, they were costing me a little over $18,000 a year. I replaced each one with code I own, running on infrastructure I rent.

That distinction is the entire game. Own the logic, keep renting the primitives.

I didn't go build a payment processor. I didn't stand up my own email servers. I kept paying for the boring, hard, commodity things where a vendor's scale is a genuine advantage. What I stopped paying for was software that wrapped my own business logic in someone else's UI and charged me a monthly toll to access it.

The build vs buy SaaS decision isn't a personality trait. It's a math problem with three inputs, and most people never actually run the math. They either default to buying because it feels safe, or they build out of ego.

I'm going to show you the exact line I drew, the five things that fell on the wrong side of it, and (this is the part most articles skip) where building actually cost me more than the subscription ever did.

The line: when buying stops making sense

The three triggers

Before the examples, here's the reusable mental model. Three triggers tip the math from buy to build. You usually need two of them firing at once.

The three triggers that tip build vs buy

Trigger one: bespoke business rules the SaaS can't model. When you're using a tool the way it wasn't designed, fighting its assumptions with manual workarounds every month, the SaaS has stopped fitting your business. You're paying to bend yourself around its limits.

Trigger two: cost that scales faster than the value. Per-seat, per-transaction, per-state pricing that climbs with your growth while the actual work stays flat. If the vendor's bill grows but the job doesn't, you're funding their margin, not your outcome.

Trigger three: you're renting access to your own data. When your customer records, your transaction history, your operational data live behind their API limits and their export buttons, you don't own your business. You're a tenant.

Two or three of those firing? It's a build candidate.

What I keep buying every time

The flip side matters more than the triggers, because this is where the build-everything crowd goes broke.

Pay for primitives, build the logic

I never build payment processing. I never build email deliverability infrastructure. I never build cloud hosting, auth primitives, or a CDN. These are commodity primitives where the vendor's scale is a real, unbeatable moat. Stripe has spent a decade on fraud models I will never replicate. Email deliverability is a relationship business with inbox providers that takes years to earn.

This is the whole philosophy in one line: pay for primitives, build the logic. Rent the things that are hard because of scale. Build the things that are hard because they're specific to you. That second category is where your edge actually lives.

1. The bookkeeping app: bespoke rules the SaaS couldn't model

The first one to go was a bookkeeping subscription that simply couldn't model how my business actually books money.

Multi-currency cost of goods. Inventory writeoffs. The specific way we recognize revenue on pre-orders that ship weeks after the charge clears. The app had opinions about all of these, and its opinions were wrong for an apparel brand carrying physical inventory.

So every month we exported to CSV and fixed things by hand. That's the tell. When you're paying for software and then manually correcting its output, you're paying twice.

The trigger here was pure bespoke business rules. I replaced it with a double-entry ledger on Postgres, with database triggers that enforce balance at the row level. The trigger is the whole point: the books literally cannot go out of balance, because the database rejects any transaction where debits don't equal credits. No human discipline required. The math is enforced by the machine.

I wrote up exactly how I replaced our bookkeeping app with a Postgres ledger if you want the implementation details.

Now, the honest part. I did not fire my CPA. I still pay a human for tax strategy, for the judgment calls on how to treat specific expenses, and for signing off on returns. What I built replaced the data-entry-and-reconciliation layer, not the professional judgment layer. Knowing the difference is the entire skill.

2. The sales-tax filing service: paying per-state for a script's worth of work

The second subscription was a sales-tax filing service charging an annual fee that scaled with the number of states I had nexus in and the volume of filings.

When I actually mapped the work it was doing, it was three steps. Pull the transaction data. Group it by jurisdiction. File through the state portals. That's it. That's a script.

The trigger here was cost scaling that had nothing to do with value delivered. Adding a state didn't make the underlying job harder. It just made the bill bigger. I was paying for surface area, not effort.

I replaced it with automation I own that does the same three steps.

And this is the section where I admit building has a downside. Tax law changes. Rates shift, thresholds move, new jurisdictions appear. The SaaS was, in part, paying a team to track all of that so I didn't have to. My replacement needs maintenance, and I'm the one who has to stay current.

There's also a real liability shift. When a vendor files wrong, there's at least a shared responsibility conversation. When my code files wrong, that's entirely my problem. I weighed that and decided the risk was manageable at my volume with my own review in the loop. At ten times the complexity, I might have kept paying. This one was close, and pretending otherwise would be dishonest.

3. The returns app: renting access to our own customer data

The third one I killed was a returns and exchanges SaaS, and this was the clearest case of renting access to my own data.

It held our return reason data, our RMA history, and our exchange logic behind its UI and its API rate limits. I wanted returns wired directly into inventory and customer support. When a customer returns an item, I want that unit back in available stock instantly, and I want my support team seeing the full history in one place. I couldn't get clean data out to make any of that happen.

The trigger was data ownership plus an integration wall. Two reasons stacked, which is exactly when you build.

I replaced it with an AI-assisted returns and exchanges system that handles RMAs, processes refunds, manages exchanges, and writes straight to my own database. No middleman holding my data hostage.

The subscription was running about $300 a month, so call it $3,600 a year recovered. But the real win wasn't the money. It was one source of truth. Returns, inventory, and customer records now live in the same database, talking to each other. No sync delay, no reconciliation, no "the returns tool says one thing and inventory says another." When your operational data is fragmented across five vendors, every report is a guess. Consolidating it was worth more than the dollars.

4. The loyalty app: a flywheel we couldn't tune

The fourth was a loyalty and points SaaS, and this one I killed on principle as much as economics.

It charged monthly and capped how I could design the program. Here's why that matters: a loyalty flywheel only works if the point values, tier thresholds, and redemption rules are tuned to your actual margins. A point is a liability on your balance sheet. Price it wrong and you're either giving away margin or offering a reward nobody cares about.

The app forced me into its templates. I could pick from its menu of program structures, but I couldn't build the one my unit economics actually called for.

The trigger was bespoke rules again, but the angle is sharper here. The program logic isn't a commodity. It's a competitive lever. How I reward my best customers is a strategic decision, and I'd handed it to a vendor with a settings page.

I replaced it with my own points and tier logic, tied directly to the ledger and customer data. Now point values reflect real margin, and I can adjust thresholds based on what actually drives repeat purchases.

The honest cost: the SaaS had a polished, customer-facing frontend that just worked. Customers trusted it. Building a points display my customers found equally clean and believable took real design work and several rounds of getting it wrong. The backend logic was the easy part. Earning customer trust in a UI I built myself was not.

5. The 3PL workflow tool: the integration tax

The fifth one was the easiest call. A third-party workflow tool sat between me and my 3PL fulfillment provider, and it was, on inspection, just middleware.

It added a per-order fee and a sync delay. Worse, every edge case needed a workaround. Split shipments, backorders, the timing on pre-orders, all of it required manual intervention because the tool's model of how fulfillment worked didn't match how my fulfillment actually worked.

The trigger was a blend of cost-per-transaction and latency. I was paying a fee on every single order for a layer that slowed things down and broke on anything non-standard.

So I deleted it. Not replaced with a smaller version. Deleted. I wrote my own integration code that calls the 3PL's API directly. The middleman was the problem, and the solution was removing the middleman entirely.

That's the lesson in this one. Sometimes the SaaS isn't software you need to rebuild. It's a tollbooth between two systems that could talk directly. This was part of a broader consolidation where one system replaced four SaaS tools, and several of those were exactly this: middleware whose only job was sitting in the middle.

The honest economics: what building actually cost

The recurring savings

Across all five, the recurring subscription savings came to a little over $18,000 a year. That's real money that now stays in the business instead of leaving it every month, forever.

The five deleted subscriptions and their savings

For a brand my size, that's meaningful. And it compounds, because none of those bills come back.

The hidden costs nobody mentions

Now the part the build-everything crowd never tells you.

Recurring savings vs hidden costs of building

Building cost real time. And the moment I shipped each replacement, I owned the maintenance, the security patches, the bug fixes, and the liability. The tax filing that goes wrong is mine now. The ledger bug that misstates a balance is mine. The returns system that double-refunds someone is mine.

There's also a key-person problem I created. If I disappeared tomorrow, someone has to understand 22,000 lines of custom Python and a Postgres schema full of triggers. SaaS pricing is partly insurance against exactly that. You pay the subscription so that the knowledge lives in a company, not in one person's head.

Here's the honesty this whole article needs: the math only works because I can build fast with AI, and because I'm running my own brand where I'm both the operator and the engineer. I understand the business rules because I wrote them, and I can build the code because that's what I do.

For a 50-person company with no in-house builder, at least three of these five should have stayed bought. The bookkeeping ledger, the tax filing, and the loyalty program carry enough liability and maintenance burden that without someone who can own the code, the subscription is the cheaper, safer choice. I deleted them because I could carry them. Most companies can't, and pretending otherwise would be selling you something.

How to run this decision in your own business

Here's the repeatable test. Go down your SaaS line items and ask three questions of each one.

The three-question build vs buy decision test

One: are we fighting its limits with manual workarounds every month? Two: is the cost scaling with our growth in a way the value clearly isn't? Three: can we get our data out cleanly, or are we renting access to our own information?

Two or three yeses, and you've got a build candidate worth investigating. One yes, leave it alone. Zero, you're happily married, keep paying.

But here's the caveat that matters more than the test. For most CEOs, the decision isn't the hard part. The hard part is having someone who can actually build the replacement and maintain it without creating a worse problem than the subscription you killed. A half-finished custom system is more expensive than any SaaS bill. I've seen companies replace a $300-a-month tool with a $40,000 mistake.

That gap (between knowing what to delete and being able to build something that holds up) is exactly what I close as a Chief AI Officer. I run this audit across a company's stack, find the SaaS lines genuinely worth killing, and build the replacements that survive contact with real operations. Not a slide deck of recommendations. Working systems.

If you've got a stack you suspect is bleeding money in places, talk to me about your stack.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together