Send us the task
Disciplines 01 Trajectories 02 Difference 03 Method 04 Cases 05 Stack 06 Team 07 Engagement 08 Questions 09 Send us the task

Atoms / Extraction · Automation · Analytics · Web systems

Since 2014 — worldwide

We take the work others return as impossible.

Atoms is an engineering team of twelve years. Four disciplines, one standard: the source nobody could parse, the process nobody would quote, the report that never reconciles, the platform a previous team could not finish. Twelve years on that class of problem, and nothing else.

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 — the first job turned into the next one, and then into a system we have been running ever since. You get an answer within 24 hours.

Atomscapability mapSince 2014
DISCIPLINE 01 Data extraction 1 000+ parsers · 5B records DISCIPLINE 02 Business automation 400+ processes · 12M ops/day DISCIPLINE 03 Dashboards & analytics 300+ systems · 400M rows/day DISCIPLINE 04 Web applications 200+ platforms · 40k sessions ONE ENGINEERING CORE 01Adapters for systems with no API 02State, retries, replay, rollback 03Exceptions designed, not deferred 04Proof: audit and reconciliation 05Cost per operation as a constraint 06Operated by us, year after year Same team, same standard, all four
Prove → Design → Build → Operate1 900+ systems shipped
1 900+

systems built and shipped since 2014

5B+

records collected and delivered

12M+

operations executed a day

12+

years working only on hard problems

VerticalsLogistics · Finance · Retail · Marketplaces · Manufacturing · Insurance · Travel · Telecom
ConstantThe work another vendor already returned
EntrySend us any task or problem — an answer within 24 hours
What we do01 / 09

Four disciplines. One engineering standard.

Each one is a full practice with its own scale, its own failure modes and its own page. What they share is the part that decides whether a system still runs in year three: exceptions, state, proof, and somebody still operating it.

01 — Data extractionSince 2014

The parsing everyone else calls impossible.

Extraction systems for the most heavily defended sources in the industry — Ticketmaster, Zillow, Amazon, Booking and their class — at millions of records a day, with coverage you can prove rather than hope for.

  • Behavioural bot management and defences that change weekly
  • Dynamic rendering, private APIs, session and state machinery
  • Completeness measured against the source, not asserted
  • Delivered as a feed your systems consume, monitored around the clock

Hardest classBehavioural bot management at national scale, held at full coverage for years.

Parsers
1 000+
Records
5B+
Per day
10M+
Years
12+
Complex data extraction
02 — Business automationSince 2014

The processes everyone else calls unautomatable.

Whole departments replaced end to end — intake, judgement, execution and control — running millions of operations a day across systems that were never designed to talk to each other, including the ones with no API.

  • Exception taxonomy from your real history, with a committed straight-through rate
  • State machines, idempotent steps, compensation and replay
  • Decisions nobody ever wrote down, encoded as versioned, explainable policy
  • Cost per operation fixed in the SLA before the build starts

Hardest classCross-department processes over undocumented legacy systems.

Processes
400+
Systems
120+
Ops / day
12M+
FTE freed
120+
Complex business automation
03 — Dashboards & analyticsSince 2014

The reporting everyone else calls unbuildable.

A BI licence gives you a chart over one clean table. We build what sits underneath: every internal and third-party system joined into one governed model, any kind of report on top, drilling down to a single transaction.

  • 90+ kinds of source system connected, including ones with no export
  • A governed semantic layer, so two departments stop reporting two truths
  • Multi-level drill-through from a board KPI to the underlying row
  • Reconciliation built in, so the numbers survive an audit

Hardest classGroup-level consolidated reporting over a dozen incompatible systems.

Systems
300+
Sources
90+
Rows / day
400M+
Years
12+
Dashboards & analytics
04 — Web applicationsSince 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 internal operating platforms, client portals, marketplaces and real-time interfaces with real domain logic behind them.

  • Hundreds of screens, permissions an auditor reads, millions of live rows
  • Legacy replacement while the old system keeps running 24/7
  • Deep integration with ERP, CRM and systems that have no API
  • Run and developed by us for years after launch, not delivered and forgotten

Hardest classReplacing a core internal system without stopping the business.

Systems
200+
Screens
600+
Sessions
40k+
Years
12+
Complex web applications
They chain

Extraction feeds the automation, the automation feeds the reporting, and the platform is where people work. Most engagements use more than one.

One team, four of them

