Send us the task
Systems 01 Complexity 02 Limits 03 Stack 04 Scale 05 Architecture 06 Craft 07 Reliability 08 Cases 09 Engagement 10 Questions 11 Send us the task

Atoms / Services / Complex web applications

Discipline 04 — since 2014

Not websites. The systems a business runs on.

We do not build brochure sites, landing pages or catalogues — agencies do that well and cheaply. We build the complex web systems companies operate on: hundreds of screens, real domain logic, millions of live rows, permissions that an auditor reads, and integrations with the systems you already have.

Twelve years, 200+ web systems in production, the largest at 600+ screens and 40k concurrent sessions. Have a task or a problem you need solved? Send it over, whatever its size — a great many of our clients arrived with something small and stayed for years. You get an answer within 24 hours.

Platformsystem stack / liveServing
LAYER 01 · INTERFACE Hundreds of screens, real workflows LAYER 02 · DOMAIN States · money · documents · deadlines LAYER 03 · DATA Millions of rows, live, with history LAYER 04 · ACCESS Roles · permissions · audit trail LAYER 05 · OPERATIONS Peaks · uptime · weekly releases ATOMS BUILD Product & UX Domain modelling Data & integrations Access control Run & release
Model → Build → Integrate → Operate40k+ sessions / peak
200+

web systems shipped and running

600+

screens in the largest single platform

40k+

concurrent sessions at peak

12+

years on systems, not on sites

VerticalsLogistics · Fintech · Healthcare · Marketplaces · Manufacturing · Insurance
Hardest classReplacing a core internal system while it keeps running 24/7
EntrySend us any task or problem — an answer within 24 hours
What we build01 / 12

Systems people work in all day.

Not something the marketing department updates twice a year — the platform an operations team has open on the second monitor from nine to six, and that the company cannot trade without.

Internal platformsOperations

The system that replaces forty spreadsheets, three access databases and a legacy client nobody can install any more — orders, resources, planning, documents, in one place.

Core · daily use

Client portalsB2B

Self-service for your customers and partners: contracts, orders, balances, documents and support, wired straight into the systems that hold the real data.

External · integrated

MarketplacesMulti-sided

Two or more sides, matching and search at catalogue scale, payments and payouts, disputes, ratings and the operational back office that actually runs it.

Scale · money flow

Real-time interfacesLive ops

Dispatch boards, monitoring walls, trading and booking screens where the state changes under the user and two people must never take the same job.

Sub-second · concurrent

Workflow & approvalsProcess

Multi-step processes with roles, four-eyes approval, SLA clocks, versioned documents and a complete history of who did what and when.

Stateful · auditable

Data-heavy interfacesDepth

Tables of millions of rows that stay responsive, bulk editing, configurators, planners, schedule grids and editors — the screens that make a generic admin panel collapse.

Volume · interaction

Legacy replacementMigration

Taking a fifteen-year-old system out of service without stopping the business: dual-run, reconciled migration, staged cut-over and a rollback path at every step.

Zero-downtime cut-over

Your systemUntested

The build that stalled, the platform two teams have already quoted, or the idea everyone says is too complex. Two weeks, fixed fee, one real workflow running on your data.

Bring it to us

What we deliberately do not do: brochure sites, landing pages, template catalogues and visual redesigns with no system behind them. A good agency will do those faster and for a tenth of our price, and we will tell you so in the first reply rather than take the work.

The distinction02 / 12

Where a site ends and a system begins.

Both are “a website” to a procurement form, and they have almost nothing in common. Everything on the right is why complex platforms are quoted by developer-months and still fail — and it is the only kind of work we take.

Dimension
A website
A system we build
Purpose
Presents information and collects enquiries.
Runs an operation the company cannot trade without for a day.
Users
Anonymous visitors, one kind of page for everyone.
Named users in a dozen roles, each seeing a different subset, accountable for what they change.
Data
A few hundred CMS entries, edited by one person.
Millions of live rows with history, versions, attachments and an audit trail.
Logic
A contact form that sends an email.
States, transactions, pricing, money movement, documents, deadlines and the exceptions to all of it.
Integrations
A payment button and an analytics tag.
ERP, CRM, banks, carriers, warehouses and internal systems — several of which have no API at all.
Failure
A page is down for an hour and nobody notices.
Operations stop, money is at risk, and somebody has to explain it to a regulator.
Lifetime
Redesigned from scratch every three years.
Changed every week for a decade by people who did not write the first version.

