Courselet: Idea to App in a Week

In a previous blog post, we laid out an AI development flow: agents do the building, humans do the deciding. A flow on paper is worth nothing until it survives a real project, and we did not want its first test to be on a client, so the first run was on a project of our own.

The excuse was a real one. One of our clients was paying for a third-party service to embed a micro-course inside an app we had built for them. A course builder of our own was a good starting point, and could potentially replace that paid service down the line. A real product with a real reason to exist, but no client waiting on it.

Honestly, we went in a bit sceptical. AI development has not exactly been consistent in the past. But we were excited to see what we could actually get out of it.

The short version: it worked. Courselet went from a rough plan to a functioning, scalable app in about a week, and the run went well enough that the next project we pointed the flow at was a real client with a real deadline. This post is about what that first run was like.

What we built

Courselet is a card-based micro-course builder. It sits in the gap between a slide deck and a learning management system. An LMS is heavy: accounts, enrolment, dashboards. A slide deck just sits there. Courselet’s bet is that a lot of knowledge sharing wants what sits between the two. A coach’s method, an onboarding explainer, a short briefing: a tap-through sequence of cards with a bit of quizzing, shared as a link, finished in one sitting on a phone.

A creator signs up, builds a course of lesson and quiz cards in a split-screen editor, previews it exactly as a learner will see it, and publishes it to a clean public link. Learners open the link, tap through, answer quizzes with instant feedback, and hit a completion screen. No account, no app, no personal learner data collected.

Stack: Next.js and TypeScript on Supabase, deployed to Cloudflare Workers via OpenNext, with the brand built as a token system down to the signature progress bar, where each pill is literally one card of the course.

What running it was actually like

The flow starts with documents: requirements, brand, journeys, page specs and a clickable prototype, drafted by AI, reviewed, then locked. If something was not written down, agents flagged the gap instead of guessing. Then the agents built, in parallel, everything through pull requests.

My day was not what you might picture. I was not watching code stream past. I was managing agents: making sure none of them was sitting on a blocker, testing what they put out, and, honestly, working on a separate project at the same time. Most of the job was checking in every so often, unblocking someone, and trying what had just landed.

The moment it clicked was when the frontend came up and connected. Suddenly I could click through the actual product and see how everything fitted together. Up to then it was all tickets and pull requests.

Not everything was smooth

Two things are worth telling on ourselves, because they are the kind of thing you only find by running a flow for real.

We put an AI review agent into Git to review and approve every pull request, and it quietly became the pace of the project. Twenty minutes waiting for a review, twenty minutes dealing with the feedback, another twenty waiting for it to check the fixes, on every PR, eating Git tokens the whole way. The comments were detailed and read like a thorough senior reviewer, and it did catch some real problems, but everything it caught could have been caught by the same review run locally, without the loop and without the bill. We pulled it out before the end. A review that looks thorough and a review you actually needed are two different things.

And left to make its own calls, the AI over-built. At one point it tried to set up a whole admin dashboard, and it wired in an external error-tracking service that chewed through our Cloudflare allowance, for an MVP that needed neither. Nothing it built was wrong exactly, just sized for a product ten times bigger. It takes a human in the loop to keep saying: smaller.

Neither of those dented the result. They tuned the flow, which is exactly what a first run is for.

What the test could not test

An internal project has no client. Nobody pushing back, nobody using it under real conditions, no deadline that is not self-imposed. When the software was done, the thing Courselet needed most was users: proper UAT, real people clicking through it and telling us what works.

That was the one box this run could not tick, and it is exactly what the next run had: a real client, live UAT sessions, a deadline and a full handover at the end.

Where it landed

Courselet exists, it works, and it is built to scale. The flow that produced it went on to a client project two weeks later, which is the strongest thing we can say about the test: we trusted the result enough to bet a client engagement on it.

If I ran it again I would keep the shape and trim the weight. For a project this size I would strip the requirements down and focus almost entirely on usability. But that is tuning. As a first run, it did its job: it proved the flow, produced a real product, and meant the client project started with everything this one had already learned.

The lesson is not that software engineers are no longer needed. They are, as much as ever: someone still has to make the calls, set the boundaries, and tell good from good enough. What has changed is the velocity. The same engineers now get from an idea to a working, shippable product in a fraction of the time it used to take.