Case Study Brieflex · Programination LLC · 2025–2026
Brieflex was an AI-powered California Bar Exam training platform with active development, a live client, and no sprint structure. No time tracking. No meeting format. No SOW for the work in flight. I stepped in, audited the project, reset the delivery process, and drove it toward commercial launch.
01 / What Brieflex is
Brieflex is an AI-powered California Bar Exam training platform — built for law students preparing for one of the hardest professional exams in the US. The core premise: adaptive AI practice that mirrors how the actual exam works, not just flashcard memorisation.
The product includes a Drill Room (adaptive question sessions across IRAC, hypothetical, and rule statement types), a Custom Tutor Mode (personalised AI coaching), Flashcards with spaced repetition, a Custom Rules engine (lawyers can upload their own rules for AI-generated questions), and Progress Analytics for paid users.
The stakes are real: the California Bar Exam is in late July. Students need a minimum of 6–8 weeks of prep time with a stable product. Every week of delayed delivery is a week fewer students can use it before exam day.
02 / What I found
The project was not stalled — development was happening. But it was happening without the structure that keeps a multi-person, multi-stream build coherent. When I did the initial audit, here is what the situation looked like:
State on pickup
After first two weeks
The real risk
BetaCraft had stayed within SOW hours but had no documented proof. If Elvis or Dan had asked for a time report, there was nothing to show. Hubstaff and structured SOWs fixed this — immediately.
03 / How I stabilised it
Mid-build pickups require a specific kind of triage: understand what exists before touching anything, then fix the operating layer without disrupting active development. Here is the sequence I ran.
Read the existing SOWs, mapped what was built vs what was claimed, identified what was complete (Gemini integration, AI response reporting, drill room animations, UI fixes), what was in progress, and what was unstarted. Flash Cards were confirmed complete and removed from active scope. Admin Portal reduced to a one-day QA task only.
Ran a priority alignment session with Elvis. Confirmed new order: Custom Tutor Room first (highest client urgency), then Stripe pricing integration, then sign-up flow, with Mailchimp and analytics deferred to a second SOW. Mailchimp specifically held — required Dan's written buy-in before committing hours. This gave the team a clear, conflict-free delivery queue for the first time.
Built a four-sprint plan anchored to 29 April start, using AI-adjusted estimates at 45–50% compression for two developers running 40 hours per week in parallel. Signup scope was flagged as unscoped with a hard deadline of 2 May to size it before Sprint 2 started. Sign-up could not be estimated until Elvis clarified requirements — I made that dependency explicit rather than carrying it as ambiguity.
SOW 1 covered Custom Tutor Room, Pricing (Stripe), and Sign-up Flow — 75–86 hours at $65/hour, 50/25/25 payment split. SOW 2 covered Mailchimp, Analytics, and a 16-hour UI polish buffer — 99 hours, $6,444.75. Both produced in a single session using the existing SOW format as the base, modified line by line to match the new scope.
Elvis had explicitly asked on a prior call for structured agendas: completed tickets, in-progress, to-do — reviewed together. I committed to this format from the next meeting and delivered it. The shift from ad hoc check-ins to structured sprint reviews gave the client visibility and gave the team a clear rhythm to work toward.
04 / Sprint structure
With the bar exam in late July, I worked backwards: students need 6–8 weeks of stable practice. That meant a commercial launch no later than end of May. Four sprints, hard-gated, no scope bleed.
Why this structure mattered
Sprint 2 intentionally ran two weeks — Stripe, Mailchimp, and sign-up in parallel across two dedicated developers. Signup was held as unscoped until the 2 May hard deadline: if Elvis hadn't provided requirements by then, it would have moved to Sprint 3 rather than blocking Sprint 2. I made that dependency contractual, not conversational.
05 / Product decisions logged
Part of stabilising a mid-build project is surfacing the product decisions that are being deferred or left ambiguous. Several calls had been made verbally with no record. I logged them formally and got written confirmation from Elvis on each.
Logged decision
Switching modes mid-drill conflicts with the question pre-loading architecture. Elvis confirmed: mode is selected on the setup screen, not once inside a session. Saved a potential backend retrofit.
Logged decision
Full voice-to-voice requires ElevenLabs integration. Mac users use system dictation as a stopgap. Logged to prevent it being raised again as in-scope mid-sprint.
Logged decision
Dan (investor stakeholder) needed to be convinced via written rationale before Mailchimp hours were committed. Elvis confirmed. This blocked the team from starting work that could have been reversed.
Logged decision
Elvis wanted PDF/docx upload for custom rules. Team proposed CSV. Decision: build a prototype with a file size limit and AI pre-check filter, measure token usage, then decide on format guardrails. Prevented a premature architecture lock.
Logging these formally meant that when scope was challenged later — by Dan, by Elvis, or by the team — the answer was in the decision log, not in someone's memory of a call three weeks ago.
06 / Ongoing delivery management
Brieflex is the most complex of BetaCraft's current engagements in terms of product depth — multiple AI integrations, a monetisation layer, mobile and web surfaces in parallel, and a stakeholder triangle that includes Elvis (product decisions), Dan (commercial decisions), and the BetaCraft team.
The drill room performance problem
Elvis flagged that the initial question load felt slower after a performance update. The team's diagnosis: pre-loading is partial (~15 seconds, generating 2 questions in background). IRAC and Hypo types legitimately take longer due to AI generation complexity — rule statement types should be faster. I documented the distinction and assigned investigation specifically to rule statement performance, rather than accepting "it's just the AI" as an answer.
Each sprint review now runs with a prepared agenda: completed tickets first, in-progress with blockers called out, upcoming scope. Elvis gets a written post-meeting summary the same day. Nothing is left to memory or to the next call to re-establish.
The two-developer parallel stream required careful dependency management — Vasanta on backend and Deepak on frontend needed clear interface contracts before either started. I scoped those contracts before sprints began so neither stream was blocked waiting for the other.
07 / Outcomes
No sprint existed before. Within the first week, four sprints were planned, scoped, and committed with dates and owners.
Hubstaff activated immediately. Every hour since pickup is logged. BetaCraft can produce a time report on demand — something that wasn't possible before I joined.
SOW 1 ($65/hr, 75–86hrs) and SOW 2 ($6,444.75, 99hrs) signed. No more uncovered work in flight.
Elvis had asked for structure — structured agendas, sprint schedules, written post-call summaries. That is now the default, not the exception.
Four key product decisions formally logged with Elvis's written confirmation. When Dan or Elvis revisit these, the answer is already there.
Flashcards complete and shipped. Custom Tutor Room, Stripe, Analytics in flight. UAT and buffer sprint planned. The July exam date is reachable.
08 / Reflection
Joining a project mid-build is a different discipline from starting one from scratch. The temptation is to immediately start fixing the product. The actual job is to fix the operating system first — because a team building fast on a broken operating system just creates better-executed chaos.
The first week on Brieflex was almost entirely about audit and reset: read everything, understand what's real vs. what was planned, surface the undocumented decisions, get the client into a structure they can trust. The sprint plan came after the audit. The SOWs came after the priority alignment. Nothing was rushed because the order mattered.
The engineering background helped here in a specific way: I could read Vasanta's backend design plan and tell Elvis it was solid without asking the team to explain it. I could understand why the drill room pre-loading has different performance characteristics for IRAC vs. rule statement questions — and ask the right diagnostic question rather than accepting "it's slower" as an answer. Those aren't PM skills. They're what happens when you spend 8.5 years on the other side of the table before you become the PM.