Path 1: Your engineering team builds it. They scope it at 3 months. They build a basic integration. Shopify data flows, alerts fire, everyone high-fives. Then the edge cases start.

Path 2: Someone vibe-codes it with Claude Code. They get a working prototype in a weekend. Shopify webhook listener, a basic rules engine, Slack notifications when something looks off. It's genuinely impressive. It also covers about 5% of what you actually need.

The prototype problem is the same in both cases. Getting data from A to B isn't hard. Knowing what to do with it across 80+ problem types, 50+ integrations, and thousands of edge cases is where years of operational intelligence live.

Claude Code is an incredible tool. We use it ourselves. But there's a difference between using AI to accelerate development and assuming AI removes the need for domain expertise. A weekend prototype doesn't know that StarTrack's API returns "delivered" 6 hours before the parcel actually arrives. It doesn't know that CIN7 inventory syncs silently fail on public holidays. It doesn't know that a specific carrier's "attempted delivery" status means something completely different in regional WA than it does in metro Sydney.

That knowledge comes from processing millions of orders across dozens of brands over years. No amount of vibe-coding compresses that into a weekend.

Most engineering teams, or a sharp ops person with Claude Code, can get a basic integration running fast. Pull order data from Shopify. Check fulfilment status against the warehouse. Fire off a Slack alert when something looks wrong. That's the easy part. That's about 5% of what Keeyu does.

Here's what the other 95% looks like:

That last point deserves emphasis. Edge cases in post-purchase ops aren't theoretical. They're the difference between a system that works in a demo and a system that works on Black Friday when your carrier marks 200 parcels as "delivered" that are still sitting in a depot, your warehouse is running a day behind on picks, and your payment provider flags a batch of legitimate orders as potentially fraudulent. All at the same time.

When teams say "we'll build it ourselves," they're usually picturing a monitoring tool. Something that watches for problems and sends alerts. That's the system of detection. It's the most visible layer, and it's the easiest to build. Which is exactly why teams think the whole thing is buildable.

But detection without decision is just noise. And decision without action is just a to-do list for an already-stretched ops team.

Keeyu runs three systems, and each one is an order of magnitude more complex than the last:

System of Detection. This connects to every system that touches the customer promise and watches for the moment something threatens it. The challenge isn't connecting to one API. It's maintaining live connections to 50+ systems, normalising data across completely different formats, and detecting anomalies across all of them simultaneously.

System of Decision. This is where it gets genuinely hard. Once an issue is detected, what do you do about it? These aren't simple if/then rules. They're decision trees that branch across hundreds of scenarios, informed by patterns learned across 100+ brands.

System of Action. This is where most internal builds never arrive. Detection alerts you. Decision tells you what to do. Action does it. Automatically. Keeyu uses multi-agent orchestration to execute these workflows, with specialised agents handling different parts of the resolution.

If you played with the calculator above, you already saw how fast the numbers stack up. But it's worth understanding why the build cost isn't what your team thinks it is.

The upfront build is just the deposit. The calculator applies Brooks's Law for a reason. Three engineers don't build it in one-third the time of one engineer. Realistically, 3 engineers at $160K each are looking at 7 months and $280,000 before a single issue is detected, let alone resolved.

Maintenance isn't maintenance. It's continuous rebuilding. AI platforms and integration ecosystems aren't "set and forget." Models drift. APIs change. Carriers update tracking formats quarterly. Shopify ships platform updates that break existing webhooks. Most teams go through 1 to 3 major rewrites over three years, each costing roughly 40% of the original build.

At Keeyu, we have a dedicated engineering team whose entire job is keeping 50+ integrations current. That's not a side project. That's a full-time operation, and the cost is amortised across every brand on our platform. When you build internally, you carry that cost alone.

The running costs nobody puts in the spreadsheet. Every order triggers a cascade of API calls. At 30,000 orders a month, you're looking at north of $30K a year just in API costs. Add AI token costs for every automated resolution. Add infrastructure. None of this appears in the "3 engineers for 3 months" estimate. All of it appears on the P&L.

This is the number in the calculator that changes the conversation.

While your team spends months building, every ticket is still being handled manually. Every swivel-chair session between 15 tabs. Every 45-minute resolution that should take 5. Every customer who churns silently because nobody caught the issue before they gave up.

The calculator puts a dollar figure on this, and it's usually the biggest line item in the entire comparison. At typical volumes, that's $30-40K a month in savings you're not capturing while your team builds. Over a 6-month delay versus being live on Keeyu in 30 days, that's $180-220K in foregone savings.

The vibe-code path compresses this delay. Maybe you're live in a month instead of seven. But "live" with a prototype that covers 5% of your problem types isn't the same as live with a platform that covers 80+. The savings gap is smaller, but the operational gap is just as wide.

Let's be direct about this because it's the objection that's getting louder every month.

Claude Code is transformative. We're not going to pretend otherwise. Our own team uses AI coding tools every day. But here's what a vibe-coded post-purchase solution actually looks like in production:

The irony of vibe-coding your own post-purchase monitoring is that you end up needing someone to monitor the monitor.

The speed of vibe-coding is real. But speed to prototype isn't speed to production. And production in post-purchase ops means handling every carrier exception, every payment edge case, every warehouse sync failure. Reliably. Silently. At scale. That's not a weekend. That's years of compounding operational knowledge.

Every tool in your stack exists because someone decided the build-vs-buy math didn't work. You didn't build your own storefront. You didn't build your own ERP. You didn't build your own helpdesk or returns platform.

Each of those is a category-specific platform built by teams who do nothing else. Hundreds of engineers. Years of iteration. Thousands of customers' worth of edge cases baked into the product.

Post-purchase operations connects to the same systems. It requires the same depth of integration. It demands the same ongoing investment. The complexity is equivalent. The only difference is that the category is newer, so the "we could build this" instinct hasn't been trained out of the market yet.

But the math is the same. And the calculator above proves it.

Your team probably can build a basic version. A sharp person with Claude Code definitely can. Most good teams can get 5% of the way there fast. The question is: should they?

Run the numbers in the calculator above. Then ask your team one honest question: do we want to be in the integration maintenance business, or do we want to be in the business we're actually in?

One of our customers put it best. When asked what they'd do without Keeyu, they said: "I just wouldn't come to work tomorrow."