The same people carry all four disciplines, so there is nobody to hand the blame to when the seam between two of them breaks.

None started this big

Almost no engagement here began as a project of this size. What it usually looks like at the start is directly below.

How it usually begins02 / 09

Almost none of this started big.

Nobody arrives with a department to automate. They arrive with one thing that annoys them — a report that takes a morning, a list somebody retypes, a number nobody trusts — and they are not sure it is worth asking about. That is where most of the systems above came from.

01 — Logistics2019 → today
First task · 3 days

One script that pulled tracking numbers out of a carrier's portal every morning, because a person was copying them by hand.

Today

The document desk for the whole group: 240k documents a day, 81 roles released, running unattended.

02 — Retail2021 → today
First task · 1 week

One report the finance team could not get out of their ERP: margin by store, weekly, without three days of manual work.

Today

The group's reporting platform: 14 source systems, 400M rows a day, month-end close down by 73%.

03 — Marketplace2020 → today
First task · 4 days

A parser for one competitor's price list, to test a hypothesis nobody was willing to fund properly yet.

Today

The pricing data layer the product runs on: 9.4M records a day at 99.4% measured coverage.

Smallest first task
2 days
Longest running client
9 years
Started with one small task
7 in 10
Any size

Send the task or the problem, however small. There is no minimum and no qualifying call before anyone looks at it.

An answer in 24 hours

A two-line question is answered the way a department-scale brief is answered: in writing, within 24 hours.

Including “you don’t need us”

When an off-the-shelf tool solves the problem, you get that answer instead of a quote. That reply has started more long relationships than it has cost us.

Why the hard ones come to us03 / 09

The demo is easy. Year three is the engineering.

Almost anyone can show you a working prototype. The reason projects like these fail is always the same five things — and all five surface months after everyone has gone home.

Dimension
Typical vendor
Atoms
The 20%
The happy path is delivered; everything unusual quietly returns to a person.
Exceptions are the design input. We build from your real history and commit to a measured rate.
Hostile systems
“There is no connector for that,” so the hard part stays manual or stays missing.
We build the adapter — internal API, database, protocol, or controlled UI automation where nothing else exists.
Failure
A half-finished run leaves duplicated or missing data that nobody notices for weeks.
Idempotent steps, compensation and replay. A failure is contained, alerted and resumable.
Scale
Fine in the pilot; runtime limits and per-task pricing make production impossible.
Throughput and cost per operation are design inputs, measured in the pilot and fixed in the SLA.
After go-live
The project closes, the team disperses, and the system quietly decays until something breaks badly enough to be noticed.
We run it. Hosting, monitoring, on-call, upstream changes and new features — month after month, by the people who built it.
The answer “no”
Every brief becomes a proposal, because a proposal is how the vendor gets paid.
We say no in the first reply when the work is not ours, and point you somewhere better suited.
01

We prove it before either side commits

On genuinely hard work, a quote written from a brief is a guess — the spread between the described version and the real one is routinely tenfold. So where the unknowns can move the number tenfold, the first step is a fixed-fee pilot on your systems and your data: one slice running end to end, with the measured numbers and the honest risks. By the end of it you know what the full build costs, what it will do and where the difficult parts sit — after a month, rather than after a year of a project that drifts.

02

Twelve years on the same class of problem

We have not pivoted. Since 2014 the work has been sources with real defences, processes with real exceptions, reporting over real mess and platforms with real domain logic. That is why the estimate for a hostile integration is a recollection rather than a guess, and why our straight-through rates hold in month nine instead of month one.

03

Running cost is a design constraint, not a surprise

At the scale we work at, the recurring line — compute, proxies, document processing, model calls, licences — decides whether the system is worth having at all. We design the execution model per case, use the expensive machinery only where it earns its place, and report cost per thousand operations from the first week.

04

We run what we build, for years

Shipping a system is the start of it, not the end. Hosting, monitoring, on-call, upstream changes, tuning and new features are all part of one monthly arrangement, handled by the same engineers who designed it. That is exactly why we build with tests, runbooks, infrastructure as code and versioned policies: a system we will still be running in year eight has to be engineered to be operated, not merely delivered. Most of our clients are on their third or fourth system with us.

05

Only inside what the client owns or is authorised to operate

Every engagement runs against systems and data the client owns or has the right to use, under credentials they authorise, with every action logged, attributable and reversible. Where a source or a process carries a legal question, we put it on the table in the first conversation rather than months in — that has cost us work, and it is worth it.

