Customizable

Built customisable. Not built bespoke.

Every customer runs on the standard platform, with their differences configured on top. The target API adapts to the system you write into, so what makes a customer special rarely turns into a change to the product.

01Position

Why this matters commercially

Customisation is where platform businesses quietly lose their margin. These three things decide whether it does.

🧱

You only maintain the differences

Platform and configuration stay separate. What you adjusted is yours to look after, everything else stays standard and keeps getting updates.

A special request is a setting

What one customer needs differently is configured, so the answer is rarely 'next release'.

🏷

Your brand, start to finish

Your domain, your logo, your colours. The customer never learns that we exist.

02Mechanics

How it works

From signal to outcome in four explicit steps, with no hidden hand-offs.

  1. Start from the standard

    A new customer gets the standard solution, which is also the one that has already been proven everywhere else.

  2. Configure what differs

    Screens, fields, steps and permissions are adjusted for that customer, without a separate version of the product being created for them.

  3. Connect the system you already run

    Our target API adapts to your system rather than the other way round, so you change nothing on your side to make it fit.

  4. Ship it under your brand

    Domain, logo and colours are yours, and the customer sees your product from the first email onwards.

03Capabilities

What's inside

Every headline backed by a concrete workflow. Screenshots show what your team will actually use.

Capability 01

Standard first, adjustments on top

A new customer starts on the standard solution. What they need differently is configured on top, and because the two stay separate, the standard underneath keeps updating while only the adjustments belong to that customer.

Capability 02

It fits the system you already run

Your own system sets the terms. Our target API adapts to it, so you do not rebuild anything on your side to make the two work together. Extending what gets written across stays a setting rather than a project.

ScreenshotIt fits the system you already run screenshot

Want to see it shaped to your setup?

20-minute call. Tell us what your customers ask for that your current tool cannot do, and we show you where it would sit.

Capability 03

One set of permissions for people and AI tools

Who may see and do what is decided once, and it covers your team as well as the AI tools they use. Not two lists of permissions that quietly drift apart.

Capability 04

Adjustable down to a single field

Screens, forms, fields and where each of them appears. If one customer needs one more field in one place, that is an adjustment and not a development ticket.

Capability 05

It ends up looking like your product

Your subdomain, your logo, your colours, or a domain of your own. The customer sees your brand from the first email to the last screen and never learns ours.

04Use cases

Situations we keep seeing

Anonymised from our customer base. See whether one of them is yours.

One platform, two industries

Scenario

The same product serves two customer groups whose requirements barely overlap, and every release turns into a compromise between them.

Outcome

Each group runs its own configuration on the same platform, so a change for one stops being a risk for the other.

A customer asks for something the standard does not do

Scenario

A large account makes a request that would normally end up on a roadmap and stay there for two quarters.

Outcome

In most cases it is configured for that account within the standard, and the roadmap stays free for what the product actually needs.

Partners resell under their own brand

Scenario

Implementation partners want to sell the platform as part of their own offering, not as somebody else's tool.

Outcome

Each partner gets their own branded environment, so their customers see one product rather than a chain of vendors.

05What we replace

What we do differently

Three ways customisation usually turns into a liability.

A branch per customerEvery special request becomes a version somebody has to maintain. Two years later, half the team is keeping old promises alive.
A tool that does it one wayWorkarounds start as a favour to one customer and end up as the way you work. Nobody remembers why.
Tools glued togetherEach gap gets its own connector. It holds until one of them changes, and nobody can say afterwards what happened where.
06Across the platform

Pairs well with

Other parts of the platform you'll use alongside this.

Onboarding flow — pipeline view with lanes, phases, onboarding counts and MRR per cell
Onboarding Flow Engine
Client portal in the customer's own branding — go-live readiness across 30 locations with stage and progress per entity
Client Portal
Data migration — test imports with status, durations and a completed progress bar
Data Migration Engine

Frequently asked

No. Every customer runs on the standard platform, and what they need differently is configured on top of it. There is no separate version of the product for anyone.

That is the normal case. Our target API adapts to your system, so the fit is made on our side rather than by rebuilding anything on yours.

We do, together with you. Most adjustments are a matter of hours rather than a development cycle, and they are recorded so you can see what was changed and why.

Yes. Each partner gets their own branded environment, with their domain and their look, so their customers see one product.

Ready to see it on your data?

20-minute call. Show us your source, we show you the mapping. No deck required.