I have built on blockchain systems, and I have also decided not to use blockchain on projects where it looked exciting on paper. That split matters.
A lot of blockchain writing is either hype or dismissal. Neither is very useful when you are actually building something. The real question is simpler: does this problem need the properties a blockchain gives you, or are you adding cost and complexity for no real gain?
This is the framework I use now. It is not a sales pitch. It is a filter.
Start with the boring question: can a database solve this?
This should be the first question, not the last one.
If one company, one team, or one trusted operator can run the system, a normal database is usually the right answer. It will be cheaper, faster, easier to change, and much easier to support.
Most products do not have a trust problem. They have an execution problem. They need better workflows, better permissions, better logs, or better integration between systems. A blockchain does not fix those things. It often makes them harder.
If your system needs:
- low latency
- private data
- frequent schema changes
- easy rollback
- cheap writes
- operational simplicity
then a regular database is probably the better tool.
I have seen teams reach for blockchain when what they really needed was an append-only audit log, signed events, or shared access to a normal API. Those are very different problems.
Question 1: do the parties actually distrust each other?
Blockchain starts to make sense when multiple parties need to coordinate, but no single party should control the system.
That is the core use case.
If all participants already trust one operator, then a blockchain is usually unnecessary. You can just use a central system with access controls and auditing.
But if you have a marketplace, clearing layer, settlement layer, or shared registry where each party wants guarantees that another party cannot rewrite the rules, that is where blockchain becomes more reasonable.
Ask:
- Who would run the database?
- Would the other parties accept that operator as neutral?
- What happens if that operator changes rules, blocks users, or edits records?
- Is removing that control point part of the product value?
If the answer is everyone is fine with us running it, stop there. Use a database.
If the answer is the system only works if no one has unilateral control, keep going.
Question 2: do you need strong immutability, or just good history?
People say they want immutability, but often they only mean they want traceability.
Those are not the same thing.
A lot of business systems need a clear history of changes. That can be handled with event sourcing, append-only logs, versioned records, backups, and signed audit trails. You do not need a blockchain for that.
Blockchain makes more sense when records should be very hard to alter after the fact, even by the operator. That matters when parties may dispute what happened and need a shared source of truth that no one side can quietly change.
Examples where this can matter:
- asset ownership records
- settlement records between separate institutions
- public attestations or proofs
- cross-organization workflows with high dispute risk
Examples where it usually does not:
- internal admin dashboards
- product analytics
- CRM data
- order management inside one company
- most SaaS application state
Immutability is expensive. You are giving up the ability to easily fix mistakes. Make sure that tradeoff is worth it.
Question 3: is shared coordination the real problem?
Many good blockchain use cases are really coordination problems.
Not storage. Not branding. Coordination.
A blockchain can help when multiple actors need to agree on state transitions without relying on one central intermediary. That can be useful for payments, asset transfers, shared ledgers, and systems where rules need to execute predictably for everyone.
That is why blockchains are more compelling around:
- settlement
- custody-lite systems
- tokenized assets
- interoperable financial primitives
- public registries with many writers and readers
I have worked on systems where the value was not put it on chain. The value was that separate participants could integrate against a common state machine and not negotiate trust with one platform owner.
That is a real advantage.
But if your app is mostly a standard product with a user table, billing logic, feature flags, and private workflows, then the coordination problem is probably not your bottleneck.
Question 4: does the system need to be credibly neutral?
This is the stronger version of the trust question.
Sometimes users do not just want you to be honest. They want the system designed so that you do not get special power.
That can matter in systems where platform incentives and user incentives may diverge. Think exchanges, marketplaces, issuance systems, or protocols where users lock in capital and need confidence that the rules will not change casually.
A blockchain can provide a form of credible neutrality, especially when logic is transparent and governance is constrained.
But be honest here. Most early products are not fighting a neutrality problem. They are fighting product-market fit. Adding a blockchain layer before you know users care about neutrality is often premature.
Question 5: what are you willing to pay for these properties?
Blockchain comes with real costs:
- slower throughput
- more complex developer experience
- worse debugging
- harder upgrades
- irreversible mistakes
- user onboarding friction
- key management risk
- compliance and legal overhead
Even when the architecture is right, the product can still fail because the operational cost is too high.
I have been in projects where the blockchain part was technically justified, but everything around it got harder: support, monitoring, incident response, migrations, and user education.
That does not mean the choice was wrong. It means you should count the full cost, not just the architecture diagram.
A simple decision test
Here is the short version I use.
Use blockchain only if most of these are true:
- multiple parties need to write or verify shared state
- no single party should have full control
- tamper resistance is a core requirement
- transparent rules or execution matter
- interoperability or portability of assets matters
- the extra complexity is worth the trust tradeoff
Do not use blockchain if most of these are true:
- one company can run the system
- users already trust the operator
- private data is central
- performance and flexibility matter more than neutrality
- records need to be editable or easily reversible
- the blockchain layer is mostly for fundraising, marketing, or trend alignment
If you cannot clearly say what gets better because of blockchain, do not add it.
Grounded examples
A case where blockchain made sense: a system where independent participants needed a shared ledger for asset movement, and none of them wanted one operator to have edit power over balances or settlement history. The point was not web3. The point was reducing reliance on a central controller in a workflow where trust and reconciliation were expensive.
A case where it did not make sense: a product that wanted on-chain reputation for user actions inside a single application. In practice, the app team already controlled the identity system, moderation rules, and user experience. A normal database with signed audit events handled the real need. Putting reputation on chain added complexity without removing any meaningful trust assumption.
Another case where I passed on blockchain: internal workflow software with partner visibility. At first it looked like a multi-party coordination problem. But once we mapped the incentives, one organization was already the accepted source of authority. The other parties wanted access, reporting, and operational reliability, not decentralization. A well-designed central system solved it better.
The practical rule
Blockchain is not useless. It is just narrow.
It makes sense when you need shared state across parties that do not want to hand control to one owner, and when that property is important enough to justify real cost.
It does not make sense when a trusted service and a database already solve the problem.
That may sound obvious, but it cuts through a lot of noise.
The best reason to use blockchain is not that it is modern. It is that your system breaks, politically or economically, if one party controls it.
If that is not true, keep it simple.
