Software engineering for systems you have to be able to trust.

We are AI-native: we build with AI, and we build the deterministic checks that catch it when it is wrong.

The engineering that comes after the prototype.

Scroll to explore
Where we do not trust AI

Vision models read the document. Ordinary code checks their arithmetic.

On a screening tool we built, long PDFs are read by vision models. Every figure they extract is then re-checked by nine deterministic cross-checks written in ordinary code, with no model involved: a misclassified revenue line, a profit row mapped to the wrong label, a margin outside its plausible band. Three of those checks exist because we hit that exact error once. A figure the tool cannot find stays visibly missing, with the reason attached, rather than becoming a zero that someone forwards to a committee.

A model is never the last thing to touch a number that reaches a screen.

Custom software, and the unglamorous parts that decide whether you can rely on it.

Five practices. Most of our work starts with something that already exists and now has more people, more data and more consequences attached to it than it was written for.

(01) Platform and migration

Move a system off what it has outgrown without a big-bang rewrite. Old and new run side by side, you cut over one tenant at a time, and one call moves a tenant back.

(02) Access and permissions

Who can see which team, which data crosses a boundary, and what happens the day someone leaves. Written down, enforced in code, and held there by tests that fail loudly.

(03) Data and reconciliation

When two systems disagree about money, we make them agree, or show you exactly where they do not, itemised. What we cannot match, we never quietly fold into a total.

(04) Reliability and review

Code review, CI, deploy pipelines, and the gates nobody puts in a proposal, which are the ones that catch a regression before your customer does.

(05) Integration and automation

Connect the systems the business already runs on so the numbers agree, and take the hand-offs that currently depend on someone remembering out of a person's head.

Selected work

What we have actually built.

Three systems, described by what they had to get right. Client names are withheld by default; we will talk specifics on a call.

Regulated compliance software

A platform moving off a .NET monolith without stopping

An eight-year-old backend of about 1,800 source files and 95 controllers, moving onto a modern API and front end with the Strangler Fig pattern. No rewrite, no downtime, no feature freeze. Old and new run side by side in the same cluster under a written contract for who is allowed to change what. Cutover is per customer: an administrator moves one tenant onto the new stack, and one call moves them back. Around twenty feature areas crossed over in six weeks.

378 API endpoints 24 route modules behind the seam ~2,670 automated tests GitOps delivery on Kubernetes
Multi-site service operations

An operations platform where the hard part was the accounting

A single-page front end over serverless functions, bridged to the ERP the business already ran on. The screens were the easy half. Every amount is handled in integer cents from end to end. Publishing a record is idempotent, so a retry cannot create a duplicate or charge twice. Invoices from the accounting system are reconciled against operational records, and anything that will not match goes to an itemised review queue instead of being rounded into a total that looks fine.

46 serverless functions 73 database migrations 364 automated tests
Investment screening

A screening tool that refuses to invent a number

Long PDFs in; a filled screen and a spreadsheet out that lines up row for row with the workbook the team already uses. Nine deterministic checks, with no model involved, run over every extracted figure. Three of them exist because we hit that exact error once. A figure we could not find stays visibly missing, with the reason, rather than becoming a zero that someone forwards to a committee.

nine deterministic cross-checks no model in the checking path

What we will not tell you

We will not quote you an uptime figure we have not measured, or a percentage improvement we cannot show you the arithmetic for. Every number on this page traces to a repository. Ask us to show you.

How we work

Five steps, then the part nobody sees.

The first five are how an engagement runs. What comes after them is how every change gets checked, which is the half that decides whether you can depend on the result.

01
Clarify Goals

Outcomes before tools. What has to be true when this is done.

02
Identify Bottlenecks

Where the work actually stalls, which is rarely where it looks slow.

03
Prioritize

What earns its place first, and what can wait without hurting.

04
Review Proposal

Scope, sequence and cost, written down before anyone builds anything.

05
Execute

A first working version in four to six weeks, then the engineering that makes it dependable. How long that second half runs depends on the system.

Every change goes through the same gate.

We run a supervised fleet of coding agents on firstmate, an open-source orchestrator we use and contribute to. It is not our software and we do not claim it. What is ours is the gate we put around it.

01
An isolated working copy

Every task gets its own git worktree, so two pieces of work can never quietly overwrite each other.

02
A review, test and lint gate

Nothing becomes a pull request until it has passed all three. A change that cannot explain itself does not proceed.

03
Escalation, not guessing

A decision that is genuinely yours is escalated to you with the options laid out, rather than answered by a model on your behalf.

04
Deterministic checks around the output

Where a model produces a number, ordinary code checks it. Where a model is confident and wrong, the check is what notices.

Who we've worked with

You talk to the people writing the code.

A small senior team. No account managers, no hand-offs, no second team offshore you never meet. The person who scopes your system is the person who builds it.

Win Raguini
Founder & Lead Engineer
Fernando Pineda
Fernando Pineda
Senior Engineer & Software Architect
Nikolas Escobal
Nikolas Escobal
Integration & Automation Engineer

Have something that works, but not something you would trust yet?

Bring the prototype, the spreadsheet the business quietly runs on, or the platform you cannot turn off. Thirty minutes, technical, no deck.