What we build, and how we think about building it.
Three capability areas that overlap on most real projects. Each lists what we deliver and the engineering principles we hold to inside it.
What are you trying to build?
We start with the decisions that are expensive to reverse — the data model, the API contract, the trust boundaries — then ship vertical slices that work end to end rather than a prototype that demos.
Retrieval that returns the right context, tools with scoped permissions, side effects that are idempotent, and evaluation that fails the build when groundedness regresses. Most AI failures are not model failures.
Reorg-safe indexing, multi-provider access, oracle failure handling and the operational tooling a protocol actually needs. We design for the reorg and the double submission before writing the contract.
We find what is actually breaking instead of what is being reported, fix root causes rather than symptoms, and leave the instrumentation behind so you can tell it stayed fixed.
Intelligent applications, agents, automation and enterprise AI.
Most AI projects fail on retrieval, permissions and side effects rather than on model quality. We build the parts that decide whether a system reaches production.
Knowledge & retrieval systems
Hybrid retrieval with reranking, structural parsing and entitlement-aware filtering so answers are grounded and permission-safe.
Agent systems
Durable agent runtimes with typed tools, scoped capabilities, idempotent side effects and human approval gates.
AI-native product features
Natural-language interfaces over governed data, structured extraction and AI steps embedded in real workflows.
Evaluation & reliability
Labelled eval suites, groundedness scoring and regression gates so a config change cannot quietly degrade quality.
Cost & latency engineering
Model routing, caching, token budgets and per-step cost attribution to keep unit economics viable.
AI operations
Tracing, replay, drift monitoring and the observability needed to debug a non-deterministic system.
Principles we hold to
- 01
Grounding over generation
An answer that cannot cite its source is not an answer. We gate on groundedness and refuse rather than guess.
- 02
Least authority
Tools are scoped per agent and per run. An AI system should not hold more permission than the task needs.
- 03
Idempotent effects
Anything that writes carries an idempotency key, because retries are normal and double-charging is not.
- 04
Measured, not asserted
Quality claims come from an evaluation set, not from a demo that happened to work.
Protocols, smart contracts, DeFi, payments, RWA and decentralized infrastructure.
Contracts are one layer of the problem. Most of the engineering value is in the indexing, risk, reconciliation and operational tooling around them.
Smart contract engineering
Solidity and EVM contracts with property tests, static analysis, role-gated admin paths and audit-ready documentation.
DeFi & financial primitives
Lending, liquidity, collateral and yield systems with risk engines and pre-trade simulation.
RWA & tokenization
Permissioned tokens, eligibility registries, ownership ledgers and distribution pipelines that reconcile to the legal record.
Payments infrastructure
Stablecoin acceptance, payment intents, settlement policy and double-entry ledgers across multiple networks.
Indexing & data
Reorg-safe indexers with deterministic rollback, plus entity resolution and analytics over on-chain activity.
Multichain infrastructure
RPC routing with failover, normalised finality semantics and at-least-once event delivery.
Principles we hold to
- 01
Reorg-safe by construction
Indexed state derives from a confirmed cursor with deterministic rollback. A reorg is a handled event, not a data incident.
- 02
Ledger over chain reads
Balances come from a double-entry ledger with enforced invariants. Chain state is an input, never the displayed answer.
- 03
Oracles are a solvency concern
Feeds are checked for deviation and staleness before entering a risk model, and failure blocks new leverage.
- 04
Policy as configuration
Haircuts, limits and eligibility rules are declarative and versioned, so a change is a reviewable diff.
Full-stack applications, APIs, platforms, cloud infrastructure and distributed systems.
The systems that carry a product: typed contracts, data models that survive scale, and infrastructure you can deploy on a Friday afternoon.
Web applications
Next.js and React products built for performance, accessibility and the real states a UI has to handle.
APIs & services
Contract-first APIs with explicit error semantics, idempotency, versioning and typed clients.
Data platforms
Schema design, event sourcing where it earns its complexity, warehouses and semantic layers.
Workflow & automation
Durable execution engines with checkpointing, compensation and human-in-the-loop steps.
Cloud & delivery
Containerised deployment, progressive rollouts, health gates and automatic rollback.
Observability & hardening
Tracing, structured logs, SLOs with error budgets and security review as part of the build.
Related systems
Principles we hold to
- 01
Contract-first
The interface is designed before the implementation, because every consumer will depend on whatever ships.
- 02
Failure modes first
Retries, timeouts, partial failure and back-pressure get designed in, not discovered in production.
- 03
Incremental delivery
Thin vertical slices that work end to end, verified as they land rather than integrated at the end.
- 04
Operable by design
If you cannot tell from the outside whether it is working, it is not finished.
How we build.
Five stages. Each produces something concrete — a decision, a design, working software — rather than a status update.
- 01
Understand
We work out what the system actually has to do, and what happens when it does not.
- Problem definition
- Constraints & risk
- Success criteria
- 02
Architect
Decisions that are expensive to reverse get made deliberately and written down.
- System design
- Data model
- Failure modes
- 03
Build
Vertical slices that work end to end, verified as they land rather than at the end.
- Incremental delivery
- Tests that matter
- Working software
- 04
Launch
Staged rollout with the instrumentation to tell whether it is going well.
- Progressive release
- Observability
- Rollback path
- 05
Scale
Performance, cost and reliability work driven by what production actually shows.
- Load & cost
- Hardening
- Iteration
What it costs, and what you are agreeing to.
The commercial answers in one place, so none of them has to wait for a call.
Typical route in
Discovery & Architecture
From $4,500
1–3 weeks
We take the problem apart before anyone estimates it. You leave with an architecture you could hand to any competent team, and an honest list of what is likely to go wrong.
A starting point for the scope described, not an estimate for your project. Ongoing engineering runs at $75 per hour blended.
Who owns what you build?
You do. On full payment of the fees for an engagement, the intellectual property in everything built specifically for you is assigned to you.
Our pre-existing tools, libraries and internal infrastructure stay ours — but where a deliverable uses them, you get a perpetual, worldwide licence to run, modify and extend it. Nothing we hand over needs us to keep operating it. Open-source and third-party components keep their own licences, and we tell you which ones and what they require.
We also will not name you as a client, describe your project, or publish a case study about it without your written agreement.
What happens if it does not work out?
Either of us can end an engagement with 30 days written notice, or immediately if the other commits a material breach and does not remedy it within 15 days. You pay for work properly performed up to that point, and we hand over completed work along with every deliverable you have paid for.
Two limits worth stating before you ask. We are engineers, not advisers: nothing we deliver is legal, regulatory, tax or financial advice, and a system built to your specification is not an opinion that it is lawful in your jurisdiction. And where our work includes reviewing or auditing code, the findings cover the scope and time agreed — an absence of findings is not a guarantee that nothing is there.
What do you need from me to start?
Not a specification. Discovery exists precisely because most people do not have one — an idea, or a technical problem you cannot yet size, is enough to begin.
What the work does assume: timely access to the people, systems, credentials and environments it touches; decisions and approvals at roughly the pace the timeline assumes, since delays on your side move both dates and cost; and that you have the right to give us whatever you give us, including data, code and third-party material.
Why you rather than the alternative?
Against hiring a senior engineer in-house: sourcing one takes months and commits you permanently. Discovery runs 1–3 weeks, and you keep the architecture whichever way you then go — including if the answer is to make that hire.
Against the cheapest contractor available: you will pay less per hour. Our argument is that the architecture decision is the one that is expensive to reverse, which is why we sell it first, separately, and at a price you can say yes to before committing to a build.
Against a larger firm: there is no account layer. The people who scope the work are the people who build it.
And when not to hire us: if a no-code or off-the-shelf tool still fits what you are doing, stay on it. We are worth paying once you have hit a ceiling you cannot engineer around from where you are.
These are summaries. The binding version of the ownership, exit and liability terms is in our Terms of Service. A person reads every enquiry. We usually reply within a few hours.
Start a technical assessment
Have a use case in mind?
Tell us what the system has to do. We’ll help define the architecture, technology and the path to production.