Case study · Subscription product
Sajusaju — a subscription content product of our own
In production
our own product, taking live payments
Two apps
public service and a separate admin console
Live
open it in your browser
Challenge
A paid content product has two failure modes that have nothing to do with design: money that does not reconcile, and long-running computation that blocks the web request while a customer is waiting for something they already paid for.
Solution
A separate computation back end so the deterministic part of the work is calculated on its own terms, a distributed worker queue for anything long-running so nothing blocks a request, and a stored-credit checkout built in-house against a payment gateway with coupons, refunds, and a ledger we can audit.
Results
A product that has been through launch and is running with real customers and real transactions — and an admin console where the content pipeline can be changed without shipping a new build.
- Client
- Our own product — Celis
- Scope
- Full stack · payments · admin console
- Stack
- Next.js · FastAPI · Celery · Redis · PostgreSQL
The reason we point clients at this one
Studio projects prove that a team can design and build. They do not prove that a team has taken money from strangers, reconciled a ledger, issued a refund, and kept the thing running the following month. Sajusaju is the case that covers that gap: it is our own product, it is in production, and the payment flow was built by us rather than dropped in as a hosted button. When a client asks whether we have shipped commerce for real rather than as a demonstration, this is the URL we send.
Separating what must be exact from what must read well
The product combines a rule-based calculation with written interpretation, and those two things fail differently. If they share one pipeline, a change to the wording risks the arithmetic and a change to the arithmetic risks the wording. So they were split: the calculation runs deterministically in its own back end, and the written layer runs through a separately configured pipeline. Long reports go to background workers with job status monitoring, so a slow report never holds a web request hostage and a stalled job can be found and restarted rather than silently lost.
An admin console that avoids a deploy
Tone, content settings, and routing are edited from the admin console and take effect immediately, without a code change or a release. That sounds like a convenience and is really a survival mechanism: an operator who has to file a ticket and wait for a deployment to change one line of copy will eventually stop improving the product. The public service and the console are separate applications sharing an authenticated session across subdomains, so permissions stay strict without making the operator log in twice.
If you need payments that reconcile and an admin your team can actually run, this is the case worth asking us about.
sww@celis.co.kr