The Kids Are Coding
An online coding-education product I founded and built across the public website, enrolment journey, learner experience and the software that keeps the programme running.
- Role
- Founder and product builder
- Status
- Ongoing
- Built with
- Next.js, Supabase, Vercel
The idea · The role
A programme became a product
The Kids Are Coding is an online coding-education programme I founded and run. I define the programme experience, customer journey, product requirements and business rules, then build and improve the systems that support them.
That role reaches well beyond a marketing website. It includes the public product, enrolment, lesson delivery, learner submissions, personal feedback, progress, quizzes, access, billing and the operational work around them.
I use AI-assisted development heavily. My responsibility is to specify how the product should behave, set the constraints, review the implementation, test it against real requirements and keep iterating when live use exposes a gap. Studying Software Engineering gives me theory; running the programme gives me somewhere real to apply it.
- Role
- Founder and product builder
- Product
- Online coding education
- Scope
- Public site, enrolment, LMS and operations
Dependency → friction → ownership
The workflow reached its limit
The first version depended heavily on messaging for communication and parts of the learner workflow. That was enough to begin, but lessons, submissions, progress and administration became too dependent on one external platform as the product grew.
The real problem was ownership of the critical workflow. The learning experience needed a home I could shape around the programme, with messaging kept as a useful communication channel instead of the place where the product itself lived.
The turning point was not a new visual design. It was deciding that the core learner journey had to live in a product I controlled.
- Messaging-heavy workflowUseful for starting, fragile as the operational centre
- Operational frictionLessons, submissions, progress and admin became harder to manage
- Owned learner productThe core experience moved into a dedicated platform
Website · explanation · conversion
A public product built for trust
The public website had to do more than look professional. It needed to explain the programme clearly, show families how the weekly experience works, make the available options understandable and turn interest into a confident next step.
Real questions from prospective parents shaped the messaging. I kept revising the explanation so the site answered the practical concerns that repeatedly appeared in conversations, while the interface used real product material instead of generic education imagery.
- Create a credible public home for the business.
- Explain programme options and the weekly learning rhythm.
- Make the path from marketing to enrolment clear on phones and larger screens.
- Use real conversations to improve the wording without claiming formal UX research.
One decision at a time
Turning interest into enrolment
A single long form would ask a family to understand every detail at once. I split the journey into a short sequence that starts with the programme choice, then gathers only the information needed for the next step.
The structure moves repetitive information collection out of chat, keeps each screen understandable and makes the next action visible. The supplied composition below uses approved empty fields and generic placeholders; it contains no customer data.
- Choose a programmeStart with the decision that shapes the rest
- About youCollect the parent or guardian details
- About your childGather the learner information
- Practical detailsAsk the remaining setup questions
- Enrolment receivedEnd with a clear confirmation and next action
From delivery workflow to product system
Moving the learner journey into an owned LMS
The dedicated learner system grew around the work the programme actually needed to do: give learners accounts, release lessons in a weekly rhythm, receive uploaded work, support personal feedback, record quizzes and progress, recognise achievements and help run the administrative side of the programme.
This was not a generic school-management system forced onto a coding programme. The product model follows the programme itself, and the admin features grew from real operational needs such as access and payment tracking.
- Learn
- Accounts, weekly lesson releases and structured content
- Submit
- Uploaded work, quizzes and progress
- Respond
- Personal feedback and achievements
- Operate
- Access, payment tracking, recurring billing and admin workflows
The human learning model
The software supports the coaching
Learners work at their own pace inside a structured weekly rhythm. They complete the work, submit what they built and receive feedback from me. The platform gives that process a reliable home and makes progression manageable; it does not replace the relationship at the centre of the service.
The software supports the coaching — it does not replace it.
- Lesson opensA structured weekly starting point
- Learner buildsWork happens at the learner's own pace
- Work is submittedThe platform keeps the evidence together
- William reviewsFeedback stays personal and human
- Progress continuesThe next step follows with context
Product model · stack · access
Architecture around the real domain
The product is built with Next.js, Supabase and Vercel. Supabase provides Postgres, authentication and Row Level Security. The useful architecture story is the boundary between the programme model, the business rules and the data operations behind it.
Business rules were increasingly separated from database input and output so important behaviour could be tested on its own before it touched the live system. Access restrictions are enforced on the server and backed by database security rather than relying on controls being hidden in the interface.
- Application
- Next.js on Vercel
- Data and identity
- Supabase Postgres and authentication
- Access
- Server-side rules backed by Row Level Security
- Programme / packageThe option a learner joins
- CourseThe structured learning path
- WeekThe release and progression rhythm
- ContentLessons, submissions, quizzes and feedback
From monthly admin to recurring logic
Billing became a rules problem
Moving from manual monthly administration toward recurring billing meant defining the business behaviour before encoding it. A convenient implementation is not enough when a rule affects access, payment history or financial reporting.
The result was a set of explicit invariants that could be reviewed and tested without exposing any customer amounts or private financial records.
- Deterministic dates
- A late payment must not move the next billing date.
- One period, one obligation
- The same billing period must not produce duplicates.
- Historical accuracy
- Existing obligations retain the amount that applied when they were created.
- Clean totals
- Test and demo records must not contaminate real figures.
- No invented policy
- Undefined business decisions stay explicit instead of becoming accidental code behaviour.
- Regression protection
- Critical access and payment behaviour remains covered as the system changes.
Production debugging
When green tests were not enough
One billing failure appeared only against the real database. The business-logic tests passed, but the database uniqueness rule did not behave with the live write path in the way I expected.
I corrected the database design, re-ran the checks and verified the behaviour against the live system. The important lesson was not the specific database mechanism; it was that a passing unit suite can validate my own logic while still missing an assumption at the integration boundary.
Green unit tests proved the business logic. Live verification exposed the database assumption they could not see.
Logic first · live verification after
Testing the paths that affect real operations
Dedicated automated tests covered finance logic, billing behaviour and database-security rules. Production-sensitive paths were then checked against the live system rather than treating the local test result as the finish line.
I have left exact test counts out of this draft because totals change and only help if they can be verified directly before publication. The stronger evidence is what the tests protect and how they are followed by integration checks.
- Finance
- Calculations and totals behave consistently.
- Billing
- Recurring obligations follow the stated business rules.
- Database security
- Row Level Security behaviour is tested instead of assumed.
- Live verification
- Production-sensitive paths are exercised at the integration boundary.
Live now · still evolving
What changed in practice
The public website and LMS launched, real learner and family onboarding took place, and the platform has been used in the day-to-day operation of the programme. The learner workflow moved into the dedicated product, while recurring billing and supporting admin logic reduced dependence on purely manual processes.
The Kids Are Coding remains an active product. Further onboarding refinement, richer in-portal interactions, certificates, privacy and compliance work, payment improvements and possible international expansion are future ideas rather than completed features.
- Live
- Public website and dedicated learner platform
- Used
- Real onboarding and programme operations
- Ongoing
- Product, learner experience and admin systems continue to evolve
What the work made clear
Lessons from running the product
The most useful lessons came from operating the programme, seeing where the workflow failed and changing both the product and the rules around it.
- Own the critical workflow instead of making the business depend on one external platform.
- Enforce access on the server and in the database, not by hiding controls in the interface.
- Treat integration and live verification as part of testing, even when unit tests are green.
- Make business policy explicit before turning it into software behaviour.
- Use software to reduce administration while protecting the human feedback that makes the service valuable.
Founder reflection
What I would change
If I rebuilt it today, I would take ownership of the core architecture much earlier.
The biggest lesson was how much operational risk comes from making a critical business workflow depend on a platform I do not control. If that platform goes down, changes its rules or I lose access to it, the business should still be able to operate.
I would still use external services where they make sense, but I would keep them at the edges rather than making one of them the place where the product itself lives. The learner experience, business rules, data model and core workflows should belong to a system I control, with the freedom to move or change the services underneath it.
That creates more responsibility, but it also gives me much more resilience and freedom to change how the product works. It is the same principle behind the turning point in this project: the core learner journey needed to live in a product I controlled.