I Reverse-Engineered a Learning Platform from My Resume

I looked at my resume and noticed something embarrassing. I have shipped production work with most of the tools listed on it. If you asked me to whiteboard half of them cold, I would hesitate.

That is the gap between having used something and being able to teach it. It is the gap between shipping and understanding. Most working developers carry it. Almost no one talks about it.

So I built BuildBot — a developer-education platform with twenty-two courses and one hundred runnable in-browser lessons, covering the exact stack I actually ship with. JavaScript, Node, Docker, Postgres, Laravel, Astro, Next.js. The whole resume. The platform is live at buildbot.cloud.

The point was never the platform. The platform is a side effect of a personal question: what would it look like to relearn my own resume on purpose?

The Gap Between Shipping and Understanding¶

A working developer accumulates a strange kind of debt. You learn a tool well enough to ship the thing in front of you. The deadline passes. The next thing arrives, in a different tool. Over years, your resume gets longer and the depth on any single line gets shallower. You are not less capable. You are more capable. But the model in your head of how each thing actually works gets fuzzier underneath.

Most people cope by trusting that they can rebuild the model on demand, because they have done it before. That is true, right up until the interview where someone wants to hear you explain it cleanly. Or the architecture decision where you cannot justify a choice past instinct. Or the moment a junior asks a basic question and you realize the answer was clear once and is not now.

The gap is not a knowledge gap. It is a teaching gap. There is a real difference between knowing a thing and being able to take someone through it. The first is enough to ship. The second is what tells you whether you actually understand it.

Resume as Curriculum¶

The discipline I gave myself was simple. Open my resume. For every tool, framework, runtime, and language that appears on it, design a short course I would have wanted before I started using it professionally. Not a tutorial. Not a reference. A course that builds the mental model, then makes you run code that exercises it.

What came out was a curriculum that no bootcamp could have given me, because a bootcamp does not have my resume. It only has the consensus stack of the year it was designed. My stack is a working developer's actual stack — the tools I picked up because real projects demanded them, in the order projects demanded them. Docker because containers landed in deployment. Postgres because every serious system eventually needs a real database. Laravel because a contract used it. Astro because a content site needed something simpler than Next. Next.js App Router because that is where my own platforms now live.

Reverse-engineering the curriculum from my own work gave each course a quality that prescribed curricula rarely have. Every lesson exists because I have used the thing it teaches under deadline pressure. Every code challenge runs the kind of code I have actually written in anger. The relevance test is built in.

Building It With AI on Weekends¶

I am not going to pretend I hand-wrote every line of every lesson. I designed the platform, picked the topics from my own gaps, and shipped the whole thing fast because that is what AI lets one person do now. I worked on it on weekends, in the cracks of the rest of my work, with Claude and Cursor as constant collaborators.

What surprised me is what the process taught me about my own gaps. Writing a lesson with AI is not dictation. The model produces a draft. You read it. You notice the parts that feel hand-wavey and ask follow-up questions to sharpen them. The places where you cannot tell whether the draft is right or wrong are the exact places your own mental model is soft. You cannot fake your way through teaching, even to yourself.

By the end of any given course, the lesson I actually learned was almost never the one I set out to write. The platform became a mirror. It showed me where I knew the topic well enough to teach it confidently, and where I had been operating on muscle memory for years.

Runnable Beats Read-Only¶

The single design decision that mattered most was making every lesson runnable in the browser, with no setup. You read a paragraph, then you edit the code below it, then you see what happens. The editor is right there. The sandbox is already warm. There is no install, no environment configuration, no clone-the-repo step that loses half your would-be students at the front door.

The friction of getting from "I want to try this" to "I am trying this" is what kills most learning. Removing that friction is not a feature. It is the whole product.

When the cost of trying something drops to zero, you experiment more. When you experiment more, the mental model gets stronger. That is the bet underneath every runnable lesson on BuildBot, and the bet underneath what I now think a relearning platform actually has to do.

Who This Is For¶

BuildBot is not aimed at people who have never written code. There are good resources for that already. It is aimed at the version of me that wrote the original resume — a working developer who has used these tools in production, knows they could explain them on a good day, and has caught themselves hedging on a bad one.

If you have shipped with the stack and you want a place to refresh the parts that have gone soft, the platform is open. If you are the version of me that needed this two years ago, that is who I built it for.

What This Says About How I Work¶

I include this here because anyone reading this on my personal site is likely doing recruiter math in the back of their head, and I would rather make the math easy.

BuildBot is a small example of what a single operator can ship in 2026 by treating AI as cognitive infrastructure rather than as a feature to bolt on. The full platform — Next.js 16, Convex, Clerk, Sandpack, Tailwind 4, content as MDX, in-browser sandboxes — went from idea to live in weekends. That is not a flex about speed. It is a fact about what is now possible when an experienced builder pairs deeply with the tools.

I run webfaCeMEdia full-time. I have shipped multi-tenant platform infrastructure, an MCP server that exposes a portfolio of client systems to AI clients with tenant isolation enforced server-side, a mobile companion app, and an analytics platform that powers the whole thing. BuildBot is the public, demonstrable slice. The rest of the work I do for clients is private by nature. The way I built BuildBot is the way I build everything — start from a real problem, design the capability before the interface, ship the capability fast, then learn from what shipping it reveals.

If that pattern is useful to you — whether as a hire, a contractor, or someone building something where the same operating model would help — my contact page is open.

What I Took Away¶

Three things, in case any of them is useful to you.

• Your resume is a curriculum waiting to be designed. The list of things you have shipped is also the list of things you most likely owe yourself a clean refresh on. If you cannot teach it, you have not finished learning it.
• AI works best as a teaching partner when you bring real intent to it. Asking it to summarize a topic produces summaries. Asking it to help you teach a topic — anticipating the questions someone would ask, drafting code challenges that fail in instructive ways — produces understanding.
• Runnable beats read-only. Anything you can do in your browser with one click, you will try. Anything that requires you to clone, configure, and install, you will not. The shape of the learning is downstream of the shape of the friction.

BuildBot is at buildbot.cloud. Twenty-two courses. One hundred runnable lessons. Start anywhere on the stack you already ship with, and refresh the parts you have been hedging on.