Smart Contract Development

Last updated: 11 November 2026

This page is for founders, product teams and businesses that need contract code written, tested and handed over properly. It explains what we build, how a project runs, which security practices to expect, and what we will not promise. It is a services page, not a tutorial; if you are learning how smart contracts work, a developer-documentation site will serve you better. Our general blockchain development page gives the wider overview.

Do you need a smart contract at all?

Many ideas that start with “we need a token” are better served by a conventional database and payment system. A contract earns its place when several parties who do not fully trust each other need a shared, public record that nobody can quietly change, or when funds must be released automatically by rules everyone can inspect. It is a poor fit when the rules change weekly, when data must stay private, or when a single company controls everything anyway. Transactions cost fees, mistakes are hard to reverse, and users need a wallet. We will say so on the scoping call if a simpler build serves you better; it saves you money and us a difficult project.

What we build

We write for EVM-compatible networks. Which specific network suits you depends on transaction fees, the wallets and tools your users already have, and any requirement from partners or exchanges. We will talk through the trade-offs with you rather than push one.

How a project runs

1. Scoping call. You describe the product, the parties involved and what must never go wrong. We ask who holds admin keys, what happens on failure, and which parts truly need to be on-chain.
2. Written specification. The contract behaviour in plain language: roles, functions, limits, events, and what is deliberately left out. You approve it before code is written.
3. Build. The contracts are written against the specification, with the simplest design that does the job. Less code means fewer places for mistakes.
4. Testing. Tests cover the normal path, the edge cases in the specification, and attempts to misuse each function. Contracts are then deployed to a test network so your team can try them with test funds.
5. Independent audit. A separate step, done by an independent auditing firm of your choice. We address what the auditor reports and share the fixes for re-checking.
6. Deployment and handover. Deployment follows a written checklist, with admin rights assigned to your wallets. Handover terms, including code and documentation, are set out in the written quote.

Security practices you should expect

No vendor can promise bug-free contracts, and you should be wary of anyone who does. These are practices we plan for and that you can ask any developer about:

• Least privilege. Each role gets only the permissions it needs. Powerful admin functions are few and clearly named.
• Admin keys held safely. Control of important functions sits with a multi-signature wallet or equivalent arrangement, not one person’s everyday wallet.
• An explicit decision on upgrades. Contracts are either fixed once deployed or upgradeable. Each choice has costs; we write the decision and its consequences into the specification.
• Careful handling of outside calls. Calls to other contracts are limited, checked and tested for unexpected behaviour.
• Tests that try to break things. Tests include failure cases, not only the success path.
• Test-network rehearsal. Every release path, including emergency actions, is practised before real funds are involved.
• A deployment checklist. Addresses, parameters and permissions are verified before and after deployment.

Audits are a separate step

An audit is an independent review of your contract code by specialists who did not write it. We treat it as its own line in the plan, with its own cost and timeline set by the auditing firm. We do not present our own review as an audit. An audit lowers risk; it does not remove it, and it applies only to the code version that was reviewed. If you change the code afterwards, ask the auditor about the change. Projects that handle other people’s money should budget for an audit before launch.

What we do not promise

• No returns, yield or price performance for any token, and no statement that a token will rise in value.
• No investment, tax or legal advice. Tokens, tokenised assets and fundraising may be regulated where you or your users are; take legal advice before you issue anything to the public.
• No guarantee that a contract is free of bugs, even after an audit.
• No promise of exchange listings, wallet support or user numbers.

Cost

We quote smart contract projects after a scoping call and give you a written scope with what is included and what is not. We do not publish a figure here because the same word, “token”, can describe a few dozen lines of code or a system with many roles and conditions. The main cost drivers are:

• the number of contracts and how they interact,
• how complex the rules are, such as tiers, vesting schedules or dispute handling,
• whether you need a front end or admin dashboard,
• how much testing and documentation you require,
• the audit, which is priced by the auditor separately.

Working with your own team or auditor

You may already have developers, a legal adviser or an auditor in mind. That is fine. We can write to a specification your team prepared, review code someone else wrote and explain what we find, or build alongside your engineers. Say so at the start, so the written scope shows who is responsible for each part, including who holds the deployment keys and who answers questions from the auditor.

Preparing for the scoping call

You do not need technical language. It helps to bring: what the contract should do in two or three sentences, who the parties are, who should be able to change settings, what must never happen, which network or wallets you have in mind, whether you plan an audit, and the date you would like to launch. Bring existing code if you have any, even rough drafts.

Related work

If your project is a network marketing or direct selling platform that uses blockchain payouts, read our crypto MLM software page first. It covers the legal cautions that apply to token-based payout schemes, which are significant. For other software around your contracts, see the full list of services.

Questions buyers ask