How we start04 / 09

Five steps. Most work never needs all five.

No discovery call before there is something to discover, no deck, no phased proposal for a problem nobody has tested yet. Bounded work goes straight from brief to done. Where the unknowns are large enough to move the price tenfold, the pilot is the sales process — and it works the same whether the work is a parser, a department, a reporting platform or a product.

1Brief

What it is and why it matters

The source, process, report or platform; the systems it touches; the volume it carries; what changes for the business if it works. Half the time the scope narrows and gets cheaper right here.

OutputWritten feasibility view in 3 days

2Pilot

Working proof, fixed fee

Two to four weeks on your real systems and real data. One slice running end to end, with measured coverage or throughput, measured running cost, and the risks stated plainly.

OutputRunning pilot + risk list

3Design

Scope, SLA and price

Target operating model, exception handling, throughput, availability and running cost — written into the contract rather than into a slide. After the pilot, the price is fixed.

OutputFixed scope & fixed price

4Build

Weekly working increments

Every week ships something that actually runs, shadowing whatever does the job today before it takes over. Monitoring, runbooks and documentation are built alongside it, not bolted on at the end.

OutputA system running in production

5Operate

Monitoring and response

Hosting, on-call, upstream changes, tuning and new features as the business moves. Routine change is covered by the monthly fee; anything large is quoted before it starts.

OutputA system you stop thinking about

Selected work05 / 09

Eight systems that had already failed somewhere else.

Two from each discipline. Every one of them arrived after another team stalled, quoted it as undoable, or delivered something that could not be maintained. Clients are under NDA — the engineering detail we walk through against your own case.

Extraction2025

Nationwide ticketing inventory, live

Full event, seat and price coverage from a source with behavioural bot management, refreshed continuously rather than nightly.

Records / day
9.4M
Coverage
99.4%
Extraction2024

Property data for a market nobody had mapped

Listings, history and agent data unified across 40+ portals with contradictory identities, deduplicated to one entity per property.

Sources
40+
Entities
180M
Automation2024

A 90-person document desk, run by nine

Shipping, customs and supplier paperwork in 40+ formats, parsed, checked against the ERP and posted, for a European freight group.

Docs / day
240k
FTE released
81
Automation2025

Order-to-cash across seven systems with no bridges

Intake, credit checks, allocation, invoicing and dunning unified across an ERP, two CRMs, a WMS and a 20-year-old accounting core.

Ops / day
3.1M
Cycle time
−87%
Analytics2025

Group reporting over a dozen incompatible systems

Consolidated commercial and financial reporting for a multi-country group whose subsidiaries had never agreed on a definition of margin.

Source systems
14
Close time
−73%
Analytics2024

Retail analytics down to the single receipt line

Board KPIs, store operations and category management on one model, drilling from a headline number to the transaction behind it.

Rows / day
400M
Report latency
< 60s
Web systems2025

Replacing a core platform while it kept running

A 600-screen internal operating system migrated module by module, with both systems live and reconciled through the whole transition.

Screens
600+
Cutover downtime
0
Web systems2024

A client portal on top of systems with no API

Real-time order, document and settlement visibility for thousands of business customers, sourced from a back office that had never been exposed.

Peak sessions
40k
Support load
−61%
The figures

Measured production numbers, agreed with each client before anything is published.

The names

Clients, their systems and anything that would identify them stay out of public material.

Under NDA

We walk through the architecture, the exception profile and the failure modes in full, against your own case.

Stack & infrastructure06 / 09

Boring technology, chosen for the tenth year.

We will be running these systems for years, so we pick technology that stays boring under load and still has a deep talent pool a decade from now. Nothing exotic without a reason we can write down, and nothing that only works while somebody is watching it.

Languages & runtimes

  • Python
  • TypeScript / Node
  • Go
  • C# / .NET
  • SQL, everywhere

Per problem, not per fashion

Data & storage

  • PostgreSQL · MS SQL
  • ClickHouse
  • Kafka · RabbitMQ
  • S3-compatible object storage
  • dbt-style modelling

Columnar where it earns it

Interfaces & front end

  • React · TypeScript
  • Design systems, not themes
  • WebSocket real-time
  • Server-side rendering
  • WCAG-aware components

Screens people work in daily

Infrastructure

  • Docker · Kubernetes
  • Terraform · IaC
  • AWS · GCP · Azure · on-prem
  • CI/CD and release pipelines
  • Prometheus · Grafana · Sentry

