Build vs Buy Software: I Replaced 4 SaaS Tools

The Four Tools That Each Owned a Piece of My Business

A year ago, my DTC fashion brand in San Diego ran on four systems that each owned a slice of the operation. None of them talked to each other cleanly. If you're a small business owner weighing build vs buy software, this is the exact situation that should make you stop and do the math.

Four disconnected tools with gaps between them

Here's what the stack looked like.

The first tool was a 3PL/WMS. It knew where my inventory physically sat and what shipped when. Good at one job, blind to everything else.

The second was a returns SaaS. It handled RMAs and refunds, told customers how to send things back, and processed the credits. It knew everything about returns and nothing about what happened to the product afterward.

The third was cloud file storage holding product specs, design files, tech packs, and photography. Everything that wasn't a transaction lived here in folders, named however whoever uploaded them felt that day.

The fourth "tool" wasn't software at all. It was tribal knowledge living in one ops person's head. The reason a SKU was flagged a certain way. The workaround for the carrier that kept mislabeling. The mental map connecting the other three systems. If she took a vacation, the seams between everything got wider.

That was the real problem. Each tool owned its slice competently. But my actual business lived in the gaps between them, and those gaps were held hostage by four different vendors plus one human memory.

The data didn't flow. It got copied, re-keyed, reconciled by hand, and occasionally lost. I was paying four monthly bills for the privilege of stitching them together myself.

I kept telling myself this was just the cost of running a small operation. It wasn't. The seams were leaking money, and I couldn't see exactly how much until I started measuring it.

Where the Seams Leaked Money

The expensive part was never any single subscription. It was the space between the tools where two systems had to agree and didn't.

Where the seams leak money, three failure modes

Inventory drift was the worst offender. The WMS said I had twelve units of a piece. The storefront, syncing on a delay, said fourteen. So we sold fourteen, then canceled two orders and ate the customer-service hit. On a typical week, my ops person spent four to five hours just reconciling stock counts between the two systems by hand. That's a quarter of a workday gone to making two databases stop disagreeing.

Stranded returns were quieter and more expensive. An item came back. The returns SaaS marked it received and issued the refund. Clean, as far as that tool was concerned. But the unit never got re-entered into sellable inventory in the WMS, because nothing automatically passed that information across.

So I'd already paid for the product, already refunded the customer, and now I had a sellable item that my own system thought didn't exist. Roughly one in five returns fell into this gap at our worst point. That's inventory I owned and couldn't sell because no system knew it was back.

Mis-ships came from stale data. When the file storage holding the latest product spec didn't match what the WMS pick list said, the wrong variant went out. That triggered a return, which triggered a refund, which sometimes triggered a replacement ship. One bad data point, three transactions of cost.

Add it up and the pattern is clear. I was paying four vendors to own four slices, then paying myself (in time and stranded product) to cover the seams they left open. The subscriptions were the visible cost. The leaks were the real one, and they never showed up on any invoice.

Why Build vs Buy Just Flipped for Small Business

For years, the build vs buy software question had an easy answer for small, ops-heavy businesses: buy. Writing custom software was slow and expensive. You needed developers, time, and a tolerance for things breaking. So you stitched together SaaS tools instead and lived with the seams.

The build vs buy math flip, glue used to be expensive, now it's cheap

That math was correct. It just isn't anymore.

The old calculus assumed the integration glue (the layer where SaaS tools actually fail you) was the most expensive thing to build. Custom plumbing between systems meant developer hours at developer rates, and small businesses couldn't justify it.

AI-assisted development flipped that. The glue is now the cheapest thing to build, not the most expensive.

Here's why that matters specifically. The boring plumbing between systems (pull from this API, transform the data, write it to that one, reconcile the differences, flag the exceptions) is exactly the kind of work where AI gives you the most lift. It's well-defined, repetitive, and pattern-heavy. That's the sweet spot.

The creative, judgment-heavy parts of software still take real skill. But the integration layer? The part that was killing me with manual reconciliation? That's now a fraction of what it used to cost to build.

So the build vs buy line moved. Not all the way. This doesn't mean you build everything from scratch and fire all your vendors. It means the specific layer where SaaS sprawl costs you the most, the connections between tools, is now cheap enough to own.

For a skeptical CEO, here's the sharp version: you used to rent the glue because building it was uneconomical. The economics changed. The thing you were renting at a premium is now the affordable part to build.

Pay for Primitives, Build the Logic

Once the math flips, the next question is what to build and what to keep renting. The framework I use is simple: pay for the primitives and build the logic yourself.

Pay for primitives, build the logic framework

Rent the primitives. Database, hosting, and compute. Carrier APIs for shipping labels and tracking. Your storefront and payment APIs. These are commodities with genuine economies of scale you will never beat. A carrier has negotiated rates and infrastructure you can't replicate. A payment processor has compliance and fraud systems you don't want to own. Renting these is correct, and it's cheap.

Own the business-logic layer. This is the part that ties fulfillment, returns, file storage, and process knowledge into one source of truth. The rules that say "when a return is received, re-enter it into sellable inventory and update the storefront." The logic that's specific to how your business actually runs.

