Case study: CodeFlash, a learning product from idea to operation

CodeFlash is a product owned by Lechner Studios, not a client commission. We describe it here because it answers the question a portfolio alone cannot: can we not only design a product, but build it, put it into operation and keep it running? Everything that follows can be checked in the running product and its source code.

The problem

Technical knowledge sticks when it is recalled, not when it is read. Developers and career changers learn between projects, in short sessions, often on a phone. What was missing was a tool with curated card sets on specific topics, a schedule for the gap between repetitions, and an interface that works in German and in English.

Our role

Concept, design, development, payments and operation all come from the studio. The product has been live at codeflash.lechner-studios.at since 2026.

What works

• Card sets across eight fields, from web and backend through cloud and security to data. The landing page reads the number of topics, packs and cards live from the database.
• Learning with spaced repetition on the SM-2 schedule, plus a quiz mode. Progress is kept on the account.
• Bilingual, German and English, in one interface.
• The foundation packs are free; further packs are bought through Stripe.
• Purchased packs can be downloaded as a self-contained HTML file and used without a connection.
• Three brands from one codebase: CodeFlash, AI Flash and Mainframe Flash are selected at build time and share the learning engine, accounts and payments.

Decisions that shape the operation

• A static web app on Vercel; data and sign-in live in Supabase. There is no server of our own to maintain.
• Payments run through Stripe. The confirmation of a payment arrives as a webhook at a Supabase function, not in the app. The payment path stays reachable even while the interface is in maintenance mode.
• The gate in front of paid content fails closed: if the build cannot determine which packs are free, it ships no pack content at all.
• Card sets are drafted with the help of a language model and checked before release.

Maintenance

• Every pull request runs lint, build and tests, plus a privacy scan, a guard against oversized files and a check of dependencies for known vulnerabilities.
• Every Monday, three automated runs probe the live product: does the main branch build, is payment active in the shipped bundle, are there empty card packs? A failed run opens a ticket in the repository.
• A maintenance mode is documented and can be switched on with a single pull request. The payment path is unaffected by it.
• Changes are recorded in a changelog.

What you can check yourself

The landing page shows the current catalogue figures. The free foundation packs can be tried. The sample cards above come from the product.

What this means for your project

Consider a driving school that wants to offer its theory material as flashcards with progress tracking and payment. The building blocks are the same as above: accounts, content, learning logic, payments, operation. What changes is the content and the brand. How we build applications like this is described under Apps & Automation. The first conversation is free of obligation.