How to Build in Public Without Faking Revenue Numbers

Last month I saw a founder post a Stripe dashboard screenshot claiming $47K MRR. The comments were fire emojis, "congrats king," the usual. Two days later, someone found the same screenshot on a stock photo site. Different name, same numbers. The account went private within hours. We've written about lessons learned building multiple SaaS products — and none of those lessons involved faking screenshots.

Here's the thing. That founder had a real product. Real users. Probably some actual revenue. But the pressure to perform "build in public" the way Twitter rewards it — hockey-stick charts, monthly MRR milestones, "[Month] was our biggest month ever" — pushed them into fabrication.

I run a multi-product studio. Eight active SaaS products. How they're doing financially? I'm not telling you. Not because it's impressive — most of them are still early — but because it's not the point. The build-in-public movement has confused transparency with revenue theater. That confusion? It's killing the thing that made it valuable in the first place.

(Also: I'm genuinely bad at the screenshot game. My Stripe dashboard looks like a Jackson Pollock painting of test transactions and reversed charges. Not exactly engagement bait.)

The Revenue Screenshot Industrial Complex

Look around the indie hacker space right now. Scroll #buildinpublic on Twitter. What do you see?

Revenue screenshots. MRR milestones. ARR celebrations. The same "How I went from $0 to $10K MRR in 6 months" thread format, over and over, that conveniently skips the part where the founder had a $200K runway from their previous exit or a spouse with a BigTech salary covering rent. I've stopped counting how many of these I've seen. Dozens? Hundreds? They blur together after a while, and I think that's the point — the format is more memorable than any individual post.

Performance. Not transparency. Big difference.

The Pieter Levels model worked because he shipped real products (PhotoAI, RemoteOK, NomadList) and shared real decisions — infrastructure costs, failed experiments, the honest operational chaos of running multiple things. Marc Lou does the same. Actual products. Actual numbers. But also actual failures and pivots. The followers came because the content was useful, not because the screenshots were impressive. We take a similar approach at VDL — shipping products like VeloCards and VeloCalls while documenting the process.

But the second-wave build-in-public crowd learned the wrong lesson. They saw "share revenue" and heard "revenue is the content." Now we've got founders posting numbers they can't back up, screenshots from test Stripe accounts, "MRR" that's actually a one-time payment from a friend.

The audience isn't dumb. They notice when someone's "growth" doesn't match their product's actual traction. They notice when the same founders keep posting milestones but never show the product. They've stopped trusting the screenshots.

Can you blame them? I can't.

That skepticism is spreading to founders who are actually being honest. Frustrating doesn't cover it. I've had people assume our product announcements are vaporware because so many others are. Someone DM'd me last month asking if ClickzProtect was "real or just landing page theater." That stung. The fake-it-til-you-make-it crowd poisons the well for everyone.

Build in Public Without Revenue: The Contrarian Take

Here's where I lose most people. I think pre-revenue content is more valuable than revenue-milestone content. And I think founders should stop apologizing for not having MRR to screenshot.

Why? Because revenue is an output. Just a number. It's the result of decisions that already happened. Sharing a Stripe dashboard tells me nothing about how to make better decisions in my own business — and if I'm being honest, the whole MRR-screenshot culture has started to feel like a weird flex that helps nobody except the person posting.

What's actually useful:

• Infrastructure decisions. "I chose Railway over Vercel because cold starts were killing my API response times. Here's the migration." That's shareable. That helps someone. Infrastructure choices like these matter more than any MRR screenshot — they're decisions other founders can actually learn from.

• Failed experiments. "I spent three weeks building a feature nobody wanted. Here's how I validated it wrong and what I'd do differently." That's content. That teaches.

• Operational systems. "Here's how I manage support across 8 products as a solo founder." The systems that let you operate are way more interesting than the revenue that results.

• Honest tradeoffs. "I could charge more but I'm keeping JustEmails at a flat annual fee because I want volume over margin. Here's the math." That's a real decision with real reasoning. It helps people think about their own pricing.

Revenue screenshots help nobody except the poster's ego. Harsh? Maybe. But true. The dopamine wears off, you need a bigger number next month, and suddenly you're stuck on a treadmill with no exit ramp.

I know because I've done it. Embarrassing to admit. Posted a milestone once, got the likes, felt good for about 45 minutes. Then spent the next week anxious about whether next month's number would be "post-worthy." The engagement treadmill is real, and I got off it as fast as I could. Never again.

What Pre-Revenue Transparency Actually Looks Like

If you're building something and you don't have revenue yet — or your revenue isn't impressive — here's what you can share instead.

Time allocation. Where did your hours actually go this week? Most founders have no idea. Track it for a week. Share the breakdown. I guarantee it's more interesting than you think. (I spent way too many hours on ops tasks last week that I'd budgeted a fraction for. Support tickets, billing edge cases, the unglamorous grind nobody wants to admit takes real time. That's content. Embarrassing content, but content.)

Decision journals. Why did you pick that tech stack? Why that pricing model? Why that market? Write it down. Share it. Even if the decision turns out wrong — especially if the decision turns out wrong — the reasoning is valuable. Claude Code subagents changed how we ship features. Worth documenting whether or not it drives revenue.

Failure post-mortems. The deploy that broke production. The feature that users ignored. The marketing campaign that flopped. The honest version, not the "learning opportunity" sanitized version. Name the dollar amount wasted if you know it. Be specific.

Infrastructure costs. How much are you actually spending to run this thing? Railway bills, Cloudflare costs, API spend. This is useful data that helps other founders budget. We share what we can because it's rare — and because I spent my first year wildly underestimating infra costs and wish someone had told me. Tools like JustAnalytics help track these metrics without the complexity of enterprise analytics platforms.

User conversations. What are your beta users actually saying? Quote them. Directly. Even three people giving you honest feedback beats a screenshot of fake MRR. (And yes, I know "just talk to users" is the most repeated advice in startups. It's repeated because nobody actually does it. I didn't, not properly, until embarrassingly late.)

Seriously. The thread that says "Here's why I chose Postgres over MongoDB for my new project, with the tradeoffs I'm accepting" will outlive every MRR screenshot you've ever posted. Nobody bookmarks Stripe dashboards. I've tried. The engagement dies within 24 hours. A good technical breakdown? Still getting replies six months later. That's why we focus on building systems that compound rather than chasing engagement metrics.

The Implications If You're Pre-Revenue Right Now

So what do you actually do?

First: stop apologizing. "I know I don't have revenue yet, but..." — delete that. You're building something. That's the content. Revenue will come or it won't, but the building process is inherently valuable to document.

Second: pick your transparency angle. You can't share everything. Pick 2-3 things you're comfortable being radically honest about. For me, it's infrastructure decisions, operational systems, and the multi-product studio model. I don't share exact revenue. That's fine. Pick your lane.

Third: document decisions in real-time, not retrospectively. A thread saying "I'm about to choose between X and Y, here's my reasoning" is 10x more engaging than "I chose X six months ago." The audience wants to follow along, not read the cliff notes. (I'm terrible at this, by the way. Half my decisions get documented three weeks after I've already committed. Working on it.)

Fourth: accept that honest pre-revenue content gets less engagement than fake MRR screenshots. In the short term. The followers you get from systems content stick around. The followers you get from revenue theater? Gone the second your numbers plateau. We've found the same pattern across our DevOS developer tools and JustBrowser — authentic content compounds while hype fades.

(This still annoys me. A lot. Some days I wonder if I should just play the game like everyone else. But no. Playing the long game, even when it feels like shouting into a void some weeks.)

At Velocity Digital Labs, we run 8 products with a 1-founder + 1-manager + AI-agents structure. Most are early-stage. I don't post Stripe screenshots because I don't need to. The content is the building — how ClickzProtect handles bot detection with JA4+ TLS fingerprinting, how JustEmails keeps pricing at $49/year flat, how the whole stack runs on shared Postgres, Railway, and Cloudflare infrastructure. That's what the indie hacker audience actually wants. Receipts, not performances.

A Prediction

By the end of 2026, the revenue-screenshot era of build-in-public will be dead.

Maybe that's wishful thinking. Probably is. But I think the audience is already moving on — they're just quieter about it than the screenshot posters.

The accounts that survive will be the ones sharing process, not outcomes. Decision logs, not dashboards. Failures, not milestones.

The Stripe screenshot accounts will have to post bigger and bigger numbers to get the same engagement. Eventually, the numbers required will be so large that faking becomes impossible — or the account just fades into irrelevance.

Meanwhile, the founder who documented their $0 MRR months honestly, who shared every infrastructure decision and failed experiment, will have an archive of useful content and an audience that actually trusts them. That's the asset. The trust, not the screenshots.

I'm betting on the honest version. Could be completely wrong about this. Wouldn't be the first time. (Honestly, my track record on predictions is mediocre at best.) If I am, I'll write the follow-up — and I'll be honest about that too.

Build in public. Just stop pretending that "public" means "revenue." It never did. And honestly? The best content I've ever written came from months where I had nothing impressive to report except "here's what I learned while failing."

Frequently Asked Questions

Can you build in public without sharing revenue numbers?

Yes. Revenue is one metric among many. Share what you're building, why you made specific decisions, what failed, and what systems you've put in place. The build-in-public audience cares about the process, not just the outcome. In my experience, founders who share $0 MRR months honestly often get more engagement than those posting suspicious hockey-stick charts.

What should pre-revenue founders share instead of MRR?

Infrastructure decisions and their costs. Failed experiments and what you learned. Time logs showing where effort actually goes. Technical architecture choices. User feedback — even from a handful of beta testers. Waitlist growth with honest conversion expectations. The boring operational details that nobody glamorizes.

Why do founders fake revenue numbers when building in public?

Social proof pressure, mostly. When everyone else posts impressive MRR screenshots, sharing $0 feels like failure. But the audience knows. They've seen the same seven founders recirculating clout. Honest pre-revenue content stands out precisely because it's rare. The risk of getting caught faking far outweighs the short-term engagement bump.

How do you stay motivated to build in public with no revenue?

Reframe what you're measuring. Track systems built, decisions documented, failures analyzed. Revenue is a lagging indicator. The leading indicators — user feedback quality, infrastructure stability, shipping velocity — are worth sharing even at $0 MRR. When revenue comes, you'll have the receipts showing how you got there.

---

Follow the Studio

Velocity Digital Labs is a bootstrapped multi-product studio building 8 active SaaS products with a 1-founder + 1-manager + AI-agents structure. No VC, no platform-play framing — just shipping. Check the studio site for the full backstory.

See the products → · Browse all VDL blog posts · ClickzProtect · JustEmails