Ide tweet · Build in public
Building in public works when people can follow a story: what you're making, what changed this week, what went wrong, and what you're deciding next. It stops working when every post is a revenue screenshot or a vague "grinding" update. The best updates are small, specific and regular.
Semua tweet di halaman ini orisinal, ditulis untuk kamu posting atau sesuaikan. Tanda kurung siku menandai bagian yang perlu kamu isi.
These templates are grouped by the kinds of posts that keep a build log interesting: updates, numbers, mistakes, decisions you haven't made yet, and behind the scenes. Use your real figures in [MRR], [users] and [number]. If a number is embarrassing, post it anyway; those are the posts people remember.
Week [number] of building [your product]: - shipped [feature] - talked to [number] users - [number] new signups - one bug I'm still chasing
Monthly update. MRR: [MRR]. Users: [users]. Best thing that happened: [event]. Worst: [event].
This week I mostly fixed things nobody will notice. Login is faster, emails stop landing in spam. Not exciting. Necessary.
Shipped [feature] on Tuesday, rolled it back on Wednesday, shipped it properly on Friday. That's the week.
Month [number] on [your product]. Still small. Still growing. Still the most fun I've had at work.
Update: [number] people used [your product] this week. Last week it was [number]. I'll take it.
Short week. Built nothing, talked to [number] customers, and learned more than in the last month of coding.
end of week [number]. one feature, two bug fixes, zero new customers. building anyway
Quarter recap for [your product]: started at [MRR], ended at [MRR]. Biggest lever was [thing], not the features I spent most time on.
Weekly update, in one sentence: I finally understand why people cancel, and it's [reason].
This month's goal was [goal]. Got to [result]. Missed it, and here's what I'm changing: [change].
Day [number] of building [your product] every day. Today: [small concrete thing].
[your product] just crossed [MRR] MRR. That covers [cost it covers, e.g. hosting and coffee]. Next stop: [target].
Real numbers for [your product], month [number]: Revenue: [amount] Costs: [amount] Profit: [amount] Hours: too many
First $100 month. Took [number] months. Most of that time was finding out who actually needed this.
Churn this month: [number] customers. Two left for a competitor, one stopped needing it. Emailed all three.
My conversion rate from free to paid is [rate]. I have no idea if that's good. Founders with similar products, what's yours?
Revenue went down this month. From [MRR] to [MRR]. Cause: [reason]. Posting it because the up months were public too.
Where my [number] users came from: - replies on here: [share] - search: [share] - word of mouth: [share] - launch: the rest
Raised prices from [old price] to [new price]. Signups dipped a little, revenue went up. Should have done it months ago.
[your product] costs me [amount] a month to run. Here's the breakdown: [list]. Cheaper than I feared.
One customer is [share] of my revenue. That's a risk I'm working on this quarter.
Took [your product] down for [time] today with a one-line change. Wrote a test for it. Then wrote an apology email.
Mistake I made: built [feature] for three weeks without asking a single user if they wanted it. Nobody did.
Lost a customer today because of [specific issue]. Fixed it an hour later. Too late for them, in time for the next one.
I spent [amount] on ads last month. Result: [number] signups, [number] paid. Not doing that again soon.
Shipped a pricing page with the wrong currency for [number] days. Two people noticed. Both were kind about it.
Things I'd skip if I started [your product] again: - custom auth - [thing] - the logo redesign
Deleted [number] lines of code today. It was a feature I was sure people would love. Usage said otherwise.
My worst week as a founder was when [event]. What I learned: [lesson].
The bug that cost me the most customers wasn't a crash. It was a confusing button label. Fixed in one word.
I waited [number] months to launch because it "wasn't ready". The first users asked for none of what I'd been polishing.
Trying to decide: build [feature A] or [feature B] next. [A] is what users ask for, [B] is what I think they need. Thoughts?
Should [your product] have a free plan? Arguments for: [reason]. Against: [reason]. Leaning toward [choice].
Thinking of raising the price from [price] to [price]. What would make it obviously worth it to you?
I could spend this month on growth or on fixing onboarding. Onboarding loses [share] of signups. Probably that.
Considering going full-time on [your product]. Revenue is at [MRR]. My number to quit is [MRR]. Not there yet.
Two customers asked for [feature] this week. It would take a month. Asking the rest of you: would you use it?
Naming question. Is [name A] or [name B] clearer for a tool that [does job]? Be blunt.
Thinking out loud: I could add [integration], or say no and keep the product simple. Saying no is harder than it sounds.
Option 1: rewrite [part] properly. Option 2: patch it and ship features. I've chosen option 2 three times. Time for option 1?
Deciding whether to keep doing [channel]. It brings [number] signups a month for [hours] of work. Worth it or not?
My entire stack for [your product]: [stack]. Boring on purpose. Boring means I sleep.
What a support day looks like: [number] emails, [number] of them the same question. Rewriting the docs tonight.
Here's the spreadsheet I use to track [your product]. Five columns. That's all I check every morning.
The most-read page on my site isn't the homepage. It's [page]. Rethinking the homepage now.
Behind the scenes of today's feature: [number] hours of building, [number] hours of naming the button.
A user emailed me a [number]-step workaround they built for a missing feature. Building the feature this week, with their name in the changelog.
My routine: code in the morning, customers after lunch, posting here in the evening. Some weeks it holds.
What I check first every morning: [metric]. What I've stopped checking: [metric]. Much calmer.
Mau yang sesuai gaya kamu sendiri?
ReplyKit menulis draf posting dan balasan di X dari topik dan gaya menulismu sendiri. Buka kolom tulis yang kosong dan ia menyarankan tiga posting; di bawah posting mana pun ia menulis tiga balasan. Tombol Posting selalu kamu sendiri yang tekan.
Tambahkan ke Chrome, gratis