Argumant · Custom business systems · Django / PostgreSQL

Four systems in your business disagree about the same number.
The spreadsheet that reconciles them is the one nobody is allowed to touch.

Taken together

You don’t need another subscription. You need a system of record.

30 minutes, with the person who would build it.

Argumant builds the software a business runs its day on: point of sale and retail operations, ledgers and reconciliation, multi-tenant platforms, market data, real-time bidding pipelines. Django and PostgreSQL, on servers we hold the runbook for. Small, owner-led, and still answering the phone in year three.

02 · What we take as given

Four things we will not argue about.

The database is the product.

Everything else is an interface onto it. If the schema is wrong, the screens are decoration.

A deployment should be boring.

nginx, gunicorn, Postgres, and a runbook a new engineer can follow on a Sunday without calling anyone.

Whoever writes the migration answers the phone when it runs.

There is no handover to a support tier that has never seen your data.

Nothing is finished at launch.

Year two, when the business changes shape, is where the money is saved or lost.

In short

We are engineers you keep, not a project you survive.

03 · Where we get called in

Six ways this starts.

Common symptoms and the systems we build for them, with time in service.
What you say	What we build	In service
“Three store systems, and one of them is a notebook.”	Point of sale and retail operations. Offline-tolerant tills, cash-up, till-to-ledger posting.	11 stores · 4 yr
“Month-end close takes nine days and one person.”	Ledgers, reconciliation and financial reporting. Double entry, bank and clearing matching, reversal by contra entry only.	3 yr
“Every new client became a copy of the codebase.”	Multi-tenant platforms and tenant merges. Row-level tenancy, per-tenant migration windows.	40 tenants · 2 yr
“Prices move faster than the reports do.”	Trading and market-data systems. Late ticks, corporate actions, replayable state.	1.2M ticks/hr · 18 mo
“Ten million bid events an hour, and nobody can query yesterday.”	Real-time bidding and ad-tech pipelines. Back-pressure that drops rather than lies, hourly rollups.	8k req/s · 2 yr
“The schema was right in 2016.”	PostgreSQL migrations, partitioning and integrations. Zero-downtime changes on live tables.	ongoing

Figures are from delivered systems. We will name the client on a call, not on a web page.

If you recognised one of those, the next two sections are for whoever you would forward this to.

04 · Failure modes

Nobody can quote capacity without naming the failure mode.

These are ours, and what we do about them.

Known failure modes in this class of software, and what we build to prevent each one.
How it breaks	What we build so it doesn’t
A card is charged twice because the network drops between the terminal and the till.	Idempotency keys on every money-moving request. The retry is the same transaction, not a second one.
A migration takes ACCESS EXCLUSIVE at 09:07 and the shop floor stops.	Migrations rehearsed against a restored production dump, timed, run in lock-free steps, with a statement timeout and a rollback we have actually executed.
Two tenants are merged and four thousand rows are quietly duplicated.	The merge runs against a copy first. Row counts and checksums are diffed and signed off before the real run touches anything.
The ledger is off by three cents and nobody can say when it started.	Balances are derived, never stored, and a nightly reconciliation fails loudly on the first cent.
The report the owner actually uses is a spreadsheet somebody maintains by hand.	We find that spreadsheet in week one and treat it as the specification.

The pattern

Every one of these is a data problem wearing an interface problem’s clothes.

Describe what breaks in yours

One reply, from the person who would fix it.

05 · Proofs

Three we can walk you through.

Proof 01 · Retail group

Given A retail group with 34 stores and three point-of-sale systems inherited from three acquisitions.

One product, price and stock model across all three estates.
A reconciling importer, so old and new ran in parallel for six weeks.
Cut over store by store. No store closed for a day.
Each old system stayed readable until its numbers agreed for a full period.

Cutover

One stock number. Month-end close went from nine days to two.

PostgreSQL · Django · 6-week parallel run

Still on it — 26 months, retainer

Proof 02 · Commodities desk

Given Intraday positions kept in a spreadsheet that was accurate as of yesterday’s close.

Tick ingest with idempotent replay, so a re-sent feed cannot double-count.
Partitioned time-series tables, one partition a day, dropped on a schedule.
Positions reconciled against the broker statement every hour, not overnight.
The spreadsheet kept running beside it until it stopped disagreeing.

Replay

Positions 40 seconds behind the market instead of a day behind it.

PostgreSQL · Python · 1.2M ticks/hr

Still on it — 18 months, retainer

Proof 03 · Multi-tenant platform

Given Two companies merged. Two PostgreSQL databases, with colliding primary keys in every table.

A tenant map written and agreed before a single row moved.
The merge rehearsed four times against restored copies, timed on each run.
Row counts and checksums diffed and signed off by their finance lead.
Cutover inside a 90-minute window, with the rollback written first.

Merge

One schema, 40 tenants, no rows lost.

PostgreSQL 16 · Django · 90-minute window

Still on it — 14 months, retainer

These are compressed. Each one leaves out a month of arguing about edge cases, at least one bad week, and the parts the contract will not let us print. Ask about those on the call.

06 · Method

Five steps, in the order they have to happen.

0001_read_the_operation.py Two weeks watching the work as it is actually done, including the workarounds nobody wrote down. You get a written scope, a fixed price and the named risks whether or not you continue.
0002_model_the_data.py You get the schema and the entity list before you get a screen. If this is wrong, everything after it is wrong — and this is the cheapest place to be wrong.
0003_ship_a_thin_slice.py One real workflow, real users, in production by week five. Not a demo environment and not a video.
0004_migrate_the_truth.py Parallel run, reconcile to the cent, cut over in slices. The old system stays alive until it is provably redundant.
0005_stay.py Retainer, monitored deploys, and a phone number. We take three projects a year so that this step is real rather than a line in a contract.

In order

You replace the system without stopping the business.

07 · What we use

And what each choice costs you.

Python 3.12 / Django 5 The ORM until it stops paying, raw SQL after. Cost: you get a codebase that assumes somebody will read SQL one day.
PostgreSQL 16 Partitioning, logical replication, zero-downtime migrations under write load, pg_stat_statements before opinions. Cost: you will pay attention to indexes. Benefit: it does the work three other services usually get hired for, inside one transaction.
React / server-rendered Django React where the interface is genuinely stateful, Django where it is not. Cost: two idioms in one repository. Benefit: most of your pages stay simple enough that anyone can change them.
nginx / gunicorn / systemd On machines you can ssh into. Cost: you own patching. Benefit: your bill is a number you can predict.
Celery / Redis Celery for the queue, Redis for the cache, and nothing else until it justifies itself in writing.

We will not

Put you on Kubernetes because it is on our CV.
Rewrite a working system to make it fashionable.
Bolt a language model onto a reconciliation problem.
Take the ticket queue instead of the system.

08 · Objections

The four things you are already thinking.

“We already have developers.”

Good — they should own it. We do the migration and the parts nobody has time for, and we hand it over documented, in your repository, with the people who wrote it available to answer questions.

“Off-the-shelf is cheaper.”

Until you are paying three people to move data between four subscriptions. We will tell you when off-the-shelf is genuinely the right answer, and we have.

“What if you disappear?”

From month one you hold the repository, the servers, the runbook and the schema documentation. Nothing runs anywhere you cannot reach, and nothing is licensed back to you.

“We cannot stop operating for a migration.”

Neither could the 34 stores in Proof 01. Parallel running exists precisely so that nobody has to close.

09 · Conclusion

You run something real, and the software under it does not fit.
The fix is a data model, a migration, and someone who stays.
That is the whole job we do.

Q.E.D.

The next step is a thirty-minute conversation.