A ledger where a database will not do
Smart contracts, tokenised assets and shared records between parties who do not trust each other's database. We say first whether you need one, and usually you do not.
The problem
Two or more organisations need to agree on the same record, and none of them will accept another's database as the truth. That is the problem a ledger solves. Most projects that reach for one do not have it, and end up paying blockchain costs for something a shared API would have done.
You are probably here if
If three or more of these are true, this pillar is where your constraint lives.
- 01Several companies reconcile the same records by email every month
- 02An audit needs proof a record was not changed after the fact
- 03Provenance has to survive a party leaving the arrangement
- 04A token or a contract already exists and nobody has audited it
- 05A pilot was built, works, and nobody can operate it
What we actually do
The database question
A short engagement that answers whether you need a ledger at all. It ends in a written no more often than a yes, and that is the point.
Smart contracts
Written, tested against the failure cases first, and audited by somebody who did not write them before anything is deployed.
Contract audit
An existing contract read against known failure classes, with each finding reproduced before it is reported.
Tokenisation
Representing a real asset on a chain, including the part everybody skips: what happens off chain when it changes hands.
Chain integration
Connecting your existing systems to a network already in use, without moving your business onto it.
Operations handover
Keys, upgrades, monitoring and the runbook for the day something goes wrong. A contract nobody can operate is a liability.
How it runs, and where you can stop
Each phase ends with something you own. Stopping after any of them leaves you better off than before it.
- 011-2w
Decide
Whether a ledger is the right answer, written down with the alternative priced next to it.
- 022-3w
Design
The chain, the contract boundaries, the key custody model and what deliberately stays off chain.
- 036-12w
Build
Contracts and the systems around them, tested against the failure cases and audited before deployment.
- 04handover
Operate
Keys, monitoring, the upgrade path and the runbook, handed to a named owner on your side.
What you receive
Artifacts, not a slide deck. Each one is usable by your team without us in the room.
- A written recommendation on whether a ledger is needed, with the alternative costed
- Audited contract source in your repository
- An independent audit report with every finding reproduced
- A key custody and recovery model
- Monitoring and an incident runbook
- An exit path off the chain, written before you go on it
What this is usually built on
The services that sit beside it
AI transformation
Most AI projects fail because they add a chat box next to the problem instead of removing the step that costs the hours. We start from the workflow, and from the systems and the data underneath it.
Web development
New builds, rescues and re-platforms, measured against what the site earns rather than against how it looks. The brand system that carries it is built in the same engagement.
SEO management
One monthly programme: technical fixes, content architecture and internal links, aimed at the queries that end in a sale rather than the ones that end in a visit.
Performance marketing
Google Ads, Meta, TikTok and LinkedIn run as one account structure, with conversion tracking you can defend and spend paced against cost per qualified lead rather than clicks.
Growth transformation
Organic accounts, reputation, lifecycle and conversion run as one programme, with fractional leadership above it for the companies that need the seniority before they can justify the salary.
Not a fit if
We would rather lose the engagement on this page than at week six.
- One organisation controls all the data and all the parties
- The reason for the project is that the board asked for a blockchain
- A token is wanted primarily to raise money
Asked on almost every first call
Do we actually need a blockchain?
Usually not. If one organisation controls the record, a database is cheaper, faster and easier to fix. The honest test is whether two parties who distrust each other must agree on the same history, and we answer that in writing before quoting the build.
Who audits the contracts?
Not the person who wrote them. Every contract goes to an independent audit before deployment, the report comes to you unedited, and nothing ships with an open critical finding.
What about the keys?
Custody is designed before any code is written, because it is the failure that cannot be patched afterwards. You end up owning the keys, with a recovery path that does not depend on us existing.
Which chains do you work on?
Ethereum and the EVM networks around it, chosen on cost and finality for your case rather than on preference. If your counterparties are already on a network, that decision is usually made for us.
Bring the constraint, not the brief
If three or more of these are true, this pillar is where your constraint lives.