Product Planning
When Blockchain Is — and Isn’t — the Right Choice
A practical Kensaltensi guide for product, engineering and QA teams.
Start with the problem, not the technology
Blockchain can provide shared, tamper-resistant state and programmable digital ownership, but those benefits come with cost and operational complexity. A product should adopt it because a requirement needs those properties, not because decentralization is fashionable.
Strong reasons to consider blockchain
A blockchain can make sense when independent parties need to agree on shared state without giving one participant unilateral control. It can also be useful when assets must be transferable across applications, when transparent settlement is important, or when users need direct custody of digital assets.
Weak reasons
“We want Web3” is not a requirement. Neither is using a blockchain as an expensive database for information controlled by one company. If the product requires private mutable records, instant low-cost writes and a trusted operator already exists, conventional infrastructure may be more appropriate.
Decision questions
- Who are the parties that do not fully trust one another?
- What state must be independently verifiable?
- Does the user need custody or transferability?
- Can the data be public, or at least represented publicly?
- Who pays network fees?
- What happens during congestion or chain downtime?
- Can mistakes be reversed, and should they be?
- What regulatory or privacy obligations apply?
Cost and scalability
On-chain writes consume network resources and can have variable cost. High-volume products need realistic transaction models rather than optimistic testnet assumptions. Layer-2 networks and alternative chains can reduce cost, but they introduce their own security, liquidity and operational considerations.
User experience
Wallet setup, signing prompts and gas are unfamiliar to many users. Teams should decide whether self-custody is essential or whether an abstraction layer is appropriate. Recovery, support and error handling need to be designed before launch, not after users lose access.
Privacy
Public blockchains are poor places for confidential personal information. Encryption does not automatically solve permanence and metadata exposure. Keep sensitive data off-chain unless there is a carefully reviewed reason and architecture for doing otherwise.
Hybrid systems
The choice is rarely “everything on-chain” versus “no blockchain.” A hybrid system can use a contract for settlement or ownership while retaining databases for profiles, search, analytics and private operational data. This often provides the desired trust properties without making every feature depend on consensus.
A simple rule
If removing the blockchain would not remove an important user benefit or trust property, question whether it belongs in the architecture. If it enables a capability that participants genuinely cannot obtain from a conventional trusted service, then it may be worth the additional complexity.