Work

The three shapes of problem we get called for.

No logo wall. Most of this work sits underneath a product nobody outside the company ever sees, and naming the client usually tells you nothing about the engineering anyway. So here is the honest version: the shape of the system, the part that is genuinely hard, and what lands in your repository at the end.

Payments that never quite agree

Money passes through a payment provider, your application, a ledger somewhere, and finally a spreadsheet in finance. Each system is individually correct and collectively wrong. The symptom is always the same: a number that is off by a small amount and nobody can say which system is the liar.

PSP webhook→ outbox→ ledger→ reconcile job→ drift alert

The part that is actually hard

Webhooks are retried, reordered, and occasionally delivered twice with different payloads. Refunds arrive weeks after the charge. Currency rounding means the sum of the parts is not the total. Any reconciliation built on "process each event once" is wrong the first time the provider retries.

So the event log becomes the source of truth, keyed by the provider's own id, and the ledger is a projection of it. Reconciliation stops being a nightly prayer and becomes a query that either returns zero rows or pages someone.

What you get

Idempotent webhook handler with a replay path
Event log + ledger projection schema
Daily reconciliation job with drift report
Alerting on unmatched or stuck events
Runbook for the 3am "numbers don't match" call

The spreadsheet that became the company

It started as a tracker. Three years later it has 4,000 rows, conditional formatting nobody understands, and one person who knows which columns are load-bearing. The team is not asking for a platform — they are asking for the spreadsheet to stop being a single point of failure.

intake form→ admin tool→ Postgres→ nightly export

The part that is actually hard

Not the CRUD. The hard part is the social contract encoded in the sheet: who is allowed to edit which column, what "done" means, and which of the eleven colours is a status. A tool that ignores those rules gets abandoned in a fortnight, and everyone goes back to the file.

So the first deliverable is a written transcription of the spreadsheet's rules — states, transitions, permissions, the exceptions people make on Fridays — and the UI is built to that, not to an idealised workflow.

What you get

Rules written down before any UI is built
Role-based admin tool with an audit trail
Import script that keeps the original IDs
Read-only export so finance keeps their numbers
A half-day walkthrough for the team who owns it

Integrating the system nobody wants to touch

The legacy system works. It has worked for eleven years, it will work for five more, and every new service has to talk to it over a protocol that predates the current team. The request is never "rewrite it" — it is "stop making every feature wait on it".

new service→ adapter→ legacy→ shadow read→ cut over

The part that is actually hard

Cutover, not code. The adapter is a weekend. Proving that the new path returns the same answers as the old one, for every edge case the legacy system quietly special-cases, is the work — and it has to happen while the business keeps running.

So we run both paths in parallel, compare outputs on live traffic, and only flip when the diff is empty for a full week. Rollback is a flag, not a deployment.

What you get

Adapter service with a stable contract
Shadow mode with automated output diffing
Backfill job, restartable and idempotent
Feature-flag cutover with instant rollback
Documented behaviour of the legacy edge cases

Something else?

Most first calls are none of the above.

Send two paragraphs: what the system does today and where it hurts. If it is not a fit, we say so in the first reply rather than after a discovery phase.

hello@zlovefu.com