If your project sits on the right-hand column, the price is set by the domain and the data you already have — not by the number of pages. That is why we start with a paid pilot on one real workflow instead of an estimate written from a specification document.

Where web projects die03 / 12

Six walls, six answers.

Complex builds rarely fail on the framework choice. They fail on the same six things, usually somewhere between month four and the first real user. Here is all six, and what we do about each.

01 — DomainThe real rules

The brief is not the business

The specification describes the process as management believes it works. The actual rules — the exceptions, the informal approvals, the three cases that carry the margin — live with the people doing the job and surface at acceptance.

What we doWe model the domain with the people who operate it: states, transitions and edge cases agreed in week one, before a single screen is designed.

02 — Legacy dataMigration

A database nobody dares to move

Fifteen years of records with duplicates, three encodings, fields reused for a different meaning in 2019, and a business that cannot pause for a weekend cut-over.

What we doMigration as engineering: profiling, mapping, dual-run against the old system, reconciled totals, staged cut-over and a rollback path at every step.

03 — AccessPermissions

Roles bolted on at the end

“Managers see their own region, except the group head, except during audit.” Retro-fitting that into a system built for one kind of user is a rewrite of every query and every screen.

What we doThe permission model is designed first and tested like business logic: roles, row-level rules, delegation, impersonation and a complete audit trail.

04 — ConcurrencyReal time

Two people, one order, same second

Dispatchers taking the same job, a stock level that goes negative, an approval applied to a document that changed underneath. Under real load these stop being rare.

What we doTransactional boundaries, locking and conflict resolution designed explicitly, with live updates pushed to open screens rather than discovered on refresh.

05 — PerformanceAt volume

Fine in the demo, unusable in year two

A screen built against 5 000 test rows meets two million real ones, a report locks the database at month-end, and the interface everyone lives in becomes the thing everyone complains about.

What we doVolume is a design input: query and index design, server-side pagination and virtualised grids, caching, background jobs and measured p95 budgets per screen.

06 — MaintainabilityYear three

A platform only its author can change

No tests, no types, no documentation, environments configured by hand, and one developer who knows why any of it works. Every change becomes a negotiation and eventually a rewrite.

What we doTyped code, automated tests, infrastructure as code, migrations and runbooks — built so the platform can still be extended in year eight, not just shipped in year one.

Engineering surface04 / 12

Everything a real platform needs, built in-house.

One team covers product design, frontend, backend, data, integrations and infrastructure — so nobody is waiting on a subcontractor to explain why the numbers on two screens disagree. Stack is chosen per project; these are the parts we own.

ProductUX for dense workflows
FrontendReact · TypeScript
Design systemComponents · tokens
BackendNode · Python · Go
Real timeWebSocket · events
DataPostgres · ClickHouse
SearchElastic · vector
QueuesKafka · Redis · jobs
IdentitySSO · RBAC · audit
PaymentsPSPs · banks · payouts
InfraKubernetes · Terraform
BridgesERP · CRM · legacy

The integration side is the same engineering our automation practice does every day: where a system has no API we go through its database, its files, its protocol or a purpose-built adapter. “There is no integration for that” is not an answer we give.

Scale05 / 12

Built for the load of year three, not of the demo.

A platform is easy to make fast when it holds test data and one user. The engineering is in holding response time on real history, at peak concurrency, while a release ships every week and nothing goes down.

Operating envelope

What a single platform sustains

Volume, concurrency, latency budget and release cadence are agreed on day one and written into the SLA — not discovered in month four when a grid takes eleven seconds to open and the operations team quietly goes back to the spreadsheet.

Largest platform
600+ screens
Peak concurrency
40k+
Response budget
<200 ms p95
Release cadence
Weekly+

Where the load goes

Typical daily profile

API requests served120M
Real-time messages pushed38M
Background & integration jobs4.2M
Automated checks before releaseevery build
Failed requests0.04%

