Approach – OR Tech

APPROACH

How we

work.

Payment systems fail expensively and publicly. Our process is shaped around that.

PRINCIPLES

Correctness before cleverness

Idempotency, exactly-once semantics and reconcilable state are not optional extras.

The ledger is the truth

Not the provider dashboard, not the database row someone edited.

Every failure has a defined path

Timeouts, partial captures, network drops and provider outages are designed for, not discovered.

Migrate by dual-running

Nothing involving money gets a big-bang cutover.

Observability at build time

If you can’t see it, you can’t operate it.

Privacy by design

Personal data is minimised, kept in the EU where required, and deleted on schedule — built in, not retrofitted.

Plain language

You’ll get a straight answer about risk, timeline and cost, including when the answer is inconvenient.

PROCESS

PHASE

DURATION

OUTPUT

Discovery

1–2 weeks

Current-state assessment, requirements, risk register

Architecture

2–3 weeks

Target architecture, integration plan, data protection impact notes, delivery estimate

Build

Fortnightly sprints

Working software in a live environment each sprint

Hardening

2–4 weeks

Load, failure and security testing; pen-test remediation

Launch

Phased

Dual-run, staged traffic shift, monitored cutover

Run

Ongoing or handover

SLA-backed support, or documented transfer to your team

ENGAGEMENT MODELS

Project

Fixed scope, defined outcome, milestone-based.

Dedicated team

A standing squad working exclusively on your product.

Embedded engineers

Senior individuals inside your existing teams.

Advisory

Architecture review, due diligence, second opinion.

Have a payment problem worth solving?

Tell us what you’re building. We’ll tell you honestly whether
we’re the right team for it.