Our infrastructure or yours

ERPSAP · 1C · Dynamics
CRMSalesforce · HubSpot
OpsWMS · TMS · MES
ExchangeMail · EDI · SFTP
LegacyTerminal · desktop
DirectYour database
Where models earn it

Machine learning and language models are used where they measurably beat rules: extraction from messy documents, classification, entity resolution.

Where they do not

They are kept out of the path wherever a deterministic rule is cheaper, faster and explainable — which is most of it.

Either way

Every automated decision stays traceable to the policy version that made it, and to the input it saw.

The team07 / 09

The people you talk to are the people who build it.

The engineers who scope your system are the ones who build it and then keep it running. That continuity is the whole point: three years in, someone here still remembers why a particular decision was made, and that is worth more than any document. The team is senior by design — we grow only as fast as we can staff work we are willing to stand behind.

Who we are

Twelve years, one class of problem

We started in 2014 doing extraction nobody else would take, and grew into the three disciplines that kept turning up next to it — the automation the data fed, the reporting the business needed on top, and the systems people actually work in. Twelve years later it is the same team, the same standard and the same class of problem.

Founded
2014
Engineers
120+
Avg. seniority
10+ yrs

Distributed across Europe, working in English, overlapping with European and US East Coast hours. Long engagements are the norm: most clients are on their third or fourth system with us.

How we work

Six rules we do not bend

  • 01 — Straight answers firstIf the work is not ours, or a cheaper tool solves it, you hear that in the first reply. We lose deals this way on purpose.
  • 02 — Nothing is quoted blindIf being wrong about an estimate is cheap, we quote the work directly. If it is not, the price comes after a paid pilot has measured the unknowns on real systems.
  • 03 — We run what we buildA system we ship is a system we keep running: hosting, monitoring, on-call and upstream changes, month after month.
  • 04 — Written over verbalDecisions, risks and trade-offs are written down. Nothing important lives only in a call.
  • 05 — Measured, not assertedCoverage, straight-through rate, throughput and cost are numbers on a dashboard you also see.
  • 06 — Only authorised systemsWe work inside what the client owns or is authorised to operate, with every action logged and reversible.
Engagement08 / 09

How we contract, and who we are wrong for.

Work prices by how hostile the environment is, not by how many features are listed, and there is no floor it has to clear. The rule is the same at every size: if being wrong about the estimate is cheap, we quote the work directly; if it is not, the price comes after a paid pilot has measured the unknowns. Either way it is fixed before anything starts.

Model

Four rungs, no floor

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 on your real systems; one slice running end to end, with measured numbers and stated risksFixed fee
Build — scope, SLA, throughput and running cost fixed after the pilot, then delivered in weekly incrementsFixed price
Operate — hosting, monitoring, on-call, upstream changes, tuning and new featuresMonthly
Engagement length over the last twelve months, smallest to largest3 days – 4 years

You start on whichever rung fits, and most clients start on the first one. 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 the system. Infrastructure runs on ours or inside your own perimeter — whichever your security and finance people prefer.

Not our work

Say no early, honestly

  • Marketing sites, landing pages and catalogues. An agency will do it better and for a tenth of the price.
  • Anything that reads as circumventing another party's controls, or using systems and data the client is not authorised to use.
  • Staff augmentation by the seat. We take responsibility for a working system, which requires owning the design.
  • Systems nobody inside the company is willing to own. Without a decision-maker a large build becomes shelfware by month three — a small task, on the other hand, needs nobody's approval.

Notice that none of these is about size. Small is not on the list and never has been. If your problem is real but not our kind of work, we say so in the first reply and point you at someone better suited — including a $20-a-month tool when that is genuinely the right answer. It costs us nothing, it saves you a quarter, and it is how a surprising number of our longest clients met us.

Legal & governance

Engineering your risk
team can sign off.

Systems run on infrastructure we operate for you, or inside your own perimeter, against data and systems the client owns or is authorised to use, under credentials the client controls. Every action is logged, attributable and reversible, and every automated decision is explainable. Access, retention and deletion controls are designed into the system rather than bolted on afterwards.

GDPR alignment and internal-control requirements are implemented through technical and organisational controls. Confirming the lawful basis, the regulatory treatment and the approval authority for a specific source, process or jurisdiction remains with the client's legal and risk teams — we give them the documentation to do it, and we raise the questions at the start rather than months into the build.

