Work

Case studies

Platform work built for regulated environments, where security review, auditability and compliance are part of the delivery rather than an afterthought.

Braid

Banking & payments

Java
Spring Boot
JPA/Hibernate
MySQL
JMS

Banking & payments API platform

Braid gives financial institutions a single place to move money. We build and maintain the API layer behind it — the services that accept a payment instruction, decide whether it is allowed to proceed, and hand it to the correct rail.

The transfer is the straightforward part. The work sits in everything around it: keeping each institution's data strictly separated on shared infrastructure, screening counterparties before funds leave, and leaving an audit trail that holds up when someone asks how a particular payment was handled six months later.

Four rails behind one interface: Wire, FedNow, NACHA and outbound partner rails are exposed through a single consistent API. Callers do not rewrite their integration each time a rail is added or its settlement behaviour changes.
Asynchronous by default: Instructions are handed to JMS queues and processed independently of the request that created them. A slow downstream rail delays settlement — it does not block the caller or lose the instruction.
Screening before money moves: Sanctions screening runs automatically on every transaction rather than as an overnight batch, so a flagged counterparty stops the payment at the point of submission instead of after it has settled.
Multi-tenant from the start: One platform serves many institutions, with isolation enforced by the system itself rather than left to each integration to get right.

Wire, FedNow and NACHA payments in production under bank-grade compliance

Degree37

Healthcare

Blood donor management platform

Blood centres run on relationships and timing. A donor who has a good experience comes back; one who arrives at a drive that was moved, or gets reminded about an appointment they already kept, usually does not. Degree37 is the platform centres use to manage that — donor records, eligibility history, scheduling, and the mobile drives that collect most of the supply.

Our work sits on the operational side. Keeping donor and appointment data consistent when the same drive is being edited by staff in the field and at head office, and making sure the numbers a centre reports afterwards can be traced back to what actually happened at the chair.

One donor record: Recruitment history, eligibility and contact preferences sit together, so a recruiter calling a lapsed donor can see why they were deferred last time instead of asking them to explain it again.
Scheduling that expects change: Drives get moved, capacity changes and slots double-book. Rescheduling is treated as routine rather than an edge case, and the resulting donor reminders follow automatically.
Built for the field: Most collection happens away from the centre, often on a poor connection in a school hall or a car park. The tooling assumes that, rather than assuming a desk.
Numbers that can be explained: Units collected, deferrals and no-shows resolve back to the individual records behind them, so a figure in a board report can be accounted for rather than simply published.

Donor recruitment, scheduling and collections on one platform

BBSC Inc

Blood banking

Blood establishment computer system

A blood establishment computer system records what happens to a donation from the moment a donor is screened to the moment a unit is released to a hospital. Get a record wrong and the wrong unit reaches a patient, which is why this category of software is regulated by the FDA as a medical device rather than treated as ordinary line-of-business software.

That does not change what gets built so much as how. Requirements are written down before the code is, changes trace back to the requirement that caused them, and a passing test suite is evidence rather than permission to ship. We work inside that process alongside the centres using the system, where a release has to be defensible to an auditor as well as correct.

Traceable in both directions: Screening, collection, laboratory results, labelling and hospital orders hang off one record, so a unit can be followed forward to where it went and back to the donor it came from.
Validation is part of delivery: Design decisions and test evidence are recorded as the work happens rather than reconstructed afterwards, because clearance depends on being able to show how a change was made and why.
Offline is normal, not an exception: Collection happens in community halls, car parks and mobile units. Staff keep working when the connection goes, and what they recorded reconciles when it comes back.
Migrating without a gap: A centre cannot stop collecting while its systems are replaced. Moving off decades-old software means running old and new together and cutting across without leaving a hole in the record.

FDA 510(k) cleared, HIPAA and SOC 2 Type 2

Want a walkthrough?

We can talk through any of these projects in detail, including what went wrong and how it was handled.

Get in touch Our services