Web 3.0 and blockchain engineering
Most companies asking us for a blockchain do not need one, and we would rather establish that in week one than bill you for finding out in month four. A shared ledger, one record several organizations keep together and none of them owns, earns its cost in a narrow set of cases. This page is about telling those cases apart.
01Capabilities
Four shapes of work, and only three involve a chain
In every project here the chain is one component inside an otherwise ordinary application, and the ordinary part is where the engineering hours go.
Platforms with a deliberately small on-chain surface
Private business-to-business marketplaces and settlement flows where only the agreement between counterparties is signed on the chain. Negotiation, documents, messaging and the customer database stay in conventional services. Commodity trading platforms are the clearest example: the platform around the ledger is the build.
Contract-level engineering
A smart contract is a small program the chain runs, and it decides when value moves. We write those as narrow rules with explicit states, then test them the way an attacker behaves: automated attempts to break each rule, a rehearsal against a copy of the live chain, and an independent review before anything is deployed. That is the guarantee that carries weight in fintech settlement.
The layer between the chain and the rest of your stack
Watching the chain for events, keeping its record and your own database in agreement, handling transaction fees and the order things are submitted in, retries, and monitoring that tells you a payment is stuck rather than merely slow. An inherited chain project is usually strong on the contract side and fragile right here.
Structured data, which is the other Web 3.0
JSON-LD and schema.org markup, which describe a page in a form machines read, plus stable identifiers and clean data agreements between systems. That is the semantic half of the term, with no ledger in it anywhere. It is how search engines and AI answer engines read your site without guessing, and nobody calls it Web 3.0 while doing it.
02Stack
Which of these three pages you actually want
Three pages, three different jobs, and mixing them up is how blockchain conversations go in circles. Every row below has exactly one destination, so the whole row is the link.
| Page | What it settles |
|---|---|
| Ethereum development | Trust modelOwns the platform decision: who the parties are, what goes on the chain, a public network against a private one, and how keys and stuck transactions get handled. Start here.Ethereum developmentOr book a meeting |
| Solidity smart contract development | SpecialistOwns the contract layer: which rule belongs in a contract at all, how it is specified, tested, reviewed and upgraded, and who may pause it. Read it after the platform question is settled, not before.Solidity engineeringOr book a meeting |
| Web 3.0 | Not a productOwns the vocabulary problem. The term covers a blockchain web, a machine-readable web and a marketing container, which share a name and very little else. Read this one first if the request arrived as a Web 3.0 project.Web 3.0, explainedOr book a meeting |
03Fit
The one thing a ledger buys, and who actually needs it
A ledger buys exactly one thing: several parties agreeing on one record without a party they all have to trust. If such a party exists and everyone accepts them, you are paying a large premium for nothing. Every row below follows from that single test, and most of them route away from a chain rather than towards one.
| Your situation | What we recommend |
|---|---|
| Several organizations that will not accept each other's database, and no neutral operator is acceptable to all of them | Build itThis is the case the technology was designed for. It starts with the platform and trust decision on our Ethereum page, not with code. |
| One company owns the process and the data | A databasePostgreSQL with an append-only audit table, meaning rows are added and never changed, plus signed exports. That gives you the tamper-evidence you were actually asking for, at a fraction of the cost to run. |
| The record has to include personal data you may later be required to delete | Keep it off-chainHold the data in your own system and put only a fingerprint of it on the chain. Permanence and a deletion request cannot both be satisfied, so this is a security and compliance conversation before it is an architecture one. |
| The rule moves with pricing, fees, limits or regulation, or you are still finding the product | In your backendCode you cannot casually change is an asset for a settlement rule and a liability for anything the business tunes quarterly. The Solidity page works through where that line sits. |
| High volume of small transactions, and the cost per transaction matters | Not the main chainRead Ethereum's own explainer on layer 2 networks before you take our word for it: it is the fairest account of what they cost and what they ask you to assume. If you do not need those guarantees, you do not need a chain here at all. |
| The requirement arrived as a blockchain strategy or a Web 3.0 project | Take the word apartWeb 3.0 covers three unrelated ideas, and separating them in a technology advisory conversation regularly ends with a smaller, cheaper system. |
Scope
What we own is that decision and everything downstream of it: which records go on the chain and which do not, and who holds the keys, meaning who is able to lose one. Then the two things that decide whether it survives production: what happens in the minutes after a payment confirms and your own database does not know yet, and whether your team can operate the result after handover. For anything holding real value we recommend an independent review and plan around it, because checking our own code is not the same thing. We are not a chain vendor and have nothing to sell you on any particular network. Where the honest answer is a conventional system with no chain in it, the work is custom software development, and we would rather build that than build the wrong thing well. We work to ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK.
04Case studies
The one chain system we have published
A trading platform where the smart contract holds the agreement between two parties who do not trust each other. It publishes no outcome figure, so this card carries none.
See all case studies
Whether you need a blockchain is not a technical question. Name the organizations that have to agree on the same record, and say why none of them will hold it for the others. If you can name them, a shared ledger may genuinely be cheaper than the reconciliation you do today. If you cannot, you want a database, and you will find that out either in week one with us or in month four without us.
Oleksandr TrofimovChief Technology Officer, unicrewThey provided great advices on the best technology solutions to adopt (including blockchain) and were ready to go the extra mile in supporting the client at 360 degrees.
05Questions
The questions that decide whether this is a chain project
Usually not, and the test is short. Name the party everyone would otherwise have to trust, then ask whether they exist, whether every side accepts them, and what it would cost to make them auditable instead. If a neutral operator plus signed records nobody can edit afterwards satisfies everybody, you get a smaller system at a fraction of the running cost. Reaching that conclusion during technology advisory is a normal outcome here, not a failed sale.
You can bring our engineers onto your team. What we will not do is staff a blockchain project that does not need a blockchain, which is the most common way this work goes wrong. An architect outside the delivery team reviews what goes on the chain and what stays off it, and the code goes through the same QA practice as our own projects. Extending your team is managed teams; handing over the outcome is custom software development.
Usually yes, and the first pass is a read rather than a rewrite. Send the repository and the addresses of anything live, because an hour spent reading verified source beats three spent hearing it described. Inherited projects are typically sound on the contract side and fragile in the ordinary software around it: reconciliation, retries, and knowing when a payment is stuck. An outside read on code that already exists is a quality audit.
A scoping call with an engineer rather than a salesperson. Bring the list of organizations involved and the one record they disagree about. What comes back is written: what we would keep off the chain, what we would put on it, and the version of the system with no chain in it at all. Work starts two to four weeks after we agree scope.
Services we deliver in Web 3.0 & Blockchain
All servicesWant a straight answer on whether you need a chain?
Describe the parties, what they have to agree on, and who currently sits in the middle. You will get a recommendation with the reasoning attached, including the version with no ledger in it.