01 — ScopeSystems and data the client owns or is authorised to use
02 — ControlEvery action logged, reversible and attributable
03 — PrivacyData minimisation and purpose limitation by design
04 — ContractNDA and DPA signed before technical detail is shared
Questions09 / 09

What gets asked before the first engagement.

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.

Another team already told us this is impossible. Is it?
Usually it means expensive rather than impossible, and that the previous team priced the happy path as if it were the whole job. That distinction is exactly what the pilot settles: two to four weeks on your real systems and real data, a fixed fee, and measured numbers — coverage or straight-through rate, throughput, and running cost. Twelve years in, the question is almost never whether it can be built; it is what it costs to build and what it costs to keep running. You get both numbers in a month rather than after a year.
Our problem is small. Are we too small for you?
No — and this is the single most common reason people do not write. There is no minimum and no qualifying call. A large share of the systems on this page began as one task of a few days for someone who assumed we would not be interested: a script, a report, one integration. We answer a two-line question the same way we answer a department-scale brief, in writing, within a business day. If a cheap off-the-shelf tool solves it, you get that answer instead of a quote — and you are welcome to come back when something harder turns up. That is usually exactly what happens.
Which of the four disciplines do we actually need?
Often more than one, and it is our job to tell you which — you do not need to work that out before writing. A “reporting problem” is frequently a data problem two systems upstream; an “automation problem” is frequently a missing interface. Describe the outcome you want rather than the component you think you need, and the first written reply will lay out what it actually takes, including the parts you can skip and the parts you can postpone for a year.
Do we have to start with a pilot?
No. The pilot exists for work large enough that a wrong estimate would hurt — a department, a platform, a hostile source at scale. If your problem is one task, we quote that task at a fixed price and do it, and there is no obligation to ever talk about a system. Where a pilot does make sense, it is a fixed fee agreed before it starts, and you get running software rather than a slide deck: a working slice on your real systems, the measured numbers that decide the business case, a written risk list and a fixed price for the full build. Stop after it and you have a working slice and the numbers behind it; carry on and it becomes the first increment of the build.
Our systems are twenty years old and have no APIs.
That is the normal case, not the exception — it is most of what we do. In order of preference we use an internal or undocumented interface, direct database work under agreed constraints, file and protocol-level exchange, and controlled UI automation only where genuinely nothing else exists, with the fragile paths isolated behind an adapter so an upgrade is a contained repair rather than a rebuild. We also tell you plainly when an integration will be brittle and what it costs to keep running.
Where does the system run, and who keeps it running?
Most of our clients run on our infrastructure and we operate the system for them: hosting, monitoring, on-call and upstream changes sit inside one monthly arrangement, so nobody on your side has to build an operations function around it. Where security, data residency or procurement rules require it, we deploy inside your own perimeter and operate it there instead. Either way you get the same monitoring, the same response times and the same dashboard we watch, and the commercial terms are agreed before anything is built.
What happens after go-live?
That is where the relationship actually begins. Clients stay on a monthly arrangement: hosting, monitoring and on-call, handling upstream changes — a redesigned source, a changed form, an ERP upgrade, a new supplier format — plus tuning and new features as the business moves. Routine change sits inside the monthly fee rather than becoming a change request; larger work is quoted first. Most of our clients are years in and on their third or fourth system with us, and that is the outcome we build for.
How do you handle confidentiality and legal risk?
NDA and, where personal data is involved, a DPA before technical detail is shared. We work only against systems and data the client owns or is authorised to use, and we raise questions about lawful basis, terms and internal authority at the start rather than once the build is running. Where an approach carries risk we cannot mitigate, we say so and propose the alternative — and if there isn't one, we decline the work.
How fast can we start?
A substantive written reply within 24 hours and a written feasibility view within three days of the brief. A small first task often starts the same week; a paid pilot usually starts within two. Emergency work — a broken production system, a source that changed overnight, a migration that stalled — is scheduled faster when we have capacity. Say so in the form and we will tell you honestly whether we do.

Start here

Two lines are
enough to start.

Send the problem in whatever detail you already have — a paragraph is fine, a full brief is fine. You get a straight answer: whether it can be done, what makes it hard if anything does, and roughly what it costs. Whatever the size — no deck, and no discovery call before there is anything to discover.

  • A substantive written reply within 24 hours, whatever the size
  • Any size — a task of a few days is a perfectly normal way to start
  • 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.