Solidity smart contract development
Solidity is a small language with an unusually high cost of being wrong. Deployed code is public, permanent unless you planned otherwise, and holds whatever value you point at it. That changes how the work has to be run, not just who writes it.
01Capabilities
Four jobs, each assuming the code can be wrong
Solidity is the language for contracts on Ethereum and compatible networks. Which network, and whether a chain belongs in your system at all, is settled on our Ethereum page before anyone opens an editor. This page picks up afterwards, and the work takes four shapes.
- Settlement
Settlement, escrow and payout logic
The rule that decides when value moves, written so no party can quietly change it afterwards. Small contracts, explicit states, and every transition tested, because a mistake here is a transfer nobody can reverse. That guarantee carries weight in fintech settlement flows.
- Standards
Token, ownership and access-control contracts
Fungible and non-fungible standards, allowance and role models, pause and emergency controls. We start from widely audited reference implementations rather than writing our own version of a standard, because originality in this layer is a liability rather than a feature.
- Recovery
The plan for the day it is wrong
Who can pause it, who can replace the logic, who approves that, and how you find out something is wrong before a counterparty tells you. We answer those in writing before anything reaches a live network, because afterwards the answer is whatever you happened to deploy.
- Harness
The test and verification harness
Unit tests, tests that hunt for broken assumptions, tests against a copy of the live network, and automated code analysis wired into the pipeline. This is most of the actual work, and its absence is the clearest signal in a repository we are asked to inherit. It runs through our QA and test automation practice.
02Fit
Where each rule belongs, on the chain or off it
Solidity is not the decision. The decision is which rules deserve to be public, permanent and impossible to quietly amend. Everything else is cheaper, safer and easier to change somewhere ordinary. Each row below names the right home for the rule or the step it needs, from a contract on the chain to a database table or an independent audit.
| Your situation | What we recommend |
|---|---|
| A rule has to hold between parties who cannot rely on each other's systems | Use SolidityKept as small as the rule allows. Which network it runs on is the Ethereum question rather than this one. |
| One company owns the process, and every side accepts that company's records | Use a databasePostgreSQL with a table nothing can edit after the fact gives you the property you were asking for, at a fraction of the running cost. |
| The rule moves with pricing, fees, limits or regulation | Keep it in your backendCode you cannot casually change is an asset for a settlement rule and a liability for anything the business tunes every quarter. |
| You are still finding the product and want to change it weekly | Settle the product firstA review cycle is not a sprint, and a bug you cannot roll back is a different class of risk from a bad release you can. |
| The contracts will hold real value | Independent auditA reviewer with no stake in the code gives the final sign-off. We plan the schedule around that, alongside our security and compliance work. |
| The network you are targeting is not Ethereum compatible | Pick the platform firstThose platforms use different languages and tooling, and pretending otherwise costs you a rewrite. Settle it during technology advisory. |
Scope
What we own is the boundary: which rules live in the contract, which live in the application, and what happens at the seam when the two disagree. We also own the unglamorous half, because a correct contract behind a broken integration layer is still a broken product. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. The work runs under an ISO 27001:2022 certified information-security management system. Where the conclusion is that nothing needs to be on a chain, the work is custom software development, and that is the better result for you.
03Delivery
Everything that has to be true before deploy
Four steps, in this order, and the order is the point. The expensive mistakes in this ecosystem are almost all sequencing mistakes rather than coding ones.
- Specify the states before writing any SolidityEvery state the contract can be in, every allowed move between them, every actor who can trigger one, and what is deliberately impossible. Most contract vulnerabilities are gaps in that specification rather than syntax mistakes, which is why the document comes before the code.
- Test the way an attacker behavesTests for the intended path, then tests that hunt for the states nobody imagined. Access-control and re-entry cases written out explicitly, and a run against a copy of the live network with real balances and real dependencies in place.
- Independent review before deploy, never afterInternal review by an engineer who did not write the code, automated analysis in the pipeline, then an external audit for anything holding value. Findings get fixed and retested rather than logged and accepted, and we move a date rather than skip that.
- Deploy with the operating answers written downWho holds which key, what the pause procedure is, how a replacement would be executed and by whose approval, and how you learn something is wrong before a counterparty tells you. A deploy without those answers is a launch with no brakes.
04Stack
What the rest of the system is made of
The contract is the smallest part. These four pages cover everything around it.
05Questions
Questions about code you cannot take back
Answered the way we would answer them on a call. If yours is not here, it is a good first message.
Our engineers can work inside your team, and engagements do start that way. The result is owned from the first contract: the contract boundary and the replacement model are reviewed by an architect who is not writing the contracts, under the same QA practice as our own projects. Team extension is managed teams; the outcome is custom software development.
Only if you designed for it. A plain contract is fixed once deployed, and the usual workaround keeps the address and the stored data while pointing at replaceable logic. That works, and it relocates the risk: whoever controls the replacement controls the contract. We make that an explicit governance decision, written down with the parties who depend on it, rather than a default copied from a template.
Put a rule in a contract only when the parties need certainty it cannot be changed behind their backs. Settlement conditions, escrow release and ownership transfer qualify. Fee schedules, identity checks, pricing and anything touching personal data do not. A useful check: if you would be happy sending the rule to every counterparty and never editing it again, it can go on a chain.
Internal review, automated analysis and tests against a copy of the live network catch a great deal. For anything holding real value, the final check is an independent auditor with no stake in the code, so we recommend one and plan around it.
A scoping call with an engineer. Beforehand we want whatever exists: the repository, the deployed addresses, the test suite, and the specification if one was ever written. What comes back is a written read on what should be on a chain, what should not, and the order we would do it in. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, offered once the first read is done. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Have a contract to write, or one you inherited?
Send the repository, or just the deployed address if that is all you have. You will get an engineer's read on what it does, where the risk sits, and where each rule belongs, on the chain or off it.