The problem: you don't own a store, you rent a stack
If you have ever run a shop on a hosted e-commerce platform, you know the feeling. You sign up for a tidy monthly plan, and within a fortnight your "cheap" store is quietly bleeding money. Reviews? That's an app. Loyalty points? Another app. A referral programme, a proper blog, multi-currency, subscriptions, a help desk, B2B quotes? Apps, apps, apps — each one £15–£40 a month, each one another dashboard, another dependency, another thing that breaks when the platform updates.
Then there is the part nobody puts on the pricing page: the transaction fee. Many platforms take a percentage of every single sale on top of what your payment processor already charges — purely for the privilege of using their checkout. On thin retail margins, that "small" percentage is often the difference between a healthy month and a break-even one.
We built Dirora because we were tired of watching good businesses pay a tax on their own success. The idea was almost embarrassingly simple: what if the features you'd normally rent as add-ons just came in the box — even on the free plan? Our one-liner became the whole product thesis: everything you'd pay extra for, included.
This is the story of how we turned that thesis into a multi-tenant platform with 68+ built-in features, and the architecture decisions that made it possible.
The core bet: features are a platform problem, not a marketplace problem
The dominant model in e-commerce is a small core plus a giant third-party app marketplace. It is a good business model — for the platform. It offloads feature development to thousands of developers and monetises merchants twice (plan + app subscriptions). But it makes the merchant's total cost of ownership unpredictable and high.
We made the opposite bet: build the long tail of commerce features natively, as first-class parts of the platform, and price the platform so growth is rewarded rather than penalised. That means the same feature set — reviews, loyalty, multi-tier referrals, gift cards, subscriptions, multi-currency and multi-language, a professional blog and page builder, a help desk, B2B quotations, manufacturing with bills of materials and purchase orders, partner programmes, fraud protection, SEO tools and more — is available on every plan, including the free one. Plans gate limits (products, staff seats, storage), not capabilities. A one-person shop on the free plan has the same toolbox as an enterprise; only the scale changes.
That bet only works if the engineering underneath can carry dozens of real features without collapsing into a monolith. So the architecture had to be right from day one.
How we built it
Multi-tenant from the first commit
Dirora is multi-tenant by design. One deployment serves many stores, each fully isolated, each reachable at its own subdomain or a custom domain with automatic SSL. Getting isolation right early — so one tenant's data, themes, and settings can never leak into another's — is far cheaper than retrofitting it later. Every domain service is scoped by tenant at the data layer, and cross-tenant reads are the exception, not the rule.
A fleet of small Go services, not one big app
The backend is built in Go, split into 40+ microservices along clean domain boundaries: catalogue, orders, payments, subscriptions, content, quotations, inventory and supply chain, notifications, and so on. We chose Go for the obvious reasons — it is fast, its concurrency model suits request-heavy commerce workloads, and its static binaries keep services lean.
The less obvious benefit is organisational: small service boundaries let us add a whole new capability (say, a quotations engine or a manufacturing module) without bloating an existing codebase or risking a regression in checkout. Read-heavy endpoints — product listings, search, collection pages — stay quick under load because they are handled by focused services with their own data access patterns. PostgreSQL is our system of record, with Redis for caching and an S3-compatible object store for media, all fronted by Traefik for routing.
API-first, so the UI is just another client
This is the decision we are proudest of. Every capability in Dirora is designed as an API endpoint first; the admin dashboard and the default storefront are simply consumers of that same contract. There is no hidden "UI-only" feature — if the admin can do it, so can your integration.
Being API-first pays off three ways. Parity: merchants and developers are never blocked because a feature only exists in the dashboard. Stability: because our own front ends depend on the API, breaking changes are expensive for us too, which keeps our incentives aligned with the people building on us. Composability: you can adopt one slice — read-only product data for a marketing site, or a headless storefront — without rebuilding checkout. The public REST API, OAuth, and webhooks are what let third-party developers build and publish to our app and theme marketplaces, and what let merchants wire Dirora into the rest of their tools.
A visual theme engine, not a code-only theme system
Design is where most "developer-first" platforms lose non-technical merchants. We built a visual theme editor with a layout engine, live preview, undo/redo history, and a library of storefront widgets, plus support for custom CSS, fonts and Custom HTML for people who do want to go deeper. Server-side rendering, automatic image optimisation and structured data ship by default, so stores are fast and crawlable without anyone touching a config file.
The economics we engineered on purpose
The feature set is only half the promise; the pricing is the other half. Dirora charges no transaction fees on any plan. The only cut we take is a small platform fee that falls as you grow — from 1.5% on the free Starter plan to 0.75% on Pro, 0.25% on Business, and 0% on Enterprise. Plans are £0, £19, £59 and £299 a month, with two months effectively free on annual billing. When a merchant is fighting for a couple of pounds of margin per unit, the platform should not be first in the queue — and by design, it isn't.
What merchants actually get
Because the platform carries the features, onboarding a real store doesn't mean assembling a stack of subscriptions. Out of the box you get physical and digital products, subscriptions, gift cards, bundles, and made-to-order/fractional selling; multi-currency and multi-language storefronts with AI-assisted translation; a marketing suite (email campaigns, reviews, multi-tier referrals, promotions); B2B quotations with quote-to-order conversion; manufacturing with components, production and purchase orders; a help desk; and a growing live integrations directory — FreeAgent for accounting, Royal Mail Click & Drop for fulfilment, Google Analytics, Meta and TikTok pixels, Slack, Discord and more — all installable without code. Payments run through Stripe (cards at standard rates, Apple Pay, Google Pay, Klarna, Clearpay) with PayPal available.
The honest part
Building features natively is slower than curating a marketplace. Every capability we ship is one we have to maintain, support and secure ourselves. We accept that trade because it is the only way to make the pricing promise real: you cannot credibly say "everything included" if half the "everything" is someone else's paid add-on. Multi-tenancy and an API-first contract also impose discipline — you move a little more carefully when every service is a public product — but that discipline is exactly what keeps the platform stable as it grows.
Try it
If you have ever added up your monthly app subscriptions and winced, that spreadsheet is the reason Dirora exists. You can spin up a store on the free plan and see the whole feature set — the same one enterprises get — at dirora.com, and weigh the true cost against your current stack on our comparison page.
We didn't build a smaller core with a bigger marketplace. We built the box big enough to hold everything you'd otherwise rent.
Top comments (0)