Ethereum development
Two conversations bring people to this page: a settlement or ownership problem where several parties have to agree on one record, and a board that has asked for a blockchain. They need very different answers, and the first thing we do is work out which one you have.
01Capabilities
Four shapes of work where a shared ledger holds up
Ethereum earns its place when a record has to be shared between parties who will not simply accept each other's database. These are the shapes of work where that holds, and in every one of them the chain is a small component inside an otherwise ordinary application.
- Settlement
Marketplaces where the deal itself is signed
Private business platforms where the agreement between buyer and seller is signed on the chain, while negotiation, documents, messaging and the customer records live in ordinary services. The part on the chain is deliberately small. The platform around it is the build, and it is the kind of system behind our commodity trading work.
- Registries
Ownership and provenance you can audit
Issuing and transferring claims, certificates or asset records, where a trail of custody nobody can quietly rewrite is the product. Documents and personal data stay off the chain with only a fingerprint recorded, because a public ledger is the wrong place for anything you may later be obliged to delete.
- Integration
The layer between the chain and your stack
Reading events, reconciling what the chain says against your own database, handling fees and ordering, retries, and monitoring that tells you a transaction is stuck rather than merely slow. This is where most of the engineering hours actually go, and it is the thinnest part of nearly every project we are asked to inherit.
- Custody
Wallets, signing, and who can lose a key
Sign-up a non-crypto user can finish, a custody model chosen on purpose rather than by default, and honest handling of the failure states: wrong network, refused signature, pending forever, lost key. In fintech work this is where compliance and usability collide, so it gets designed rather than bolted on. We build under an ISO 27001:2022 certified information-security management system.
02Case studies
A trading platform we built this way
One published build in commodity trading, where the on-chain part is one component of a much larger platform.
See all case studies
03Fit
Choosing between Ethereum and a database
A blockchain buys exactly one thing: several parties agreeing on one record without a party they all have to trust. If such a party exists and is willing, a database under that party gives the same property for far less. Many problems that arrive as blockchain projects are ones an ordinary database already solves, so the first two rows below start with the database, and row three is where Ethereum earns its place.
| Your situation | What we recommend |
|---|---|
| One company owns the process and owns the data | Use a databasePostgreSQL with a table nothing can edit after the fact, plus signed exports, gives you the property you were actually asking for at a fraction of the running cost. |
| You want a record nobody can quietly rewrite, and there is an operator all sides accept | Use a databaseThen a chain solves a problem you do not have. Signed, append-only records in an ordinary database under that operator satisfy everyone and cost far less to run. |
| Several organizations that do not trust each other must agree on one record, and no neutral operator is acceptable to all of them | Use a chainEthereum or another compatible network. This is the case it was designed for, and everything else on this page assumes you are in it. |
| The record has to include personal data you may later be required to delete | Keep it off the chainPermanence and a deletion request cannot both be satisfied, so record a fingerprint and hold the data where you can erase it. We raise this alongside our security and compliance work before any contract code exists. |
| A high volume of small transactions, and the cost of each one matters | A cheaper networkA cheaper network built on top of it, if you genuinely need what the main one guarantees. If you do not, no chain at all, and the saving is the whole point. |
| The requirement arrived as 'we need a blockchain strategy' | Advisory firstThat is a technology advisory conversation about two or three specific decisions, and it usually ends with a smaller and cheaper system. |
Scope
What we own is that decision and everything downstream of it: which state goes on the chain and which does not, and the custody model that decides who is able to lose a key. We also own what happens in the moment a transaction confirms and your database does not know yet, and whether your own team can operate the result. unicrew has been building platforms like this since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system. When a conventional system with no chain in it fits the problem, that is custom software development, and it is what we build.
04Delivery
The order that keeps a contract from becoming a liability
Four things we sequence deliberately, because every one of them is expensive or impossible to change once a contract is deployed.
- Write the trust model down before the architectureWho the parties are, what each can do alone, what needs agreement, and what happens when one of them behaves badly. That document decides whether a ledger is justified, and you have the answer before anyone writes contract code, which is the cheapest point to have it.
- Decide what goes on the chain, and keep it smallOn-chain storage is the most expensive you will ever buy, it is public, and it is permanent. Usually the answer is a fingerprint plus the minimum state the rule needs, with documents in ordinary file storage and the readable model in your own database.
- Build the contracts as if the money is realUnit tests, tests that hunt for broken assumptions, tests against a copy of the live network, automated code analysis in the pipeline, and independent review before deploy. The upgrade path is decided in advance rather than discovered during an incident. Detail on the Solidity page.
- Plan for keys and for stuck transactionsKey custody, rotating who can sign, and a rehearsed answer to a transaction that will not confirm, a network reorganization or a fee spike. These are operating problems rather than contract problems, and they are the ones that wake people up at night. Every step goes through the same QA and test automation practice we use on our own builds.
05Stack
What sits on either side of the chain
The five parts a system like this is actually made of, each with a page of its own.
06Questions
The questions a blockchain project starts with
The six that come up most, answered the way we would answer them on a call.
Yes, and our engineers begin by confirming that several parties really do need one shared record, so the contracts they write are ones the problem needs. The split between what runs on the chain and what does not is reviewed by an architect outside the delivery team, and the code goes through the same QA practice as our own projects. Team extension is managed teams.
The main network when final settlement between strangers is worth the cost of each transaction, which is narrower than the pitch decks suggest. A cheaper network built on top of it when you want the same tools and can accept its own assumptions. A closed network when every participant is known, in which case be honest that you have built a shared database with a governance question attached. All three use the same Solidity skills.
When several organizations must agree on one record and no neutral operator suits them all. Settling that in week one is far cheaper than settling it after a review. The test we use: name the party everyone would otherwise have to trust, then ask whether they exist, whether all sides accept them, and what it would cost to make them auditable instead. If that works, you get a smaller system on a conventional database, settled during technology advisory rather than three months into a build.
Yes, and the first questions are unglamorous. Does the deployed code match the repository, and can anyone check. Who holds the keys that can upgrade, pause or drain anything. Is there a test suite that runs against a copy of the live network. Does the reader that feeds your database recover after downtime, or silently skip blocks. We map that before touching features.
A scoping call with an engineer rather than a sales call. If something already exists we ask for read access to the repository and the addresses of anything deployed, because an hour reading published source beats three spent describing it. What comes back is a written read on what belongs on the chain, what does not, and what we would build first. Most engagements start within two to four weeks.
Three shapes. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and we offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Weighing a blockchain for this system?
Describe the parties, what they have to agree on, and who currently sits in the middle. You will get a straight recommendation, on-chain or on a conventional database. If it turns out to be an ordinary platform build, that is custom software development.