Skip to content

SOLUTIONS

One core. Every client. No forks.

The model we run our own studio on. Infrastructure built once, a fix that propagates to every project, and client-specific work that never enters the shared codebase.

WHAT WE TRIED FIRSTWHAT WE BUILTproject 1project 2project 3project 4project 5the same fix, five times— and one had driftedconfigured, not copiedQuarkino Coreone codebase, twelve clients laterthe same fix, once— and it reaches all five

The situation

Five clients, five repositories, five slightly different versions of the same authentication code. A security fix means five pull requests and one merge conflict in the project that drifted furthest. A developer moving between clients spends a week getting oriented. You've priced infrastructure into five proposals and delivered it five times.

What you get

Each one links to the feature page that proves it.

Infrastructure once, not per client

Authentication, content, media, notifications, admin, security — built and tested once. Every new proposal starts from there.

A fix reaches everything

Nothing diverged, so nothing has to be merged. A core improvement propagates to every project you've built on it.

Extensibility

Client peculiarities stay out of the core

That odd discount rule, that unusual field type, that bespoke report — each is a registered definition, not an edit to shared code. Which is why the core is still clean at client number twelve.

Every brand independent

Colours, fonts, logo, text direction, language, and the entire feature set are per-installation configuration. Each generates its own encryption keys on first run, so nothing is shared between clients — not even by accident.

White-label

Team mobility

A developer moving from client A to client B already knows the architecture. Onboarding is about the client, not the codebase.

Better margins on the same work

The parts you used to bill and rebuild are already done. Which means either a faster delivery or more room for the design and product work you'd rather be doing.

The maths

The same portfolio of clients, run two ways.

One codebase per clientInfrastructure per projectOne core, N configurationsInfrastructure done once
One codebase per clientFixes applied N timesOne core, N configurationsFixes propagate
One codebase per clientUpgrades are projectsOne core, N configurationsUpgrades are routine
One codebase per clientKnowledge fragments across reposOne core, N configurationsOne architecture to know
One codebase per clientInfrastructure priced into every proposalOne core, N configurationsProposals compete on product, not plumbing

This isn't a model we're recommending from the outside. It's how our own studio delivers client work — Quarkino is the core our projects run on, and every rough edge gets found by us first, on our own deadline.

Running an agency on five codebases?

Tell us how many clients and how different they are. We'll be honest about whether one core fits.

  • We reply within one working day
  • No sales sequence, no drip campaign
  • NDA before the call if you'd prefer