Free trials
Trial length is a per-plan column and a trialing subscription is a first-class state, not a coupon with a short expiry.
Plans, intervals, trials, coupons and the entitlement check that decides whether a viewer may press play. This is the part of the platform with paying users on it, so the description is of code rather than of a roadmap.
Plans live in the database and are edited from the admin console. Each carries a name, a price in taka, an optional price in dollars, a billing interval, a duration in days, a trial length, an active flag and a sort order. Adding a plan is adding a row; it is not a deployment and it does not involve us.
Taka is the primary currency and that is a schema fact rather than a positioning line: `price_bdt` is the non-null column and `price_usd` was added afterwards as nullable. A platform built for another market treats this the other way round, and the difference shows up as rounding on every invoice.
The seeded plans a new estate starts with are 90 taka monthly, 300 quarterly and 900 yearly, each with a seven-day trial. They are a starting point to be replaced with yours, not a price list we recommend.
The columns that exist on a plan, and what each one controls.
| Field | What it holds | Notes |
|---|---|---|
| Price in BDT | Decimal, required | The primary currency; not a conversion |
| Price in USD | Decimal, optional | Added after BDT and nullable, deliberately |
| Billing interval | daily · weekly · monthly · quarterly · yearly | Five, from the schema enum |
| Duration in days | Integer, default 30 | What the entitlement window is measured in |
| Trial length | Integer days, default 0 | Seeded at 7 on the sample plans |
| Recurring flag | Boolean | Marks the plan as a recurring product — see the renewal note below |
| Active flag and sort order | Boolean, integer | Controls whether and where it appears |
Playback does not trust the client. When a viewer presses play, the platform asks billing whether that account currently holds a subscription that has not ended, and separately whether it holds a one-off purchase for that title. Either answer opens the title; neither answer closes it politely.
The check is a comparison against the period end rather than a flag somebody remembered to clear. A subscription that has run out is expired because the date says so, which means there is no state where a cancelled account keeps working because a job did not run.
Trial length is a per-plan column and a trialing subscription is a first-class state, not a coupon with a short expiry.
A separate coupon service with its own deployment. Redemptions are readable per coupon, and the admin create route sits behind a key gate proven by a verification playbook.
Every payment attempt is a row with a state — pending, success, failed or cancelled — readable per user and in aggregate from the console.
Monthly recurring revenue in taka, a monthly revenue series and subscriber counts by current status. Real figures, out of billing.
Nothing yet distinguishes a cancellation today from one in March, because no subscription state-transition history is recorded. Churn is the prerequisite for lifetime value, so it is two builds rather than one.
What exists is a snapshot ratio of accounts trialing now against paid now. Nobody is followed from trial to decision over time, which makes it a ratio rather than a funnel.
None, today, and this is worth reading rather than skipping. The device limit is a single service-wide value with a default of 3, identical on every plan, and a slot is a registered device rather than a playing stream — so two streams on one device count once. Selling '1 stream' on a basic plan and '2 streams' on a premium one would be a promise the code does not keep. Making the limit per-plan and counting streams is a scoped build.
Not today. The plan carries a recurring flag and an interval, and entitlement lapses when the period ends. There is no scheduler in the billing service that initiates the next charge, and no retry ladder behind the past-due state. Recurring collection is a build inside an engagement.
Yes. Plans are database rows edited from the admin console — price, interval, trial length, whether the plan is visible and where it sorts. No release is involved and we are not in the loop.
Taka. `price_bdt` is the required column on a plan and the gateway settles in BDT; the USD column exists and is optional. This is the schema's shape, not a display preference.
Most catalogues need three or four plans and one trial length. Send yours and we will tell you what maps onto what runs today and what needs building.