Replace SaaS With Custom Software: The Honest Tradeoffs

Four Subscriptions, Four Problems

Last quarter I cut four SaaS tools from my DTC fashion brand and rebuilt all four in-house. A returns app, a chargeback service, a reviews platform, and a loyalty app. Each had a monthly bill. Each was on the storefront. And each one I now run as code I own.

Before you assume this is a "building is always cheaper" pitch, it isn't. Most of the time replacing SaaS with custom software is a bad idea. The vendor has spent years on the problem and they spread the cost across thousands of customers. You can't beat that on price for a generic feature.

So why these four?

Each one was some combination of three problems. A recurring cost that scaled the wrong way. A black box I couldn't see into or extend. A performance drag on the storefront. And underneath all of that, the same root issue: none of them could do the specific logic my brand actually needed.

That last part is the whole story. These weren't generic features I was paying for. They were rules core to how my brand runs, and the SaaS forced me into a generic version that fought me.

I run the brand on an agent-first platform I built and maintain myself, which changes the math in ways I'll be honest about later. That context is doing a lot of work in this decision.

Here's the question every CEO with a growing SaaS bill is actually asking. The tools don't quite fit, the invoices keep climbing, and building my own feels both tempting and reckless. So when is it actually worth it?

That's what I want to answer. Tool by tool, cost by cost, including the parts that hurt.

Why Each Tool Didn't Fit

In every case, the SaaS could do 80% of what I wanted. The missing 20% was the part that mattered.

Returns: store-credit-only with price-diff exchanges

I wanted refunds to default to store credit, not back to the original payment method. Store credit keeps the money in the brand and turns a return into a future sale. I also wanted exchanges to handle price differences cleanly, so a customer swapping a $60 item for an $80 one pays the gap without a support ticket.

The returns app defaulted to refund-to-original-payment and treated store credit as the awkward exception. I was fighting the tool's defaults on every single return.

Chargebacks: zero-per-dispute evidence

The chargeback service charged me per dispute. I wanted automated evidence assembly: pull the order, the tracking, the delivery confirmation, the customer communication, package it, submit it. At zero marginal cost per dispute, because it's just code running.

Paying per dispute meant the service got more expensive exactly when fraud got worse. That's backwards.

Reviews: style-pooled across variants

My products come in sizes and colors. A black medium and a navy large are the same style. I wanted reviews pooled by style, so a customer sees all the feedback on the dress, not just the three reviews on the exact variant they're looking at.

Off-the-shelf review tools tie reviews to a single SKU. New variants launched with zero reviews even when the style had hundreds. That's a conversion killer for no good reason.

Loyalty: atomic redemption that can't double-spend

Loyalty points are money. If a customer can spend the same 500 points twice in a race condition, I'm minting free product. I needed atomic redemption with a transactional guarantee, so a point balance can't be drawn down twice in parallel.

The loyalty app had no such guarantee. It tracked balances but offered nothing transactional under the hood.

The pattern across all four is the same. The logic I needed wasn't a nice-to-have feature. It was core to how the brand makes and keeps money. This is what owning your business logic actually means in practice. It's not about controlling everything. It's about the handful of rules that are genuinely yours.

The Three Costs SaaS Hides

When you add up what a SaaS tool really costs, the sticker price is the smallest part.

The Three Hidden Costs of SaaS

Recurring and per-transaction fees

The SaaS subscription cost is the obvious one. But the per-transaction fees are the ones that hurt. A tool that charges per return, per dispute, per redemption gets more expensive as you grow.

That's the worst kind of bill. It punishes the exact thing you're working toward. You scale revenue and your software cost scales right alongside it, eating the margin you just earned.

The black box you can't extend

You can't extend a SaaS tool past what its roadmap allows. You can't see why it made a given decision. And your data lives in someone else's database, formatted their way, accessible only through their API on their terms.

When I wanted to feed return reasons into my own analytics and pricing models, the data was locked behind an export and a rate limit. I was renting access to my own customers' behavior.

Performance drag on your storefront

Every third-party app drops a script or an embed on your storefront. Four apps means four sets of scripts loading on pages where every hundred milliseconds costs conversion.

A slow product page is lost revenue you never see on a line item. It just shows up as a slightly worse conversion rate that you can't trace back to the reviews widget.

I want to be honest here. For a lot of businesses, none of these three costs matter enough to act on. A $50 a month tool with light traffic isn't worth replacing over performance. The dollar math only flips at real volume, and I've written up the math behind replacing four SaaS tools if you want to see the actual numbers. This is the cost side of the build vs buy ecommerce decision. The other side is harder.

What I Took On By Building

Here's the part most "build it yourself" articles skip. When you own the software, you own the edge cases and the maintenance. Forever.

The returns flow isn't just "issue store credit." It has to handle partial returns, damaged items, items lost in transit, returns past the window, and the customer who returns three of five items and wants the exchange on a different style. Every one of those is a branch I now have to handle and test.