Illustrative profile of one production platform. Your envelope is fixed in the design phase and written into the SLA.

Architecture06 / 12

Built to be changed every week for ten years.

Every platform we ship runs on the same contour. Blocks change per product; the property that does not change is that a release is boring — tested, reversible, migrated without downtime, and observable from the first minute it is live.

Platform contourrev. 07
Reference architecture of an Atoms web platform A delivery layer covers environments, CI, migrations and feature flags. Requests move from clients through the interface layer into an API and domain layer, onto a data layer, and out through an integration layer to ERP, CRM, payment and legacy systems. A cross-cutting security and observability layer measures every stage and feeds authentication, audit and error budgets back into the interface and domain layers. LAYER 00 Delivery environments · CI & tests · zero-downtime migrations · feature flags · rollback · infrastructure as code CLIENTS Who uses it Staff & operationsCustomers PartnersMachines · API LAYER 01 Interface Design systemDense data grids Live updatesOffline & resilience p95 budget per screen LAYER 02 API & domain Domain model & statesTransactions Permissions & auditBackground jobs rules in one place LAYER 03 Data Relational coreHistory & versions Search & cacheQueues & events LAYER 04 Integration ERP · CRMPayments · banks Carriers · WMSLegacy adapters CROSS-CUTTING Security & observability SSO · row-level access · full audit trail · tracing · error budgets · on-call · dependency patching USAGE & ERRORS ACCESS & AUDIT
Why we are number one at this07 / 12

Anyone can ship screens. We ship a system that lasts.

The difference between a web studio and a systems engineering team shows up at the second release train — when the domain turns out to be deeper than the brief, and the data you already own turns out to be the hard part.

01

We model the domain before we draw screens

The first two weeks are spent with the people who do the work: what the states are, what may follow what, who is allowed to override, what happens on the third of the month, and which exceptions carry the money. Interfaces designed after that stay stable; interfaces designed before it get redrawn twice and blow the estimate.

02

The data you already have is the project

Most complex builds are replacements, and the schedule is decided by fifteen years of existing records rather than by the new features. We profile and map that data early, run the new system in parallel with the old, reconcile the totals daily and cut over in stages — so the business never has a week of two truths.

03

Complex does not mean slow to use

Systems people spend eight hours a day in are judged on the twentieth click, not the first screenshot. Keyboard-first flows, dense grids that stay responsive on millions of rows, bulk actions, undo, and states that survive a lost connection — this is where a generic admin framework stops and product engineering starts.

04

We run what we build, for years

Typed code, automated tests, infrastructure as code, migrations, runbooks and architecture notes. Shipping is the start of it, not the end: hosting, monitoring, on-call, upstream changes, tuning and new features all sit inside one monthly arrangement, handled by the same engineers who designed the thing. A system we will still be running in year eight has to be engineered to be operated, not merely delivered — and most of our clients are on their third or fourth system with us.

Reliability08 / 12

What we commit to once people work in it every day.

A platform an operations team lives in is a production system with an uptime, not a project that was delivered once. These are the commitments in the support agreement; tiers and windows are set per project against how critical the system is.

CommitmentTargetWhat it means in practice

Availability

99.9 %

Measured on real user requests, not on a ping to the home page, and reported monthly. You get the same dashboard we watch.

Response time

< 200 ms p95

A latency budget per key screen, held against production data volumes. A slow grid is treated as a defect with an owner, not as the price of having a lot of data.

Releases

Weekly+

Automated tests, staged rollout, zero-downtime migrations and a rollback path. Shipping on a Thursday afternoon is routine rather than an event.

Monitoring

24 / 7

Errors, latency regressions, failed jobs, queue growth and integration outages are detected by us and raised to you — not reported by a user on a Monday morning.

Engineering response

From 4 h

Incident tiers with named windows. A changed partner API, a new role, a schema migration or a security patch is routine work covered by the retainer, not a change request.

Security

Continuous

Dependency patching, access reviews, full audit trail and a codebase that stands up to a client's penetration test — several of ours have.

Selected work09 / 12

Three platforms that had already stalled.

