Software & Cloud Development

Blockchain development

Blockchain is useful for a narrow set of problems: several organizations that do not fully trust each other need to share a record that nobody can quietly change. For many other problems a well-designed database is simpler and cheaper. We help you tell the difference, and build carefully when a ledger is the right answer.

Who this service is for

A good fit if

  • Several independent organizations, such as suppliers, partners or regulators, need to share and verify the same records.
  • You need a tamper-evident history of events, such as provenance, custody or approvals, that others can check independently.
  • You want to issue credentials, certificates or records that third parties can verify without contacting you.
  • You are exploring tokenization or digital assets and want an engineering view that is candid about risks and regulation.
  • An existing blockchain proof of concept needs review before going further.

Another approach may suit you better if

  • Only your organization writes and reads the data. A conventional database with audit logging will usually serve you better.
  • You are looking for a way to raise money or offer an investment through tokens. We do not build token offerings.
  • You need high transaction volumes at very low cost with no tolerance for added complexity.

What this service is

Blockchain development is the design and engineering of systems built on a distributed ledger: a shared record, copied across several participants, where new entries are agreed by the network and past entries cannot be quietly altered. Smart contracts add rules that run automatically on the ledger.

We approach blockchain as an engineering tool, not a trend. The first question in every engagement is whether a ledger is actually the right tool, and we will tell you plainly when it is not.

Where a ledger helps

  • Supply chain provenance and custody. Recording where goods came from and who handled them, so buyers, auditors or regulators can verify the history.
  • Multi-party records. Shared registers between organizations, such as trade documents, reconciliations or approvals, where no single party should control the record.
  • Verifiable credentials and certificates. Training records, licences or certificates that third parties can check without contacting the issuer, often using W3C Verifiable Credentials alongside or instead of a ledger.
  • Document notarization. Recording a fingerprint (hash) of a document at a point in time to prove it has not changed since.
  • Tokenization and digital assets. Representing rights, memberships or loyalty points as tokens. See NFT and digital asset development for our cautious approach.

Platforms and technology

For business networks we typically recommend permissioned platforms such as Hyperledger Fabric or Hyperledger Besu, where known participants run the nodes. For public verification we work with Ethereum and compatible networks, writing smart contracts in Solidity with established, well-reviewed libraries such as OpenZeppelin. Applications and APIs around the ledger use the same technologies as our web application development, and ledger events can be connected to ERP and document systems through our business system integration service.

What a fit assessment looks at

Our assessment asks a short set of practical questions. How many organizations need to write to the record, and do they trust one another or a single operator? Must outsiders be able to verify entries independently? What data is involved, and can personal information be kept off the ledger? What happens if a participant leaves, or a key is lost? What would a conventional database with audit logs cost by comparison? The answers usually make the right choice clear, and the report records them so your decision can be explained later.

Security, privacy and regulation

Blockchain systems fail in ways conventional systems do not. A bug in a deployed smart contract can be permanent, and a lost private key can mean lost control. We test contracts extensively, require independent audits before production, design key custody and recovery with care, and keep personal information off the ledger to respect privacy principles under PIPEDA and provincial laws.

Regulation is an important constraint. Activities involving crypto assets or tokens may be subject to securities regulation overseen by provincial regulators and coordinated through the Canadian Securities Administrators, and to anti-money-laundering requirements. We do not build token offerings or investment products, and we recommend you obtain legal advice before any project involving digital assets. For a related look at secure platforms, read building secure trust management and trading platforms.

What is included

The exact list is agreed in writing for each project. These are the usual deliverables and the usual boundaries.

