Skip to content
Writing
How we build

The shared core: what every product inherits on day one

Starting a new vertical product from scratch means spending the first three months on things that have nothing to do with the industry — sign-in, roles, tenancy, tax, exports, audit. We stopped doing that some years ago, and it is the main reason a new product reaches a real customer in months rather than years.

2 min readOadbox

What sits in the core

  • Tenancy and data isolation, decided once and enforced below the application layer.
  • Identity, sessions and device management, including shared-terminal patterns.
  • Role and permission modelling, down to field-level and record-level scope.
  • Statutory tax computation and document numbering.
  • Offline sync and conflict resolution for mobile.
  • Audit logging on every write, non-optional.
  • Reporting, filtering and export, in a form that behaves the same everywhere.
  • Notifications across email, message and in-app.

The criterion for inclusion

Something enters the core when it is expensive to build, dangerous to get wrong, and genuinely identical across industries. Audit logging qualifies. A fee structure does not, even though every industry has prices.

The failure mode of shared platforms is generalising something that only looked identical. We have made that mistake and the recovery is slow, so the bar is deliberately high.

Shared code needs a shared consequence

A core that eleven products depend on can break eleven products at once. That risk is managed by treating the core as a product with its own review, its own tests and its own release discipline — not as a folder anyone can edit in passing.

Breaking changes are versioned and adopted per product rather than pushed. The cost is some duplication of effort during migration; the benefit is that no product is ever forced to take a change on a day it cannot afford one.

Where it shows up for a customer

Mostly invisibly, which is the point. A customer notices it when the eleventh product has the same export behaviour as the first, when a permission model they learned in one place works the same in another, and when a mobile app that lost signal for an hour resolves cleanly.

They also notice it in the timeline. Most of what makes enterprise software slow to deliver is exactly this list.

Product teamArchitectureEngineering

Written by the Oadbox team. Something here not match how it works in your business? We would genuinely like to hear it — connect@oadbox.com.

Eleven products, already running. One of them probably fits how you work.

See it on your own data rather than in a slide deck — thirty minutes with someone from the product team.