I Built a Custom Returns Management System (Simply Explained)

Returns Look Simple. They're Not.

Returns seem like the easiest part of running my DTC fashion brand in San Diego. A customer ships something back, you give them their money, you put the item back on the shelf. Three steps. Done.

In a warehouse, it's a mess in a cardboard box.

Here's the lie every returns software tells. It assumes that whatever the customer said they're sending back is exactly what shows up. It isn't. Items go missing on the way. The wrong size comes back. A customer returns two pieces of a three-piece set, and the software credits them for all three because the shipping label said three.

That gap between what's promised and what actually arrives is where your money quietly disappears.

I learned this the hard way. When I went to check my own returns, I found 506 open returns stuck in the system. Of those, 50 had been sitting for under 90 days and couldn't be processed at all. Not "nobody got to them." They physically could not be scanned in. The software had no way to receive them.

That's not a customer problem. That's a software problem. So I built my own returns system from scratch.

The Bug That Started It All

My scanning system worked great, as long as the return had been created inside my own software.

The problem? Not every return lived there.

For years I used an outside returns app, and I also let customers start returns directly through my store. Both of those were real returns with real refunds owed. But neither of them showed up in my system. So when my warehouse employee scanned a real box, the software looked in the only place it knew to look, found nothing, and gave up.

That's the 50 stuck returns. Real boxes, real customers, employee standing there scanning into thin air.

The fix was simple in concept. When a scan comes up empty, instead of quitting, the system now reaches out to my store, finds the return there, and pulls it in automatically. The employee never knows it happened. They scan, it works.

My first attempt at this made things worse. I had it pull in the entire original order, not just the items being returned. So the screen would show six items when the customer only sent back one. Now my employee is staring at a return that doesn't match the box.

That kind of wrong information kills trust fast. Once an employee sees one bad line, they stop trusting all of it and go back to checking everything by hand.

So I fixed it to pull in only the items tied to that specific return. The box matches the screen. The employee believes what they see.

Credit Only What Actually Showed Up

This is the heart of the whole thing, and it's the part most people doubt.

Most returns software works at the whole-return level. The box comes in, you hit accept, the customer gets credited for everything on the list. One button.

Mine works one item at a time.

When a box arrives, my employee marks each piece as either received or missing. Not the whole return. Each item.

Say a customer returns a three-piece set: a top, a skirt, and a jacket. The box shows up with the top and skirt. No jacket. Maybe it never got packed. Maybe it fell out. Doesn't matter why.

The employee marks the top and skirt received, and the jacket missing.

Here's what that changes. The customer gets credit for two items, not three. And only the top and skirt get added back into inventory. The jacket never arrived, so I never pay for it and never count it as in stock.

Every wrongly-credited missing item is straight loss out of my pocket. If your software credits the full return based on the label, you just paid a customer for a jacket you never got back. Do that a few hundred times a year and it adds up to real money.

The scary part? Before I built this, I had no idea how much I was losing, because nothing was tracking it.

Don't Pay Twice. Ever.

Once you start handing out money inside software, you create a new danger. Software does things more than once.

A double-click. A slow internet connection that retries. An employee re-scanning a box because they weren't sure it went through. Any of those can issue store credit twice for the same return. That's not a small bug. That's giving money away.

So I built a lock. In plain terms, no matter how many times the "issue credit" action runs, it only ever issues credit once. The system recognizes it already did the job and refuses to do it again.

I also made store credit the default instead of a cash refund. That's a business choice, not a technical one. For my brand, keeping that money working inside the store beats sending it back to a credit card. Your call might be different, and a good system should bend to your call, not the vendor's default.

Cleaning Up the Mess

A returns system rots if you only ever add to it and never clean it up.

Some items shouldn't come back at all. Wrong item, against the return policy, or damaged. For those, my system ships them back to the customer but charges a flat fee, so my brand isn't eating shipping in both directions.

Then there's the pile of returns that never finish. The customer changed their mind, never shipped the box, or it got lost. If you never close those out, they sit open forever and wreck every number you look at. Remember those 506 open returns I mentioned? That backlog existed because nothing ever closed them out automatically.

So I built a scheduled job that retires stale returns after they've sat too long. Now my open count reflects reality, not abandoned intent.

Should You Build Your Own?

Let me be fair to the software I used to pay for. It was fine, right up until my returns reality stopped matching its assumptions.

It could accept a return or reject a return. It could not say "two of these three showed up, credit two, restock two, ignore the third." That one missing ability was bleeding money on every incomplete return, and there was no setting to turn on to fix it.

Here's the honest part. Building your own doesn't make sense for everyone.

If your return volume is low, keep paying for the app. If your products always ship back complete (one simple item, no multi-piece sets), this whole problem barely exists for you.

You should think about building when reconciling "what came back" against "what got credited" is eating real employee hours, and when missing items are costing you money you can actually measure. If you've never measured that loss, that's a signal in itself. It usually means it's bigger than you'd guess.

Most brands have no idea how much they're losing to missing items, because their software never tracked the gap. The loss is invisible until you measure it. Then it gets uncomfortable.

Want to explore what AI could do for your business?

Book a free 30-minute strategy call. No pitch deck, no sales team, just a real conversation about your operations and where AI fits.

Book a Discovery Call