The chargeback evidence assembly works great until the payment processor changes its API. When that happens, my evidence pipeline breaks silently and I lose disputes I should have won. That's now my problem to monitor and fix.

Loyalty is the scary one. A bug in redemption doesn't just annoy a customer. It can mint free points or let balances go negative. I've hit this failure mode for real, and the fix had to be fast because every minute it ran, it was giving away product.

There's no vendor to call at 2am. You become the vendor. When something breaks, the buck stops with you and your code.

I'm saying this plainly because it's the honest tradeoff. Building is not free. You trade a predictable monthly bill for an ownership burden that never goes away.

The reason it worked for me is specific. All four of these run as skills on the platform I run my brand on, a multi-tenant system I already maintain. The infrastructure, the monitoring, the deployment pipeline already existed. So the marginal cost of adding a returns skill was low.

That context matters enormously. Most businesses don't have a platform sitting there ready to absorb four new features. If you'd be standing up infrastructure from scratch, the math looks very different.

The Decision Rule: Is the Logic Core and Bespoke?

Here's the test I actually use, and it cuts through almost every build-vs-buy argument.

The Decision Rule: Core AND Bespoke 2x2 Matrix

Build when the logic is both core to your business and bespoke enough that no SaaS fits. Both conditions. Not one.

Rent the primitives, own the logic

The store-credit-only returns rule was core, because keeping money in the brand is how the unit economics work, and it was bespoke, because no returns app made it the default. So I built it.

Rent the Primitives, Own the Logic

But I still pay for the payment processor. I still pay for email infrastructure. I still pay for hosting. That's commodity plumbing. Building my own payment rails would be insane, the providers do it better than I ever could, and there's nothing about my version that needs to be different.

This is the principle I've written about as pay for primitives, build the logic. Rent the standardized pieces. Own the rules that make you money. It's also the core of the full build vs. buy framework I apply to every system.

When renting still wins

If the logic is generic and standardized, rent it. Email sending, payment processing, hosting, transactional SMS, error monitoring. These are solved problems where your version would be worse and more expensive.

The mistake I see CEOs make goes both ways. Some rent everything, including the rules that are their actual competitive edge, and wonder why they look like every competitor. Others want to build everything and burn a year reinventing email delivery.

Here's the clean test you can run today. List every recurring SaaS tool you pay for. For each one, mark two things: does it encode a rule that's unique to how you make money, and are you fighting against it to do what you need?

The tools that score yes on both are your candidates. That's it. Usually it's one or two out of fifteen.

Be clear with yourself that most of the stack should stay rented. If your audit produces a list of ten things to build, you've done it wrong. The whole point is finding the small number where ownership actually pays off.

The Results, And the Caveats

Let me give you the honest scorecard, the wins and the costs.

Build Scorecard: Wins vs Costs

What I got. The returns, reviews, chargeback, and loyalty logic now match exactly how the brand runs, no compromises. No more per-transaction fees, which matters more every quarter as volume grows. A measurably faster storefront with fewer third-party scripts loading on product pages. And all the data, returns reasons, review patterns, redemption behavior, now lives in my own database where I can feed it into analytics and AI.

That last point is quietly the biggest one. My pricing engine and my product decisions get smarter because the data is mine and it's all in one place.

What it cost. Real build time up front. Ongoing maintenance forever. And the full set of edge cases I now own, from lost-in-transit returns to API changes I have to chase down.

I'm not going to invent precise dollar figures, because the honest answer is the savings show up as a combination of eliminated subscriptions, eliminated per-transaction fees, and conversion lift from speed, and the maintenance cost is real but hard to pin to a number. Net, it was clearly worth it for me. At lower volume it would not have been.

Now the hard caveat. This made sense because I run on a platform I already own and can build on fast. The marginal cost of each new skill was low because the hard infrastructure was already there.

If you'd be standing up an entire infrastructure from scratch to replace a $50 a month app, do not do this. The math only flips at the right combination of volume and genuinely bespoke need. Get either one wrong and you've traded a small bill for a large headache.

How to Audit Your Own SaaS Stack

If you want a concrete next step that costs nothing, run the audit.

SaaS Audit Decision Flow

Pull your last twelve months of SaaS invoices. All of them. Sort by two questions. Which tools charge you per transaction in a way that scales with growth? And which tools are you actively fighting to make them do what your business actually needs?

The tools that show up on both lists are your real candidates. Most of your stack will stay rented, and that's the correct outcome. But the two or three tools that encode how you actually make money, the ones where you've built workarounds and accepted compromises, those are worth a serious conversation.

I've done this across my own brand and across other businesses, from a real estate syndication client to a payments startup. And the difference in how I work is that I build the replacement, not just advise on whether to. The recommendation and the implementation come from the same person.

If you're staring at a SaaS bill that keeps growing and a stack of tools that don't quite fit, that's exactly the kind of decision I help CEOs make, and then build the answer to. Sometimes the answer is "keep renting, it's fine." Sometimes it's "this one rule is your edge, let's own it." Either way you get a straight answer.

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