Typical deliverables

  • A fit assessment comparing a blockchain with conventional alternatives, with the reasoning written down.
  • A choice of platform, such as a permissioned ledger (Hyperledger Fabric or Hyperledger Besu) or a public network, with trade-offs.
  • Architecture covering on-chain and off-chain data, identity, key management and integrations.
  • Smart contracts or chaincode, with automated tests and internal review.
  • Coordination of an independent security audit of smart contracts before production use.
  • Applications, APIs and dashboards that let users work with the ledger without needing to understand it.
  • Integration with ERP, document management and identity systems.
  • Operational documentation covering nodes, keys, upgrades and incident response.

Not included unless agreed separately

  • Independent smart contract audits, billed separately by the auditing firm you choose.
  • Legal, securities, tax or accounting advice, including whether a token is a security.
  • Token sales, fundraising, exchange listings or market-making.
  • Network transaction fees and third-party node or infrastructure services.

What we will need from you

Most delays in this kind of work come from access and decisions, not from the technical build. Knowing these early keeps the project predictable.

  • A clear business problem and the organizations that will take part in the network.
  • Agreement among participants on governance, meaning who can join, write, read and approve changes.
  • Legal and compliance advice on the regulatory position of what you plan to build.
  • A plan for how private keys will be held and recovered.
Delivery

How the work is delivered

Each stage ends with something you can review before the next one starts.

  1. Assess fit

    Examine the problem, the participants and the trust relationships, and compare a ledger with a conventional database or other approaches.

    Output: Fit assessment and recommendation.

  2. Design

    Choose the platform, governance model, data split between on-chain and off-chain storage, identity and key management.

    Output: Architecture and governance outline.

  3. Prove

    Build a limited proof of concept with real participants and realistic data to test assumptions.

    Output: Working proof of concept and findings.

  4. Build and audit

    Develop production smart contracts and applications, test them thoroughly and arrange an independent security audit.

    Output: Audited contracts and applications.

  5. Launch and operate

    Deploy in stages, monitor the network and applications, and hand over operations documentation.

    Output: Production system and runbook.

Testing and handover

  • Smart contracts have automated tests covering normal use, edge cases and attempts to misuse them.
  • An independent audit is completed before production use, and every finding is fixed or formally accepted.
  • Personal information is kept off the ledger, with only references or hashes stored on-chain.
  • Private key storage, rotation and recovery procedures are documented and tested.
  • Upgrade and emergency procedures for contracts and nodes are written down and rehearsed.

What affects the cost

We do not publish package prices. Each estimate is based on an agreed scope, in Canadian dollars, with taxes shown separately. These are the things that move the number most:

  • The number of participating organizations and the complexity of governance.
  • Public or permissioned network, and who operates the nodes.
  • The complexity of smart contract logic.
  • Integrations with existing systems.
  • Security audit scope and key management requirements.

Questions buyers usually ask

Do we actually need a blockchain?

Often not. If one organization controls the data, a database with audit logging is simpler, faster and cheaper. A ledger earns its place when several parties need a shared record none of them controls alone. Our fit assessment answers this question first.

Public or permissioned blockchain?

Permissioned ledgers, where known participants run the network, suit most business consortia because they offer privacy, predictable costs and clear governance. Public networks suit cases where anyone must be able to verify records independently. We compare both for your case.

Can personal information go on a blockchain?

It should not. Records on a ledger are very hard to change or delete, which conflicts with privacy principles under PIPEDA and provincial laws. We store personal information off-chain and put only references or hashes on the ledger. This is general information, not legal advice.

What are the regulatory risks?

They depend on what you build. Activities involving crypto assets or tokens may fall under securities regulation or anti-money-laundering rules, including FINTRAC registration for some businesses. We build with those constraints in mind, but you need legal advice on your specific plans.

Are smart contracts secure?

Only as secure as their code and the keys that control them. We test contracts thoroughly, use well-reviewed libraries, and require an independent audit before production. Deployed contracts are hard to change, so mistakes are costly.

Wondering whether blockchain fits your problem?

Describe the records involved, who needs to share them and why trust is an issue. We will reply to arrange a conversation about whether a ledger or a simpler approach makes sense.