When identity, billing, tax, admin, catalogue and native mobile arrive already wired together — and a million-product catalogue imports in about 40 minutes — a two-person studio can credibly serve enterprise clients. Five concrete, buildable product ideas: a sovereign B2B portal, a multi-location booking platform, a membership library, a white-label marketplace, and an agent-callable catalogue for AI shopping.
Enterprise software used to require an enterprise to build it — not because of the interesting part, but because of the vast, undifferentiated plumbing underneath. Take that plumbing off the table and the equation inverts.
There is a quiet shift in what a two-person studio can credibly promise a large client. For most of the last decade, enterprise-grade software — identity, billing, tax, an admin back office, a real catalogue, native mobile — was a reason to hire twelve engineers, not two. Those building blocks took quarters to assemble and years to harden. The moment they arrive already wired together, the arithmetic of who can serve whom changes. A small team stops competing on headcount and starts competing on judgement.

That is the practical promise of a full-stack, self-hosted SDK such as VBWD: one Python backend core, a Vue/TypeScript web front end, and native iOS and Android SDKs, all driven from the same backend. Payments, subscriptions, catalogue, CMS, booking, chat and an agent-callable MCP interface are plugins over an intentionally agnostic core, each switching on or off without a restart. The leverage point worth naming plainly is throughput: on VBWD’s own internal benchmark — and benchmarks vary by data shape and hardware, so treat it as directional — a one-million-product catalogue of complex products imports in roughly 40 minutes, against three hours or more on a typical legacy commerce platform. When the infrastructure does that much heavy lifting, a small studio can run a large enterprise’s stack without pretending to be a large enterprise.
Here are five products a lean studio could realistically ship this quarter on that substrate.
1. A sovereign B2B commerce portal for a regulated EU manufacturer
Who buys it: mid-sized German or Nordic manufacturers selling into distributors and trade accounts, who need contract pricing, tax handling and a deep product catalogue, and who are increasingly nervous about where their data lives. Why now: data residency has stopped being reassurance enough for many procurement teams. Why a small team can build it: the catalogue import throughput above means even a sprawling industrial parts list loads in an afternoon, not a fortnight, and self-hosting keeps the whole stack inside the client’s own boundary. The studio spends its time on pricing logic and integration, not on rebuilding commerce primitives from scratch.
2. A multi-location booking platform for a clinic or gym chain
Who buys it: a physiotherapy group, a dental network, or a boutique fitness chain running fifteen sites on a patchwork of calendars and spreadsheets. Why now: these operators want one system across locations without surrendering their patient or member data to a US-owned SaaS. Why a small team can build it: booking, identity and subscription billing are already plugins on the core. The studio configures the workflow and the branding rather than authoring the scheduling engine, and can stand up a working pilot for one location before rolling it across the estate.
3. A subscription library or membership product
Who buys it: a specialist publisher, a professional association, or a training provider that wants recurring revenue and gated content under its own brand. Why now: memberships are how content businesses survive, and off-the-shelf platforms take a cut and hold the customer relationship. Why a small team can build it: subscriptions, a CMS and identity ship together, so the studio ships the catalogue of what members get and the renewal logic — the plumbing of billing cycles, entitlements and login is already there.
4. A white-label marketplace
Who buys it: an industry body or a founder who wants to run a curated marketplace of vendors in a vertical — trades, artisanal food, professional services — without paying a platform tax to an incumbent. Why now: vertical marketplaces win on trust and curation, both of which favour a smaller, closer operator. Why a small team can build it: catalogue, payments and an admin back office are the marketplace. The studio adds the vendor onboarding and the commission model on top, and the self-hosted footprint means the operator, not a third party, owns the transaction data.
5. An agent-callable (MCP) catalogue for AI shopping
Who buys it: a forward-leaning retailer or distributor who wants their catalogue to be legible to AI shopping agents, not just to human browsers. Why now: MCP ships natively, so exposing a catalogue to an AI agent is a configuration exercise rather than a research project — and being early here is cheap while it is still novel. Why a small team can build it: the agent interface and the catalogue live in the same system, so the studio wires an existing product database to an existing MCP surface instead of inventing either.
A word of honest caution, because leverage is not magic. Pre-wired building blocks compress the build; they do not abolish the run. A studio that ships a clinic’s booking platform still owns the operations, the on-call rota, the backups and the awkward 2 a.m. incident. Self-hosting means sovereignty, and sovereignty means the buck stops with you rather than with a vendor’s status page. There is also a maturity trade to make plainly: an SDK like this is younger than the twenty-year-old incumbents, and it swaps some accumulated edge-case hardening for modern architecture, speed and auditability. For a great many businesses that is the better trade. For a few — those living entirely inside one legacy platform’s long tail of quirks — it is not. A serious studio says which one its client is before it signs.
What the substrate really changes is the shape of the bet. It lets a small, sharp team credibly quote work that used to require a division, and it lets that team spend its scarce hours on the parts a client actually pays for — the domain logic, the integration, the judgement — rather than on rebuilding commerce, identity and billing for the hundredth time. If you want the underlying reasoning, VBWD’s own write-up on how a small studio runs an enterprise commerce stack is a fair place to start.
If this maps to a conversation happening inside your own organisation, the useful next step is specific rather than generic: see your own workload on modern, self-hosted infrastructure. Request an enterprise installation and bring the numbers you’re trying to improve.
Sources: VBWD internal benchmark (catalogue import figures, directional).