Building in public: why I built a custom order management system for a tablecloth webshop instead of buying one, what broke, and what low-and-slow taught me about software.
Conventional wisdom says you shouldn’t build what you can buy, that you should use the off-the-shelf thing and not reinvent the wheel. Conventional wisdom is usually right, which is exactly why it’s so boring, and just often enough why it’s wrong.
I run a webshop that sells tablecloths. Table skirts, to be precise, the pleated kind you see wrapped around buffet tables at events. Not glamorous, I know, but stick with me.
Why I didn’t just buy one
Every order management system I looked at was built for a shop that works like most shops do, and mine doesn’t, in a handful of small but stubborn ways. Each plugin treated those ways as some rare edge case, whereas for me they were just Tuesday. You’ll recognise the feeling if you’ve ever tried to bend a piece of SaaS around a process it was never shaped for: at some point you notice you’re spending more time fighting the tool than actually doing the work it was meant to save you.
So I did the thing you’re explicitly not supposed to do, and I built my own.
Low and slow
This is where my actual hobby leaks into the work. I do barbecue, the proper low-and-slow kind, where a brisket takes the better part of twelve hours and the whole point is that you genuinely cannot rush it. Crank the heat to finish sooner and what you pull off the grill is a grey, tough disappointment. Patience there isn’t a virtue you bolt on afterwards; it’s the actual mechanism that makes the thing work.
Software turns out to be the same, and I keep having to relearn it the hard way. The version of the order system I tried to slam together in a single hot weekend was exactly that grey, tough disappointment. The version that actually runs my shop today is the one I built slowly, in unglamorous layers, testing each part against real orders and letting the whole thing cook.
The prompt-hack crowd will always sell you the high-heat sear, but the work that lasts is low and slow. I wish that were a more exciting thing to believe, and the fact that it isn’t is rather the point.
What broke
Plenty broke, and building in public means showing the burnt ends along with the good bits.
I built the pretty dashboard first, of course, because that’s the fun part. I spent a genuinely happy weekend on something nobody actually needed while the boring synchronisation logic, the part nobody ever sees but everybody quietly depends on, sat there unbuilt and judging me. Then I assumed my own process was far more standard than it really was, which is funny in hindsight given that “my process isn’t standard” was the entire reason I’d started building in the first place. And the edge cases I underestimated the way absolutely everyone underestimates edge cases: confidently and repeatedly, right up until the morning one of them finally bit me.
None of it was a disaster, though. It was tuition. You pay it in lost time and mild embarrassment, and what you get back is a system that fits the business in a way nothing off the shelf ever could have.
Should you build your own?
Probably not, honestly. See above: conventional wisdom, usually right.
But “don’t reinvent the wheel” quietly assumes the one on the shelf actually fits your cart. Mine didn’t, and no amount of clever configuration was going to make a square thing roll. The honest move is to admit that early, before you’ve sunk six months and a stack of weekends into pretending otherwise.
That’s what building in public means to me. Not a polished case study with the failures quietly airbrushed out, but the real version: here’s what I did, here’s what broke, here’s what I’d do again tomorrow. Take whatever part of it is useful to you, and feel free to leave the brisket metaphors behind if they’re not your thing.
(I’ll add the real numbers, orders processed and hours sunk and money saved-or-not, as the system racks them up. Building in public means the receipts come too.)