VisNavigans Admin
Three years ago I was a senior developer who wanted to teach online. I had the skills. I had the experience. I had zero audience. Here's what worked, what didn't, and what I'd do differently if I were starting today.
The audience myth
The myth: you need a big audience first, then you can sell courses / books / coaching. Reality: you don't need a big audience. You need the right kind of small one.
A thousand people who care about your specific topic and trust you is worth more than 50,000 followers you collected by posting trendy hot takes. The commerce happens on trust × relevance, not raw reach.
Where I wasted time
Writing for every platform
Year one I tried Twitter, LinkedIn, Dev.to, Medium, YouTube, Instagram. I wrote variations of the same content for each. Result: mediocre presence everywhere, traction nowhere. Platform-specific mediocrity compounds to nothing.
What I do now: pick ONE platform where your audience actually hangs out and go deep. For teaching technical topics, that's Twitter + LinkedIn for short-form, a newsletter + YouTube for long-form. Ignore the rest.
Chasing trends
Year one I wrote about whatever was trending. "AI will change coding". "Web3 primer". "Rust vs Go". Most of it was superficial because I wasn't an expert on any of it — I was just chasing search volume.
What I do now: write about what I actually know deeply. The specificity is the moat. "How I migrated a 500k LOC monolith to modular architecture" gets 1/10th the traffic of "5 tips for better code" but 10x the business value — because the people who read it are my actual customers.
Optimising for likes
Engagement metrics lie. A post with 500 likes and 5 replies feels great; a post with 50 likes and 20 detailed replies is 10x better for business. Replies mean people cared enough to type, which is the behaviour correlated with eventually buying.
What I do now: I track email signups and DM conversations, not likes. When a post drives 30 signups, I write more of that. When a post gets 2000 likes and 0 signups, I write less.
What actually worked
Writing the "bad takes" people have in private
Every technical community has things people mutter to colleagues but don't say publicly. "Microservices are mostly a net negative". "Most startups should use Django and SQLite". "Kubernetes is the wrong choice for 80% of teams using it". If you have a well-considered contrarian view, publishing it attracts attention because nobody else is saying it.
The catch: you have to have actually earned the take. If you argue against microservices and someone asks "have you run a monolith at scale?" you need to have an answer. Otherwise your take reads as ignorance, not insight.
Publishing weekly for 18 months
Consistency over brilliance. One decent post every week for 80 weeks is a library. One amazing post a month for 18 months is a pamphlet. The first one compounds because readers learn your schedule, your voice, your topics. Serendipitous discovery requires a body of work.
I wrote weekly on Sundays. Some posts bombed. Some went mildly viral. The cumulative effect was growing to 15k engaged followers who read everything — not because I wrote brilliantly, but because I wrote reliably.
Long-form over short-form
Short-form gets likes. Long-form gets customers. A 15-tweet thread might get 5000 likes and no one remembers who wrote it. A 2500-word essay gets 400 views and 10 of them email you asking to book a session.
I pivoted to mostly newsletter after year one. 300 subscribers became 800 became 3000. Each newsletter landed in a specific inbox with my name on it. Monthly revenue started tracking the newsletter number, not the follower number.
Generous, specific, replicable advice
Not "work hard". Not "be consistent". Specific, named, replicable. "Use the Pomodoro technique like this. Schedule reviews on day 1, 7, 30. Never write a first draft longer than 1000 words." Concrete tactics people can copy.
When you give advice that someone tries, notices works, and attributes back to you, you've created a trust relationship that commerce follows. Vague inspiration doesn't do this. Named tactics do.
Respond to every email for the first 2 years
Before I had volume to worry about, every email back-and-forth mattered. 80% of my first 20 paying clients came from email threads that started with "I read your piece on X and have a question". If I'd replied with a template, I'd have lost every one.
Once volume becomes real (500+ emails/month), you'll have to template. But start by treating every message like it might be the next year's biggest client.
What I'd do starting today
Pick one narrow topic
Not "software engineering". "Backend performance optimization for teams under 50 people". The narrower the positioning, the faster the resonance.
Pick one platform and one format
My recommendation for most technical teachers: a weekly newsletter + a Twitter/LinkedIn account that mostly exists to funnel to the newsletter. Everything else is optional.
Commit for 18 months minimum
Before you start, decide you'll write weekly for 18 months regardless of traction. Month 3 will be lonely. Month 9 will still be lonely. Month 15 compounding starts to kick in. Stop before then and you've wasted the effort.
Build an email list early
Social follows are rented. Email subscribers are yours. The day Twitter or LinkedIn changes their algorithm, your reach can halve. Email is stable. Drive everything toward email capture.
Launch something small immediately
Don't wait until you have "enough audience" to sell. Launch a $30 PDF at month 2 to 50 followers. Learn what people pay for. Iterate the product faster than the audience. A tiny product informs everything you write afterward.
The slow compounding
Year 1 — 200 subscribers, $0 revenue. Year 2 — 1000 subscribers, $5k revenue. Year 3 — 4000 subscribers, $50k revenue. Year 4 — 12,000 subscribers, $200k revenue. The curve is real, ugly flat, then hockey stick. You have to survive the flat part.
Most people quit at month 6. The returns go to the people who don't.
