Custom
Platforms
Software with users who are not your employees: tenants, roles, onboarding, billing and uptime. A platform is a commitment to operate something, not a delivery date.
The problem
You are no longer building a tool for your own team. People outside the company will log in, pay, depend on it and complain to somebody when it breaks — and very little about how internal software is built, staffed or budgeted survives that change.
Why a package will not do
A platform is a different commitment from a project. The build is the smaller half of it. What makes it hard is that people will be using yesterday’s version while you ship tomorrow’s, and none of them agreed to be interrupted.
That shapes the architecture from the first week. Who a tenant is and what they must never see. Roles that survive an organisation restructuring itself. Onboarding that works without you on a call. Billing, because it touches everything and is the worst thing to add late. Reporting that answers a customer’s question rather than only yours.
It also shapes what happens after launch, which is where a platform is won or lost. Releases that need no maintenance window. Migrations that run while people are logged in. Support with enough context to answer and enough instrumentation to know what changed. Capacity added before it is missed rather than after somebody notices.
None of that is bought as a package, because a package cannot make those decisions for a business it does not know. It is built, operated and extended — and the first version is deliberately smaller than the one you arrived with, because the fastest way to learn what the platform should be is to have real customers using a smaller one.
How we approach it
01
Discovery
Who the users are, what they will pay for, what they must never see, and which promises the business is ready to keep.
02
Architecture
Tenancy, roles, billing and the reporting model — the four decisions that are cheap now and structural later.
03
Build
A first version smaller than the one you arrived with, in front of real users early enough to change what comes next.
04
Scale
Releases without a maintenance window, migrations while people are logged in, capacity added before it is missed.
Proof
NexusGrounds, the company's own consumer platform, live and operated by the team that built it. Guests and account holders, daily quotas, subscriptions and entitlements, three payment processors behind one interface, and a retention clock on every class of data it holds.
Pizza Pe Bune, a restaurant operating system, multi-tenant from the first table. Four order channels into one kitchen, a floor POS, cash ledgers per person and role, and one native app that becomes six products depending on who signs in. The rest is built and switched off.
Is this the right fit?
For companies becoming an operator of software — users outside the business, a roadmap, and an obligation to keep it running. If what you need is a system your own team uses, custom software is the smaller and better-defined version of this.
It starts with a discovery, and for a platform that includes deciding how small the first version has to be.
What a discovery includesContact