At some point, almost every developer thinks about building an audience. Maybe you want to sell something. Maybe you want to attract better job offers. Maybe you just want people to read what you write instead of shouting into the void. We've been there — Stefan started writing on Twitter with zero followers and felt like he was live-tweeting to his mom, and only his mom, and she doesn't even have an account.
So we've experimented with all three: Twitter (fine, X, but we're not calling it that), a blog, and a newsletter. Here's an honest breakdown of what each channel is actually good for, what the failure modes look like, and how to think about where to put your limited time.
The Core Problem With Audience Building
Most developer content fails not because it's bad — it fails because it's generic. 'How to use useState in React' has been written ten thousand times. Nobody needs an eleventh. The audience-building game rewards specificity and consistency, in that order. Specific content that helps a particular kind of person solve a particular kind of problem will always outperform broad content written for everyone.
Before picking a channel, you need to answer one question: what do you know that a specific group of people would pay attention to? Not 'I know JavaScript' — everyone knows JavaScript. More like 'I've shipped three SaaS apps with Next.js and Stripe and I keep making the same billing mistakes, and so does everyone else.' That's a thread. That's a blog post. That's a newsletter issue.
Specificity is the only moat available to individual developers. You can't out-SEO Google or out-budget a VC-backed content team. But you can be the most useful person in a narrow lane.
Twitter: Fast Feedback, Short Memory
Twitter is the fastest feedback loop in developer content. You write something, post it, and within 24 hours you know if it resonated. For developers specifically, it's still the place where actual practitioners hang out — not LinkedIn, where everyone's performing professionalism at each other.
What works on Twitter for developers: threads with concrete code examples, hot takes that have actual reasoning behind them, and replies to other people's posts where you genuinely add something. The accounts that grow fast are usually either very funny or very useful. Ideally both.
What doesn't work: vague motivational stuff ('shipping beats perfection!'), posting links to your blog with no context, and trying to go viral by dunking on frameworks. The dunking might get impressions but it doesn't build a following that cares about your actual work.
The brutal truth about Twitter: the half-life of a tweet is about 6 hours. You write something, it gets some traction, and two days later it might as well not exist. This means you're constantly on the content treadmill. That's fine if you enjoy the format. It's exhausting if you don't.
- Good for: quick tips, live reaction to things (shipping, bugs, discoveries), building relationships with other developers
- Bad for: long-form explanations, anything that needs more than 10 tweets to explain properly
- Growth speed: fastest of the three channels if you're consistent
- Ownership: zero — the algorithm changes, your account can get suspended, reach can crater overnight
- Time commitment: high, because consistency is everything and once-a-week doesn't cut it
Blog: Slow Burn, Long Tail
A blog is the opposite of Twitter in almost every way. Growth is slow — embarrassingly slow at first. We published our first twenty posts on peal.dev's blog to basically no organic traffic. Then month four happened and something clicked with search engines and the numbers started moving. The content you write today might bring you readers two years from now.
The key is writing things that answer real questions people are actively searching for. Not just what you want to write about — what your target reader types into Google at 11pm when something is broken. Those posts compound. A Twitter thread is a spark; a blog post is a slow-release capsule.
SEO matters more than people admit. You don't need to be an SEO wizard, but you do need to understand that the title, structure, and specificity of what you write affects whether anyone finds it organically. A post titled 'Stripe Webhooks' gets buried. A post titled 'Why Your Stripe Webhooks Are Failing in Next.js App Router (And How to Fix It)' has a fighting chance.
// Example: a good blog post teaches something specific and copy-paste useful.
// This is the kind of code that earns backlinks and bookmarks.
// Bad blog post code:
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)
// just use stripe
// Good blog post code — shows the actual gotcha:
export async function POST(req: Request) {
// You MUST use req.text() here, not req.json()
// Stripe signature validation requires the raw body.
// If you parse JSON first, the signature will always fail.
const body = await req.text()
const signature = req.headers.get('stripe-signature')
if (!signature) {
return new Response('Missing signature', { status: 400 })
}
let event: Stripe.Event
try {
event = stripe.webhooks.constructEvent(
body,
signature,
process.env.STRIPE_WEBHOOK_SECRET!
)
} catch (err) {
console.error('Webhook signature verification failed:', err)
return new Response('Invalid signature', { status: 400 })
}
// Handle your event types here
switch (event.type) {
case 'checkout.session.completed':
// ...
break
}
return new Response('OK', { status: 200 })
}The code above is the kind of thing that earns a bookmark. Not because it's impressive — because it saves someone an hour of debugging. That's what good blog content does. It makes the reader feel like you've solved their specific problem.
- Good for: SEO-driven traffic, long-form tutorials, establishing credibility in a niche
- Bad for: real-time discussion, anything time-sensitive, building personal relationships
- Growth speed: slowest of the three, but the most durable
- Ownership: high — you own the domain, the content, the backlinks
- Time commitment: medium — one solid post a week beats five rushed ones
Newsletter: The Highest-Value Channel Nobody Uses Right
An email subscriber is worth dramatically more than a Twitter follower or a blog reader. They invited you into their inbox. They gave you their email address — something they guard more than their Twitter account. The conversion rate from newsletter to paid product is 10-50x higher than from social media, depending on who you ask and how they're measuring.
The problem is that newsletters are hard to grow from zero. Unlike Twitter (where retweets can spike your following overnight) or a blog (where Google can send you traffic), newsletters grow almost entirely through word of mouth and cross-promotion. Your subscriber count goes up when you write something so good people forward it to a friend and that friend subscribes.
The developers we've seen build great newsletters treat each issue like a mini blog post — not a roundup of links, not a summary of what they tweeted this week, but an actual argument or tutorial that teaches one specific thing. Beehiiv and Resend make the technical side trivially easy now. The hard part is the content, same as it's always been.
// If you're building a newsletter signup flow in Next.js,
// here's a simple server action that actually handles errors properly:
'use server'
import { z } from 'zod'
const EmailSchema = z.object({
email: z.string().email('Please enter a valid email'),
})
export async function subscribeToNewsletter(formData: FormData) {
const result = EmailSchema.safeParse({
email: formData.get('email'),
})
if (!result.success) {
return { success: false, error: result.error.errors[0].message }
}
const { email } = result.data
try {
// Example with Beehiiv API
const response = await fetch(
`https://api.beehiiv.com/v2/publications/${process.env.BEEHIIV_PUB_ID}/subscriptions`,
{
method: 'POST',
headers: {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.BEEHIIV_API_KEY}`,
},
body: JSON.stringify({
email,
reactivate_existing: false,
send_welcome_email: true,
}),
}
)
if (!response.ok) {
throw new Error('Subscription failed')
}
return { success: true }
} catch (error) {
console.error('Newsletter subscription error:', error)
return { success: false, error: 'Something went wrong. Try again.' }
}
}- Good for: direct relationship with readers, selling products, highest conversion rates
- Bad for: discoverability — nobody stumbles on a newsletter the way they stumble on a tweet
- Growth speed: slowest to start, but accelerates with every quality issue
- Ownership: the highest — your list is yours, no algorithm can take it away
- Time commitment: medium-high, because consistency matters and a bad issue can spike unsubscribes
How to Actually Think About This Decision
The honest answer is that you probably want all three eventually, but you shouldn't try to run all three from day one. That's how you end up doing all of them badly and burning out by month two. Pick one, do it consistently for six months, then expand.
If you're starting from absolute zero with no audience anywhere: start with Twitter or a blog, not a newsletter. A newsletter is hard to grow without existing distribution. Use Twitter to find your voice fast (you'll know within weeks what resonates), or use a blog if you prefer writing longer-form and are willing to wait for SEO to kick in.
If you have any audience at all — even 500 Twitter followers who are the right people — start capturing emails immediately. The cost of not doing it is invisible until you try to sell something and realize your social following converts at 0.3%.
There's also a strategic ordering that tends to work well: blog post → Twitter thread summarizing the key insight → newsletter issue diving deeper. You create the content once and repurpose it across channels with different depth levels. The blog drives SEO, the Twitter thread drives discovery, the newsletter drives conversion. This is roughly what we do for peal.dev — the templates give us concrete things to write about, and writing about them helps developers find the templates.
The Mistakes People Make (Including Us)
Mistake one: writing for other developers instead of for your target customer. If you're building a SaaS for restaurant owners, tweeting about TypeScript generics doesn't build the right audience. It might feel productive, but it's not.
Mistake two: inconsistency followed by guilt-driven bursts. Going quiet for three months and then posting ten times in one week is the worst pattern. Your audience doesn't track your publishing schedule — they track yours. Quiet for a week is fine. Quiet for a month means you're starting over.
Mistake three: optimizing for virality instead of usefulness. The tweet that gets 500 retweets and attracts people who aren't your target audience is less valuable than the tweet that gets 20 retweets from exactly the people you want to reach. Big numbers feel good. Right numbers matter.
Mistake four: waiting until you have something 'worth saying.' If you've been writing code for more than two years, you have ten blog posts in your head right now. The thing you debugged last week. The package you almost used but decided against. The architectural decision you regret. All of it is content. Write it down before you forget.
# A content idea framework we actually use:
## 'I just learned that...' posts
Write immediately after learning something that surprised you.
The confusion is still fresh — you'll explain it better now than in 6 months.
## 'I got this wrong and here's what actually works' posts
Your mistakes are your most valuable content.
People search for error messages, not success stories.
## 'Here's exactly how I built X' posts
Walk through a real implementation with real code.
No 'simplified for clarity' garbage — the actual thing.
## 'Why I chose X over Y for Z' posts
Opinionated comparisons with specific context.
Not 'React vs Vue' — 'Why I switched from React Query to server actions
for a specific kind of real-time dashboard'
## 'The thing nobody tells you about X' posts
The gap between documentation and production reality.
This is where your actual experience lives.What We'd Actually Do If Starting Over
Start a blog on a domain you own. Write one post per week. Each post should solve a specific problem you actually encountered — not a hypothetical one. Set up a newsletter from day one, even if you only send it monthly. Capture every email you can.
On Twitter, post a thread version of each blog post within 24 hours of publishing. Engage with replies. Reply to other developers' posts when you have something real to add. Don't chase viral moments — they're random and they usually attract the wrong people anyway.
After six months, look at what's working. Where is your traffic actually coming from? Which posts got shared? Which newsletter issues got replies? Double down on that. The data tells you what your audience wants better than your intuition does.
For the technical side of running a blog: if you're a Next.js developer, building your own blog is genuinely a good idea — you learn a lot and you own the stack completely. Our templates at peal.dev include a blog-ready setup with MDX support, RSS feed, and SEO metadata handling baked in, which cuts out most of the boring setup work so you can focus on actually writing.
The best audience-building strategy is the one you'll actually stick with for 12 months. Pick the channel that matches how you naturally communicate, not the one that seems most strategic on paper.
Building an audience takes longer than you think and compounds faster than you expect. The developers who succeed at this aren't usually the most talented or the best writers — they're the ones who showed up consistently, wrote specifically, and treated their readers' time as something worth respecting. Start boring. Stay consistent. Get specific. That's genuinely it.