Skip to content

Services

Most things that get built on a blockchain did not need one

Some genuinely do. If several organisations that do not fully trust each other have to agree on the same record, a shared ledger solves a problem an ordinary database cannot. That is a narrower set of situations than the market suggests, and we would rather establish which one you are in before you spend anything.

Book a discovery call

Discovery, fixed fee · Contracts · Infrastructure

The decision

When a ledger is the right answer

One question settles most cases, and it is worth settling before anyone writes code.

A ledger solves it

Several organisations that do not fully trust each other must agree on the same record.

None of them would accept another party's server as the source of truth, and a contract between them changes nothing. A shared ledger swaps trust in each other for verification everyone can run themselves.

Many writers, no mutual trust

A database serves you better

One system writes, everyone inside trusts the operator, and the hard questions are about history.

Internal trust, or trust backed by contracts, means a well built relational database with an audit log answers the same questions for less money and none of the ceremony.

One writer, audit logs suffice

Most enquiries land in the right hand column. Establishing which column you are in costs a discovery, not a deployment.

The work itself

What actually gets built

Contracts get the attention. Most of the hours go into the conventional software around them.

  1. Contracts and their tests

    The on-chain logic, written to survive being read by strangers, together with the test suite that justifies putting it in front of them.

  2. The conventional application around it

    Accounts, dashboards, admin screens. Most of what users touch never goes near a chain, and it is built like any other careful web application.

  3. Indexing and reading

    Chains answer questions slowly. Events are indexed into a database the product can query quickly, so screens stay fast.

  4. Integration with off-chain systems

    Payments, records, internal tools. The ledger joins the estate you already run rather than pretending to replace it.

Security

Security works differently here

Deployed contracts may not be changeable.

Many designs cannot be patched the way a server can. Recovering from a mistake can mean migrating everything to a fresh contract.

The code is public, including to attackers.

Once deployed, assume every line will be read by people hunting mistakes for profit. It changes how carefully the code must be written.

Mistakes can be irreversible.

An outage loses hours and gets rolled back. Value moved by a broken contract rarely comes back, however fast the response.

Audits

If the work involves deployed contracts, third party review is part of the conversation before the quote is final.

How the work runs

Three steps. The first one is the product.

Everything else on this site follows from these three steps.

  1. 01

    Discovery that ends in a written plan

    A short piece of paid work. We sit with the problem and you get back a document that says what is being made, how it fits together, what order it gets built in, and what it costs. The plan is yours unconditionally. Take it to us, take it to another firm, or decide not to build at all.

  2. 02

    A named team, and one person you can reach

    The people who understood the problem build the thing. You get names rather than a rotating cast, and one lead who answers to you directly. If someone is not working out, we raise it first and manage the replacement ourselves.

  3. 03

    Progress you can check, changes you can price

    Work arrives in increments you can see and use, not in a reveal at the end. When scope moves, and it will, the change is costed in writing before anybody starts it.

On this service

Discovery carries one extra responsibility here: establishing whether you need a ledger at all. When the honest answer is no, the plan says so and recommends an ordinary database instead. That counts as success, and the fee is the same either way.

Ownership

What you own

From the first commit, everything belongs to you. Not at handover. From the beginning.

  • Code and repositories

    All of it, in accounts you control. There is no private framework underneath and no dependency on continued payment to keep the thing running.

  • Infrastructure and keys

    Cloud accounts, domains, credentials and certificates are created in your name. We hold nothing that you cannot revoke yourself.

  • Documentation

    Decisions, diagrams and runbooks are written while the work happens, so the knowledge leaves with the documents rather than with the people.

  • The freedom to leave

    If you stopped paying us tomorrow, the product would keep running without us. That is the test we design against.

Questions

Answered before you ask

Which chain should we build on?

More often than not the counterparties decide it before we do: a partner's platform, an industry network, an existing deployment. Where nothing forces the choice, discovery weighs the options properly instead of defaulting to whatever is fashionable this quarter.

Will you audit contracts someone else wrote?

Sometimes, and only after reading them properly. What we will not do is skim someone else's contract and stamp it safe. If we take a review on, it gets the same scrutiny as our own work, and the findings are written down whether or not they flatter the original authors.

Do we need cryptocurrency to operate it?

Public chains charge fees in their own tokens, so possibly a small operating balance, treated like a hosting cost. Plenty of ledger problems, though, belong on shared infrastructure with no token anywhere near them. Which kind you have comes out of discovery.

What happens after deployment?

Whatever suits the size of the system. Monitoring with a named engineer under a maintenance agreement, or a handover complete enough for your own team to run it alone. Either way the choice is designed for from the start rather than improvised at the end.

Next step

Tell us what you think needs a ledger.

If it turns out a database would serve you better, you will hear that on the call rather than after an invoice.

The ledger question

A few lines about the situation is plenty. We read every one.

No newsletter, no drip sequence. A reply from a person who read this.