Here's the trick most owners miss. The SaaS tools that were bleeding me weren't selling primitives. They were selling the logic layer wrapped around primitives I could have rented directly. My returns SaaS was a set of business rules sitting on top of a database and some email. My WMS was logic on top of storage and carrier APIs.

I was paying a premium for the wrapper, and the wrapper held my data hostage so I couldn't connect the systems myself.

So I rented the primitives directly and built the logic that connected them. One source of truth, my rules, no seams. If you want to see the unified system I built to replace those four tools, here's the full stack I run a real apparel brand on.

The point isn't that SaaS is bad. It's that you should know exactly what you're paying for. Often you're paying logic prices for commodity primitives, and you're losing control of your own data in the bargain.

The Math: What I Actually Paid vs What I Replaced

Let me run the honest numbers, anonymized but real in shape.

The four subscriptions together ran in the range of $1,200 to $1,800 a month depending on volume tiers. That's $15,000 to $21,000 a year in recurring cost, just to keep the four slices alive.

The build cost was my time plus primitive costs. The primitives (database, hosting, compute) run me a small fraction of the old SaaS bill, somewhere in the low hundreds per month. The development time was real, but with AI-assisted development it was weeks, not the months or quarters that same work would have taken a few years ago.

That alone made the payback obvious. But the subscription savings were never the main prize.

The hidden cost the subscriptions never put on the invoice was the leak. The four to five hours a week of manual reconciliation. The one-in-five returns that never re-entered inventory. The canceled orders from overselling. The mis-ship refunds from stale data.

When I rebuilt the logic so returns automatically flowed back into sellable inventory and stock counts reconciled themselves, that entire category of loss disappeared. The stranded inventory came back online. The reconciliation hours went to zero.

Across all the AI systems I've built for the brand, I'm saving over 3,000 hours a year and I cut manual operations time by 42%. The integration rebuild was one of the biggest single contributors to that, because it killed work that produced nothing but a chance for two systems to disagree.

Now the honest part. I own the maintenance now. When a carrier changes an API or something breaks, that's on me, not a vendor's support queue. That's a real cost and it's not free. I don't pretend otherwise.

But trading $15,000-plus a year in subscriptions plus thousands of hours of leak for low-hundreds-a-month primitives and some maintenance I control? That wasn't close.

When You Should NOT Build

I'm not going to tell you to build everything. That's how consultants leave you with a system nobody can run. Here's where buy is still the right answer.

Compliance-heavy and liability-heavy systems. Don't build payroll tax. Don't build regulated compliance reporting. Don't build payment processing from scratch. These come with legal exposure and regulatory cover that vendors absorb for you. The cost of getting it wrong dwarfs any savings.

Anything where the vendor's scale genuinely beats you. Carriers, payment networks, fraud detection at scale. These have real network effects and infrastructure you cannot replicate at your size. Renting them isn't a compromise, it's the smart move.

Anything nobody at your company can maintain. This is the one that catches people. If you build a custom system and the only person who understands it walks out the door, you've recreated the tribal-knowledge problem with extra steps. Custom software you can't maintain is a liability dressed up as an asset.

The line is this. Build the integration glue that's unique to your business, the logic that no vendor sells because it's specific to how you operate. Buy the commodity infrastructure and the genuinely hard regulated stuff.

If you want a deeper version, here's a decision framework for build vs buy vs hire that walks through the full call. And if you're curious about the broader pattern, these were part of the five SaaS subscriptions I deleted this year.

How to Run This Calculation for Your Own Business

You can run this assessment this week. Here's the process.

Three-step assessment process for your own business

Step 1: List what each tool actually owns. Go through every SaaS subscription and write down what data it owns exclusively. Not what it does, what it knows that nothing else does. Be specific. This is where you'll see how scattered your source of truth really is.

Step 2: Find where the seams leak. Look for every place two tools have to agree and don't. Inventory counts, customer records, order status, anything that gets copied or re-keyed between systems. For each seam, put a dollar figure on it: hours spent reconciling, money lost to errors, product or revenue stranded in the gap. This is the number that never shows up on an invoice, and it's usually bigger than the subscriptions.

Step 3: Separate primitives from logic. For each tool, ask: is this a commodity primitive (storage, compute, carrier API, payments) or is it business logic wrapped around one? The primitives you keep renting. The logic is your candidate to own, especially where it sits across the seams you just priced out.

That's it. Three steps, a weekend of honest looking, and you'll know whether your build vs buy math has flipped the way mine did.

This is exactly the assessment I run as a Chief AI Officer before I build anything. I map the tools, price the seams, and find where owning the integration layer pays for itself fastest. In my experience, that integration layer is almost always where the fastest ROI hides, because it's the work everyone hates and no vendor sells.

Thinking about AI for your business?

If this resonated, let's have a conversation. I do free 30-minute discovery calls where we look at your operations and find where AI could actually move the needle, starting with the seams that are quietly leaking money right now.

Book a Discovery Call