Ideias de tweets · 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.
Todos os tweets desta página são originais, escritos para você postar ou adaptar. Os colchetes marcam as partes a preencher.
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.
Quer um com a sua própria voz?
O ReplyKit escreve posts e respostas no X a partir dos seus temas e do seu estilo de escrita. Abra uma caixa de texto vazia e ele sugere três posts; embaixo de qualquer post, ele escreve três respostas. Quem clica em Postar é sempre você.
Adicionar ao Chrome, grátis