Case study · Jan – Aug 2026
CaseConduit.io: from blank page to a live, billing SaaS platform — solo
I set myself a challenge: take one idea — AI-powered business case-study teaching — from conception to a real, commercial product, alone, in months not years. This page is about the architecture and the decisions, because those were the actual job.
01The brief I set myself
Business schools teach with case studies — written accounts of real corporate situations that students analyse and debate. Having spent 15 years running IT at a case-method publisher, I knew the market and its gap: authoring tools, simulations, live classroom delivery and AI feedback existed nowhere in one place. CaseConduit is that suite — studios for writing cases, building playable simulations, generating narrated story films, and delivering all of it to live cohorts.
The product thesis mattered less than the operational thesis: could one person design, build, run and sell a production AI platform? That only works if the architecture does most of the operating.
02Constraints first
- Party of one. No ops team, no on-call rota. Anything that needs babysitting is a design failure.
- Fixed costs near zero. Revenue starts at £0, so idle infrastructure must cost pennies. Variable cost (AI tokens) must be measured, capped and priced — per feature, per user, per day.
- AI is slow and occasionally unavailable. Long generations, provider overloads and timeouts are normal operating conditions, not exceptions. The user should never lose work because of them.
- Sell to institutions eventually. Universities and firms ask about SSO, LMS integration, billing and data handling before they buy. Enterprise readiness had to be designed in, not bolted on.
03The architecture
Everything static lives in S3 behind CloudFront; every module in the suite is a static app. There are no servers. All dynamic work — AI calls, voice synthesis, billing, entitlements, admin — funnels through a single API Gateway endpoint into one Lambda, which is the only place secrets live and the one chokepoint where every request can be authenticated, metered, logged and cost-attributed.
The single-chokepoint decision is the load-bearing one. Because every AI and billing request passes through one function, adding usage metering, per-plan entitlements, abuse caps, cost attribution and Stripe webhook handling never required new infrastructure — each was a change to code already standing in the request path.
04Deep dive: the 29-second wall
API Gateway terminates every request at 29 seconds — a hard AWS quota, not a setting. AI generations routinely run far longer. The naive result: the gateway returns a 504, the browser gives up, the Lambda finishes minutes later, and the user's work — already paid for in tokens — evaporates.
My fix treats the timeout as a normal event in a longer conversation. The client stamps each request with a unique ID; the Lambda journals the job's state to S3 — running, then done with the full result. When the gateway cuts the connection, the client simply polls a status action every few seconds and collects the result when it lands. A dedupe guard means a retry against a live job returns "still running" rather than starting a second generation, and a retry against a finished job replays the stored result instantly — no double token spend, ever.
I also chose what not to alarm on. My CloudWatch alert fires on Lambda errors — real crashes — and deliberately ignores gateway 5XXs, because once the resume protocol existed, a 504 stopped being an error and became the expected first act of every long generation. An alarm that cries wolf nightly is worse than no alarm.
I proved the design with a purpose-built test harness before trusting it: forced-long generations recovering after the 504, killed connections mid-flight, burst-load of parallel requests — all landing their results.
05Deep dive: making AI unit economics work
AI features have a marginal cost per click, which most side projects ignore and most businesses discover too late. I built the accounting into the chokepoint from the start: every request's real token usage is logged and converted to cost, aggregated per day and per module, and surfaced in an admin dashboard.
- Pricing is derived from measured cost, not vibes: one credit represents one cent of metered AI spend, and plan prices target a healthy margin over observed usage — so the pricing page stays honest by construction.
- Two revenue lines: monthly credit subscriptions for creators, per-learner seats when a cohort plays — the scalable half, priced deliberately under the incumbent's per-seat rates.
- Cost defence in depth: gateway rate throttling, per-day usage caps on unauthenticated surfaces, and per-user monthly credit gates for signed-in creators. A runaway script or a viral demo can be annoying; it cannot be ruinous.
- Model spend tuned per feature: in-game simulation turns disable the model's deliberation mode (deterministic length, ~3× faster, several-fold cheaper), while authoring and assessment keep full reasoning quality. Same API, different economics per call site.
06Deep dive: enterprise-ready as a party of one
Institutional buyers ask predictable questions — single sign-on, LMS integration, self-serve billing, data handling. Each got a pass-based build: ship the smallest production-grade slice, prove it end-to-end, leave a clean seam for the next slice.
- SSO: SAML federation through Cognito into the existing user pool — tokens, groups, entitlements and billing all unchanged. Customer onboarding is a ten-minute metadata exchange, registered by URL so their certificate rotations never need my involvement.
- LMS: LTI 1.3 launch flow live and proven against a test driver I authored myself — sixteen assertion checks passing — with grade passback as the designed next pass.
- Billing: Stripe Checkout and customer portal, webhook-driven entitlements, live since July 2026. Deliberately dependency-free — raw HTTPS and manual signature verification in the Lambda — because every dependency is something a solo operator must patch forever.
07Outcomes
08Decisions I'd defend in an interview
- Static-first, one chokepoint.
- Boring on purpose. It's why metering, billing, caps and cost logging were each incremental additions rather than projects.
- Plans are data, not identity.
- Roles live in Cognito groups; billing state lives in a data store. Groups answer "who are you", plans answer "what have you paid for" — conflating them makes every upgrade a security event.
- Design for the failure you can't remove.
- The 29-second limit is immovable, so the system treats it as choreography instead of catastrophe. Reliability engineering is mostly deciding which failures get promoted to normal life.
- Measure cost before setting price.
- The cost ledger came before the pricing page. I'd rather derive a price from a number I log than defend a number I guessed.
09How it was built — honestly
I used Anthropic's Claude as a build partner throughout, and I think candour about that is part of the skill now. My job was everything around the code: the architecture, the constraints, the failure modes, the economics, the security posture, and the judgement about what to build at all — then directing AI implementation against those designs and testing what came back. Twenty years of infrastructure experience is what informed that direction. It still took eight months and no shortage of mistakes along the way — but the result is one person and a live commercial platform.