Each of these came to us after an agency delivered screens without a domain, an internal team ran out of runway, or a vendor returned the migration as impossible. Clients are under NDA — the engineering detail we walk through against your own case.

01 — Logistics2024

A core platform that replaced 40 spreadsheets and two legacy systems

Orders, capacity planning, subcontractors, documents and settlement for a freight group of 3 000 staff, live in nine countries.

What was hardFifteen years of data in a system with no export, per-country process differences, and a business that could not be paused for a cut-over weekend.

Screens
420
Daily users
3 100
Systems joined
9
Cut-over downtime
0
02 — Fintech2025

A client portal that moves money, with four-eyes approval

Self-service for corporate clients: balances, payments, limits, documents and approvals, wired into a core banking system and three payment providers.

What was hardIdempotent money movement, a permission matrix the regulator reads, full audit of every action, and a core system that answers in seconds rather than milliseconds.

Peak sessions
18k
p95 latency
140 ms
Releases / month
12
Audit findings
0
03 — Marketplace2025

Real-time dispatch for a 24/7 two-sided marketplace

Live matching, dispatch board, pricing, payouts and dispute handling, with an operations back office running the whole thing from one screen.

What was hardThousands of dispatchers and couriers acting on the same objects at once, sub-second state propagation, and a previous build that double-assigned jobs under load.

Jobs / day
220k
Live messages / day
38M
Uptime, 12 mo
99.98%
Double assignments
0
How we start10 / 12

We build one real workflow before either side signs a platform.

On a complex system, an estimate written from a specification is a guess — the gap between the documented process and the actual one is routinely tenfold. So we build one slice on your real data and your real systems first, for a fixed fee.

1Brief

The domain and the decision

What the system must run, who works in it, which systems it must talk to, what the existing data looks like and what happens to the business if it works. Scope often narrows here.

OutputDomain map & risk profile

2Pilot

One workflow, end to end, fixed fee

Two to four weeks: a real workflow running against your real data and at least one real integration — plus the honest list of what the legacy data and the domain are going to cost.

OutputWorking slice + risk list

3Design

Architecture, roles and SLA

Domain model, permission model, integration contracts, migration plan, performance budgets, release cadence and price — written into the contract, not into a slide.

OutputFixed scope & fixed price

4Build

Weekly working increments

Every week ships something usable in your environment, with real users on it early. Monitoring, runbooks and documentation are built alongside it, not bolted on at the end.

OutputA system running in production

5Operate

Run, extend, grow

On-call, monitoring, integration changes, new modules and onboarding of your own developers — routine work sits in the retainer, large additions are quoted first.

OutputA platform you could run without us

Engagement11 / 12

How we contract, and who we are wrong for.

Complex platforms price by domain depth, the state of your existing data and the number of systems that must agree — not by page count. So we price in two steps, and we say no early when the work is not ours.

Model

Two steps, both fixed

First task — one small piece of work, days rather than weeks, quoted before it starts and often all anyone needsFixed price
Pilot — two to four weeks; one real workflow running on your data with a real integration, and the risks documentedFixed fee
Build — architecture, migration plan, scope, performance budgets and price fixed after the pilotFixed price
Operate — hosting, on-call, monitoring, integration changes, new modules, onboarding your developersMonthly

You start on whichever rung fits, and most clients start with one small first task. From the Operate rung onward it is a single monthly arrangement covering hosting, monitoring, on-call and continued development, so nobody on your side has to build an operations team around it. Infrastructure runs on ours or inside your own perimeter — whichever your security and finance people prefer.

Not our work

Say no early, honestly

  • Brochure sites, landing pages and template catalogues. A good agency ships those in two weeks for a tenth of our price, and we would be the expensive way to get there.
  • A visual redesign with no system behind it. If the problem is how it looks rather than what it does, you need a design studio, not us.
  • Renting developers by the hour to execute someone else's specification. We take responsibility for a working system, which requires owning the design.
  • Platforms nobody inside the company is willing to own. Without a decision-maker, a complex build becomes an unfinished migration in month six.

If your project is real but not our kind of work, we will say so in the first reply and point you at someone better suited — including an off-the-shelf product when that is genuinely the right answer. That costs us nothing and saves you a quarter.

Legal & governance

