Blockchain at the core of an IT product: when it helps and when it does not
Blockchain solves a specific shared-trust, ownership or immutable-record problem. If a product does not need those properties, a conventional database will be simpler, cheaper and faster.
Start with the trust problem, not the technology
Blockchain is useful when several parties must agree on state without one trusted operator, users should control a digital asset or the history must be independently verifiable. Handling payments, documents or data from several companies is not enough by itself.
If one organisation controls writes and needs to correct mistakes, a relational database will usually deliver better performance, privacy and maintainability.
Architectural decisions that cannot be hidden
The team must choose a network, fee model, token standard, key-management approach, on-chain/off-chain boundary and smart-contract upgrade process. Every choice affects security, transaction cost and user experience.
Personal data and large files usually should not live directly on a public chain. Store them elsewhere and record only the identifier, hash or event needed for verification.
The proof of concept should test the hardest transaction
A PoC should not stop at writing a simple record. It must include wallet flow, signing, fees, confirmation, errors, retries and event synchronisation with the product backend. Only then does it reveal real cost and friction.
- What does the user own and who may change it?
- What happens when a key is lost?
- How does the product handle network delay or reorganisation?
- Which data must remain private?
- What is the smart-contract migration plan?
Monarty: a product where blockchain was part of the model
In the Monarty marketplace, Ethereum, ERC721 and ERC1155 standards, wallets and IPFS were directly tied to ownership and exchange of digital art. This is a case where the technology supported the product promise rather than serving as a marketing add-on.
Content updated: July 29, 2026