Digiipatt sells eBooks and audiobooks. The whole product comes down to one sentence: the person who paid should reach what they bought, immediately, and the person who did not pay should not.
Entitlement should be derived
The mistake I wanted to avoid was treating access as separate data — a flag someone sets after an order comes in. Anything maintained by hand will eventually drift out of sync with reality, and the failure mode is a paying customer locked out.
order completed ──► entitlement exists ──► reader / player unlocked
order cancelled ──► entitlement revokedDeriving access from order state removes the whole category of support ticket. It also forces you to handle the awkward branches — refunds, partial cancellations, repeat purchases — explicitly instead of hoping they do not occur.
Two formats means two products
I initially treated audiobooks as eBooks with a play button. They are not. Reading is scroll-driven and skimmable; listening is time-driven and linear, with buffering, seeking and background playback to think about. Designing them as one experience produced two mediocre ones, so they became two.
The moment after payment is the product
Nobody remembers a storefront they browsed. They remember what happened in the thirty seconds after they paid. That screen deserves more design attention than the homepage, and it usually gets less.
Say what you can actually guarantee
Being precise about guarantees is not weaker positioning. It is the only kind that survives contact with a determined user.
What I would do differently
- 01Model the entitlement states on paper before configuring anything in WooCommerce.
- 02Design the post-purchase flow before the storefront.
- 03Write the content policy first — it decides the interface, not the other way round.
Written by Huzaifa Ahmed