Systems your risk
team can sign off.

Platforms run inside the client's own perimeter, authenticate against the client's identity provider, and enforce role- and row-level access with a complete audit trail of who saw and changed what. Personal data is minimised by design, and retention and deletion are features rather than promises.

GDPR alignment and internal-control requirements are implemented through technical and organisational controls, and our code is written to survive a client-commissioned penetration test. Confirming the lawful basis, the retention rules and the regulatory treatment for a specific system and jurisdiction remains with the client’s legal and risk teams — we give them the documentation to do it.

01 — IdentitySSO, role- and row-level access control
02 — AuditEvery change attributable and reversible
03 — PrivacyData minimisation, retention and deletion by design
04 — ContractNDA and DPA signed before technical detail is shared
Questions12 / 12

What gets asked about complex builds.

If yours isn’t here, put it in the form — we answer in writing, within 24 hours, and without a discovery call first. Most questions get a straight yes or no rather than a proposal.

We need a website. Is that something you do?
If you mean a marketing site, a landing page or a catalogue on a template — no, and we will say so in the first reply. A good agency will do it faster and for a fraction of our price. We are for the case where the “website” is actually a system: named users with roles, real domain rules, live data at volume, money or documents moving, and integrations with the systems you already run. Those two things share a browser and nothing else.
Our build stalled with another team. Will you take it over?
Often, yes — a good share of our work starts as somebody else's unfinished platform. We audit the codebase, the data model and the delivery setup for a fixed fee, then come back with one of three answers: continue it, keep the domain model and rebuild the weak layer, or restart with what has been learned. We will tell you which even when the honest answer is that the existing work is better than you feared and you need less from us than you thought.
Our core data sits in a fifteen-year-old system. Can it be replaced?
That is the normal case, and the migration — not the new features — usually sets the schedule. We profile the existing data early, map it explicitly, run the new system in parallel with the old, reconcile totals daily and cut over in stages with a rollback path at each one. Where the old system must stay alive for a while, we bridge to it through its database, its files or a purpose-built adapter rather than waiting for an API that does not exist.
How do you handle go-live without stopping the business?
By never having a single big-bang date. Real users are on the system from the first increments, one region, branch or process at a time, with the old system still running and both sets of numbers reconciled. Migrations are backwards-compatible and reversible, releases are staged behind flags, and the cut-over that eventually happens is the least eventful day of the project.
Will it stay fast with millions of rows and hundreds of users?
Yes, and that is designed rather than hoped for. Query and index design, server-side pagination and virtualised grids, caching, background jobs and per-screen latency budgets measured against production-sized data. The envelope — volume, concurrency and p95 response — is measured during the pilot and written into the SLA before the build starts.
Do you do the design, or do we bring our own?
We do product design for dense, work-all-day interfaces, and it is part of the engagement rather than a separate purchase — screens are designed after the domain is modelled, which is why they stop changing. If you have a design team or an existing design system, we work inside it and take responsibility for the parts that carry real behaviour: grids, states, bulk actions, errors and permissions.
Where does the platform run, and can our own developers work on it?
Most clients run on our infrastructure and we operate the platform for them — hosting, monitoring, on-call, releases and integration changes sit inside one monthly arrangement. Where security or procurement rules require it, we deploy inside your own perimeter instead. If you have developers of your own, we onboard them during the build and they work in the same repository alongside us; plenty of our platforms are built that way.
How fast can we start?
A written feasibility assessment within three days of the brief, and the paid pilot itself usually starts within two weeks. Emergency work on a broken production platform is scheduled faster when we have capacity — say so in the form and we will tell you honestly.

Bring us the hard system

Tell us what the
platform has to run.

Send the process it has to carry, the systems it must talk to and the data that already exists. You get a straight answer: whether it can be built, what specifically makes it hard in your case, and roughly what it costs to build and to run. No deck, no discovery call before there is anything to discover.

  • A substantive written reply within 24 hours, whatever the size
  • Feasibility assessment within three days of the brief
  • NDA signed before we go into technical detail
  • If it isn’t our kind of work, we say so immediately

By sending you agree to our privacy policy. Briefs are never shared and you will not be added to a mailing list.