Devlify AII started out the way a lot of developers in Gusau do - building whatever paid: school websites, small business storefronts, the occasional production system for a local company. Client work is a good teacher, but it's a lonely one. You solve a hard problem, ship it, and move to the next client without ever writing down what you learned.
The first video wasn't supposed to be a course
It started as a screen recording to explain a bug fix to a client. Posting a cleaned-up version of that same explanation publicly got more engagement than I expected, and it became clear that a lot of developers were stuck on the exact problems I'd already solved three or four times for different clients - school management systems, REST APIs, the freelancing logistics nobody teaches in school.
Teaching made the client work better
The unexpected part wasn't the audience, it was what teaching did to my own code. Explaining a decision out loud - why this folder structure, why this auth flow - forced me to justify choices I'd been making on autopilot. Some of them didn't hold up to explanation, and I'd go fix the pattern before the video even went out. My client projects got more consistent once I was documenting them for an audience, not just for myself.
Running both at once
The honest answer to "how do you balance it" is that I don't split time evenly - client work pays the bills and gets priority, and teaching happens in the space around it: recording during a lull between projects, turning a solved client problem into a course module once the client-specific details are stripped out. It's slower than treating either as a full-time thing, but it means neither one goes stale.
If you're a developer sitting on a few years of client work and wondering whether it's worth teaching: the market doesn't need more polished courses from people who've only ever built toy projects. It needs the version of the lesson that includes what broke in production.