Most of what I write here compares tools other people built. This one is different — it's about a decision I made myself: building a white-label e-commerce platform from scratch instead of buying one off the shelf, and what that decision actually cost in time and what it bought back in control.
The Starting Question Nobody Asks Early Enough
Before picking a single line of tech stack, the real question was: does this need to be multi-tenant from day one, or can it start single-tenant and get refactored later? I chose to architect it as multi-tenant early — every client's data logically separated, but running on shared infrastructure rather than spinning up a new instance per client. That decision alone shaped almost everything downstream: database schema design, how permissions worked, how billing per client would eventually plug in.
In hindsight, this was the right call for the specific goal (a platform meant to serve many white-label clients), but it's genuinely more upfront complexity than a single-tenant MVP. If the goal had been "prove this works for one client first," I'd have built single-tenant and refactored later — refactoring toward multi-tenancy is painful, but building multi-tenancy you don't need yet is a different kind of painful, upfront instead of later.
Monolith vs Services: Where I Landed
I built it as a monolithic MVC application, deployable on standard cPanel shared hosting — not microservices, not a separate API layer with a decoupled frontend. This gets criticized in a lot of "modern architecture" advice, and for good reason at scale. But for a platform meant to be sold and deployed to clients who mostly have ordinary shared hosting, not Kubernetes clusters, a monolith that a single hosting account can run is a real business requirement, not a technical shortcut. The trade-off is real: scaling a monolith horizontally is harder later, and a bug in one module can theoretically affect others more easily than in a properly isolated service. I accepted that trade-off deliberately, not by default.
The Part I'd Actually Change
If I were starting over, the thing I'd do differently isn't the framework or the hosting model — it's how early I locked in database schema decisions before fully understanding how courier and payment integrations would eventually need to hook in. Payment gateway integrations and courier/shipping provider APIs each have their own opinionated data shapes, and retrofitting a schema designed without them in mind cost more rework than it should have. The lesson that's actually generalizable: for any platform planning third-party integrations, sketch the third-party API's data model before finalizing your own schema, even if the integration itself comes later in the build order.
What This Has to Do With Buying vs Building
This is the actual point of writing this up: every "should I build or buy" comparison — and I've written several tool-comparison posts on exactly that question — assumes the buyer knows enough about their own requirements to evaluate the built options fairly. Building this platform taught me things about multi-tenancy, schema design against third-party integrations, and deployment constraints that I simply didn't know to look for when I was only ever evaluating other people's software from the outside. If you're seriously considering building instead of buying for your own business, the real cost isn't the code — it's the requirements you don't know you have yet, and you only find them by hitting them.
Where This Leaves Me Now
The platform runs, serves real clients, and the architecture decisions mostly held up — the schema rework was the one genuine regret, not the monolith choice or the multi-tenancy choice. If you're weighing a similar build-vs-buy decision for your own business and want to talk through the specific trade-offs, reach out on the Contact page — I'm more useful for this kind of conversation than another feature-comparison table would be.