Services

Every service, in full detail

The short version is on the home page. This is the long one: how we work inside each service, the practices we hold to, and what you have in your hands when it ends.

System and API integration

Connect applications, partners and services with contracts that hold up under load.

Most integration failures are not technical surprises. They are undocumented assumptions: a field that is sometimes null, a partner that retries silently, a timezone nobody agreed on.

We start by writing the contract down. Every field, every error path, every retry rule. Then we build against it, and we keep a record of every message that crosses the boundary so that when something looks wrong you can prove what actually happened.

OpenAPI or AsyncAPI contract for every interface
Idempotency keys and safe retries by default
Dead letter queues with a replay path
Message level audit trail with correlation IDs

What you get

A documented interface, a running pipeline and a dashboard that shows it working.

Custom software development

Complete systems built around your operation, not around a template.

Order management, custom CRM, help desks, portals, internal back offices. The kind of system that has too many rules to buy off the shelf and too much value to run on spreadsheets.

We keep the architecture boring on purpose. Clear boundaries, patterns the market already trusts, and a codebase another developer can pick up without a guided tour.

Domain modelling before a line of code
Automated tests around the rules that matter
Role based access and full change history
Admin console so your team can operate it

What you get

A system in production, documented, with your team trained to run it.

Data engineering and migration

Move data between systems without losing it, duplicating it or corrupting it.

A migration is not a copy. It is a translation between two models that were never designed to agree, and it has to survive being run twice.

We build migrations that are repeatable and reversible, with reconciliation counts on both sides so the cutover is a decision rather than a leap of faith.

Repeatable, idempotent migration jobs
Row level reconciliation before cutover
Dual write and shadow read phases when needed
Rollback plan written before the first run

What you get

A verified cutover with reconciliation reports on both systems.

Event streaming

Real time flows that stay ordered, stay observable and absorb spikes.

When systems talk directly to each other, one slow consumer takes the whole chain down. Events break that coupling, but only if the delivery guarantees are chosen deliberately.

We pick the guarantee each flow actually needs, at least once, exactly once or best effort, and we make that choice visible in the code and in the monitoring.

Transactional outbox to avoid lost events
Partitioning designed around your ordering rules
Consumer lag alerting from day one
Replay tooling for reprocessing history

What you get

A stream topology with documented guarantees and lag dashboards.

Observability and reliability

Grafana dashboards, structured logs and alerts that fire before your client calls.

Software that moves other people money has to be watchable. We instrument every integration with metrics, structured logs and traces, and we put them behind a dashboard you can read without being an engineer.

Alerts are tied to symptoms your business recognises, like orders not reaching the warehouse, rather than to CPU graphs nobody acts on.

Grafana dashboards per integration
Structured logs with correlation IDs end to end
Alerting on business symptoms, not just infrastructure
Runbooks written for the person on call

What you get

Dashboards, alert rules and runbooks handed over with the system.

Managed operation and support

We keep running what we built, or take over what somebody else left behind.

Integrations rot quietly. A partner changes a field, a certificate expires, a volume doubles. Somebody has to be watching.

We operate the platforms we build, and we regularly adopt systems built by others. First we make them observable, then we make them stable, then we improve them.