How to build something honest with a blockchain

I've shipped two student-grade on-chain products this year — TraceCraft for supply-chain provenance and LawLedger for legal documents. Neither is going to put a Big Four firm out of business, but both taught me something I'd repeat in a real product.

The default mistake

The tempting move is to put everything on-chain. Photos, PDFs, full audit trails. It feels rigorous. It also makes your dApp slow, expensive, and impossible to delete from — and "you can't delete this" is sometimes a feature and sometimes a regulatory disaster.

A better default

Put the minimum verifiable state on-chain. Hashes, ownership transitions, time-boxed access grants. That's it.

Put the rest in regular storage:

• Files in IPFS, encrypted client-side. The chain only knows the CID hash; the user holds the decryption key.
• A read model in Postgres or Mongo, kept fresh by an indexer that listens to contract events. Your consumer-facing site loads in <200ms because it never touches the chain on the read path.

This split also fixes most "regulator asked us to remove a record" problems: you delete the off-chain copy, the on-chain hash becomes meaningless, and the audit trail still tells the truth about what happened.

Identity is the real boss fight

Decentralization is the easy part of a dApp. The hard part is onboarding a non-technical user without making them write down a 12-word seed phrase.

I think the answer is custodial-then-self-custody: start the user with a server-managed wallet so they can use the product immediately, then let them export to their own wallet when they're ready. It feels icky if you've drunk the maximalist Kool-Aid, but it's how real users will get on-chain — and it's a far better experience than the status quo of "lose this paper, lose your house."

If your dApp's first screen shows a seed phrase, you're building for engineers, not users. That's fine, but be honest about it.