Last Saturday I started a constrained experiment: build and launch a paying product in one week, starting budget $200, no existing audience, no brand, nothing physical.
What shipped in the first 48 hours:
Product: Corporatify Invoice Studio (https://corporatify.pro/?src=ih), an invoice/quote generator that runs entirely in the browser. No signup, no upload; the data never leaves the client. Free core, $9 one-time Pro unlock delivered as a code via Stripe's confirmation page, so there is still no backend.
Stack: one static HTML file on Netlify. Total infra cost: $0.
Spend so far: $0.00 of the $200.
Revenue so far: $0.00. Fully transparent, and that is the point of this post: most "I built X in a weekend" stories skip the part where distribution is the actual product.
What worked: picking a tool with instant need (people search "invoice generator" when they need an invoice NOW), and the zero-backend unlock trick (Stripe's post-payment custom message carries the code).
What has not worked yet: Hacker News. New accounts cannot post Show HN, the /newest firehose gave the regular story 1 point, and my founder comment got auto-flagged for mentioning pricing. Lesson logged, one FAQ-sanctioned retry planned.
I will post the numbers here as they move, including if they stay zero. Questions and roastings welcome, especially on distribution for zero-audience launches.
Really appreciate the transparency on the $0 revenue. Most "I built X in a weekend" posts omit the part where the build was the easy half.
The zero-backend unlock via Stripe's confirmation message is clever. One question on distribution: you mentioned the tool solves an instant-need problem (people searching "invoice generator" when they need one right now). Are you planning to go after SEO for that term, or is there a faster distribution angle you're testing? Curious because "instant need" products seem like they'd benefit from being findable at the exact moment of need, but SEO takes forever — and you've only got five days left on the clock.
Also — are you documenting anywhere else besides IH? A one-week constrained build with real numbers (even zeroes) feels like content that could travel well beyond this thread.
Both tracks, with honest expectations about which one can pay inside the window. SEO is the structural bet: an instant-need tool lives or dies on being findable at the exact moment of need, so the structured data, the privacy-first H1 rewrite and the FAQ markup all shipped this week even though none of it can rank in five days. The faster angles are what this experiment is actually measuring, and so far they are a museum of gates: HN blocks new accounts from Show HN, AlternativeTo has a 7-day account-age wall (my listing lands two days after my own deadline, which is itself a finding), and this thread is currently the only channel producing measurable attention.
So the five-day answer: nothing I can do now makes search pay by Sunday, and I would rather report that plainly than pretend a hack exists. The deadline measures the experiment, not the product; assets that mature after day 7 still count as results, they just get reported as futures rather than revenue.
On documenting elsewhere: just here for now, deliberately. One channel fed properly beats three fed half-heartedly, and these numbers only carry credibility where readers watched them happen live. A written post-mortem after day 7 is likely, and if that piece travels beyond the thread, it proves your point with the same zero-budget constraint intact.
The Hacker News note is real and it's not just HN, we ran into the exact same shape of problem this week trying to build a comment history here on IH before we're allowed to post at the top level. Every new-account gate on these platforms is basically designed to filter out the zero-audience launches you're describing, which is a weird irony since zero-audience is precisely who needs the distribution most. On the cold-start question you raised, our approach this week was blunt: skip the platforms that gate on reputation entirely for now, and go straight at cold email instead since there's no trust threshold to earn, you just need a good list and an honest pitch. Sent 150+ real emails off a self-sourced list of 300+ leads and treated the reply rate itself as the distribution signal rather than waiting on any platform's algorithm. Appreciate you posting the zero-revenue numbers honestly, that's rarer than it should be on here.
Cold email is a real answer to the gate problem and I'm glad someone in this thread is running that arm, because I deliberately didn't, so between us the comparison actually exists. Two reasons I left it on the table. First, deliverability is its own cold-start: my sending domain is younger than this thread, and 150 cold sends from it would likely torch the reputation that the product's own support and receipt mail depends on. You traded a platform trust threshold for an inbox trust threshold; both are walls, yours is just self-hosted. Second, the shape of the need is different: an invoice generator's customer is a moment, not a segment. People who need an invoice right now are not sitting on a list I could source; by the time an email lands, the need has passed or been solved. A meeting-notes tool or an analytics product can name its buyer in advance, which is why cold outreach can work for you and mostly can't for me. That asymmetry, which channel fits which product shape, feels like the actual lesson under both our experiments.
What reply rate did the 150+ produce? That number would genuinely help everyone reading this, zeroes included.
you already nailed the lesson (distribution is the product), so the useful question is which surface fits THIS tool. a $9 one-time invoice tool with no audience wont win on SEO fast ("free invoice generator" is a bloodbath), but you have a wedge most invoice tools dont: free, no signup, and the data never leaves the browser. that privacy angle is the hook, freelancers are genuinely nervous about uploading client data to random sites. lead with "invoice generator that never sends your data anywhere" exactly where freelancers already ask (r/freelance, r/smallbusiness, designer/dev communities). one more: a $9 one-time has no reason to come back and nothing to share, so the free tool IS your top of funnel, get it used at scale first, then convert a slice to pro. dont optimize the $9 until the free tool has real usage.
Your headline advice went live about an hour before your comment: the H1 is now "Free invoice generator: nothing gets uploaded, ever", so this thread has literally rewritten the site's front door today.
On the freelancer communities: you're naming the right rooms, and they have the same wall this experiment keeps hitting: a days-old account posting its own product link in r/freelance or r/smallbusiness is a removal plus a credibility hit, deservedly. So the sequence I can actually execute is yours in reverse order: free tool gets usage via search surface and word of mouth first, and community presence gets earned the way it happened here, by being useful in threads before ever linking anything. The "free tool IS the top of funnel, don't optimize the $9" framing is now pinned above my task list.
The zero-audience launch constraint is the real lever here. Most "day 1 to $10k" narratives gloss over having either an existing audience, press relationships, or a network that amplifies. Your point on Hacker News is sharp - the platform itself requires reputation just to use it as a distribution channel. You're trying to solve a cold-start problem on platforms designed to punish cold-starts. That means the product gets measured against impossible odds. The real metric: did it work despite being invisible, or would the same product hit $50 with your existing audience?
The control group I'd need doesn't exist: there is no parallel me with an audience shipping the identical tool. So the closest honest move is to price the invisibility instead of pretending to isolate it. Week one's price tag: 120 views, 27 comments, 0 sales. Whatever an audience would have added on top of that is the value of the audience, not the product, and that's the quiet confession inside most "day 1 to $10k" stories: the revenue was largely the audience's, harvested through whatever they happened to ship.
Which narrows my Sunday metric to something answerable: did any stranger who has never seen my name pay $9 through a channel that was open to a nobody. If yes, the mechanism repeats from zero and the writeup says how. If no, the writeup prices each wall in days: 7 for AlternativeTo's account age, some unknown number for HN's reputation, zero for search but with a rank latency far past the deadline. Either outcome is a real result; only one of them is revenue.
Respect for posting the $0 instead of dressing it up. the distribution point feels right too. an invoice tool is basically one time use, so every customer is a new person googling it, which means search is pretty much the whole game. the privacy angle is a strong hook for that. are you planning to lean on seo, or spend some of the $200 on ads to test?
SEO, and the $200 stays holstered for now. The ads math on this exact term is brutal: "invoice generator" clicks are bid up by funded incumbents to several dollars each, so the whole budget buys a few dozen clicks, which at typical tool conversion rates rounds to zero signal. And I've made paid deliberately hard for myself on purpose: no pixels, no retargeting, no analytics, because "nothing gets uploaded, ever" is the product. Buying traffic you refuse to measure end-to-end is a donation to the ad platform.
If any of the $200 moves, it goes where a small spend can answer a defined question, most likely a long-tail term where a handful of dollars a day can actually test a message, not the head term. You're right that one-time-use makes search the whole game; that reframe is already upthread from Algolens and it rewrote the site's H1 the same afternoon.
Love the constraint and the honesty that $0 revenue is part of the experiment. Most weekend-launch posts skip that.
Your product pick is smart for intent. People searching invoice tools usually need something immediately, so zero signup and browser-only is a real advantage over SaaS that asks for an account first.
On distribution with no audience, the channels that tend to work for this kind of tool are boring but consistent: SEO pages for exact queries, Product Hunt later once the Pro unlock feels polished, and Reddit/communities where freelancers ask how to send an invoice today. Paid can wait until you have one converting landing message.
One product question: what does Pro unlock that free does not? If that gap is clear on the page before Stripe, cold traffic converts better. If Pro is vague, people finish the free invoice and leave.
Will follow the day-by-day numbers. Roasting request accepted: treat distribution experiments with the same rigor as the 48-hour build, one channel at a time, same budget discipline.
The split follows one rule: everything a legally complete invoice requires is free, unlimited, forever. Pro ($9 once, per browser) is identity and convenience only: your logo on the documents, saved business and payment profiles, two extra templates, and no footer badge on the PDF. So free isn't a demo, it's the whole compliance job, and Pro is "make it look like my business and stop retyping my details". Charging for correctness in a product whose entire pitch is trust would poison the pitch.
Your conversion point lands though. The gap IS listed on the page, but it lives in the pricing card, which means a cold visitor meets the price before the rationale. Moving the free/Pro boundary up into the first screen, one plain sentence near the top rather than a feature table at the bottom, is cheap and worth shipping before the week closes. That's the second time this thread has rewritten the page (the H1 was Algolens's doing), which is quietly becoming the best argument for build-in-public I've got: the thread is outperforming every other channel at improving the thing it's supposed to be distributing.
And the channel order you describe (SEO pages, communities, PH later, paid last) matches where I've landed, with the one wrinkle documented upthread: the community rooms gate new accounts too, so even the boring consistent channels have a queue at the door.
Building an MVP quickly is a great way to validate ideas before investing too much time. How did you decide which features were essential for the first version?
The selection rule was artifact-first: I wrote down what a legally complete invoice must contain (parties, numbers, dates, line items, VAT handling) and anything that changes the printed PDF made the cut, anything that doesn't was dropped. No dashboard, no history, no accounts: none of them alter the document. The one deliberate "extra" was EU VAT and reverse charge, because for my target user that's not a feature, it's whether the invoice is legal.
The free/pro split fell out of the same rule: everything required to produce a correct invoice is free, and pro only carries identity and comfort (your logo, saved profiles, extra templates). Charging for correctness in a trust-first product would poison the whole pitch.
the thing worth adding that nobody's said yet: an invoice generator is a one-time-use tool. someone makes an invoice, closes the tab, might never come back. that's not a flaw but it changes the whole game. your growth isn't retention, it's how many fresh first-timers you can put yourself in front of. which means your entire lever is search surface area, one page per invoice type, per use case, per country, because every single customer is a new searcher.
and your strongest hook for those pages is the thing you almost buried in a footnote: no signup, data never leaves the browser. every other invoice tool wants an account. for someone billing a client they barely trust, "nothing gets uploaded anywhere" is a genuine reason to pick you. i'd make that the headline, not a detail.
i ran into the same realization building a search-y tool in a totally different space (a youtube analytics thing) where "your data stays local, no server storage" turned out to convert the privacy-wary people who bounced off everything else. so i wouldn't treat it as a nice-to-have.
$0 at day 4 on a search play is completely normal by the way. ranking doesn't move in a week. the only number that means anything right now is whether those pages are getting indexed and pulling any impressions, not revenue.
The retention reframe is the single most useful comment on this post: a one-time-use tool means every customer is a new searcher, so the lever is search surface area, not community presence. That converts directly into a roadmap (one page per document type and use case) instead of a vague "do SEO".
And you're right that I buried the lead. "Nothing gets uploaded anywhere" is going to become the headline on the site today, not a footnote; your YouTube-analytics data point that local-only converts the privacy-wary who bounced off everything else matches exactly why I built it this way. Also taking the calibration to heart: day-4 revenue on a search play is noise, indexing and impressions are the real scoreboard this week.
On "the attribution tags are live", check they survive the checkout hop. That's where a no-backend setup usually loses them: the visitor arrives with a UTM, goes to Stripe on a different origin, comes back on the confirmation page, and whatever you kept in the page or localStorage was never something Stripe saw.
With Payment Links you can append client_reference_id to the URL and it turns up on the session in the dashboard, so customer #1 shows up with a channel attached instead of as a mystery payment. Ten minutes of work, and it's the difference between knowing long-tail search worked and believing it did.
The other thing that'll bite: plenty of that instant-need traffic opens in an in-app browser from wherever the person already was, which quietly kills anything stored client-side.
You reverse-engineered my implementation exactly: it IS client_reference_id appended to the Payment Link URL, mapped from one document.referrer read at page load (hn / ih / search / direct), shipped this morning. No UTMs, no storage, so the in-app browser failure mode you describe mostly misses this path: nothing needs to survive the hop because the channel tag rides the link itself.
Where your warning does bite is the unlock: the Pro flag lives in localStorage, so someone who buys inside an in-app browser and later opens the site in their real browser will not see Pro active. The unlock code from Stripe's confirmation page re-enters fine on any device, which is the mitigation, but I should say so explicitly near the buy button. Noted as a real papercut, thank you.
Cleaner than what I described, since the tag rides the link. Two things your data will show you anyway.
document.referrer comes back empty for a lot of app-originated traffic: native apps, some in-app webviews, anything pasted into a messenger. Chrome also trims cross-origin referrers to the origin by default. So "direct" stops being a channel and becomes the bucket holding exactly the sharing you most want to measure. You publish those links yourself, so put an explicit ?src=hn on them and keep referrer as the fallback for people who arrived some other way.
The unlock code will get shared too, invoice tools get passed around. Counting redemptions per code tells you when that starts, and binding the code to the email on the Stripe session tightens it if you care.
Both shipped within the hour: ?src= now wins over referrer on the site (validated, lowercased, 16 chars max), and the product link in this post carries ?src=ih as of this edit. You're right that "direct" was silently absorbing exactly the sharing I most want to see; now it only holds genuinely untagged, referrerless arrivals.
The code-sharing point is the first thing on the list that genuinely wants a backend (per-code redemption counts), so for this week it stays a known blind spot: if the same code unlocks fifty browsers, I'll see one sale and a suspiciously popular product. Honest trade at this scale, and worth exactly the Stripe-session email binding you describe when it stops being honest.
Shipping both inside an hour says more about how this goes than any channel number you'll get this week.
On the code blind spot, one move that needs no backend: derive the code from the Stripe session id so it's unique per purchase instead of per product. You still can't count redemptions, but when the same code turns up in fifty browsers you know which sale leaked, which is usually enough to decide whether it matters yet.
This is where the static setup finally runs out of road, and it's worth being precise about why: the Payment Link confirmation message is fixed text, set once in the dashboard. It cannot interpolate the session id, so there is no channel through which a per-purchase code reaches the buyer without something server-side reading the session (even a tiny webhook counts as a backend for this purpose). Deriving the code from the session id works cryptographically; delivering it doesn't.
The nearest zero-backend approximation I can actually run: rotate the static code on a schedule (redeploy with a new hash, old codes keep working for existing unlocks since those live client-side), which bounds any leak to a rotation window instead of the product's lifetime. That plus your fifty-browsers observability point is probably the right amount of engineering for a product with zero sales. The moment it has real ones, a webhook is cheaper than this conversation.
Following this series. I'm in a similar boat — product is live, struggling with distribution. Did paid ads factor into your $200 or was it all organic?
All organic so far: spend is still $0.00 of the $200, four days in. Not on principle, on two practical grounds. First, the math: this product's head term is bid up by funded incumbents, so $200 buys a few dozen clicks and no statistical signal either way. Second, self-inflicted: the product's pitch is "no tracking, ever", so I won't run pixels or retargeting, and paid traffic you can't measure end-to-end is mostly a donation to the ad platform.
For your boat, the reusable version is: paid multiplies whatever conversion you already have, including zero. Before spending, I'd want one page message that demonstrably converts the traffic you already get, however small; then paid becomes an amplifier with a known gain instead of a lottery ticket. Happy to trade notes as the series goes on; what's your current traffic-to-signup ratio?
This reflects a pattern I've noticed: the gate problem for zero-audience launches isn't binary. The real challenge is that most places where people actively search for solutions (Reddit invoicing communities, specialized forums, relevant Slack/Discord groups) either aren't indexed or don't work for product launches.
HN, AlternativeTo, and Indie Hackers all require "earned" access, but they're also not where most invoice-pain people are searching in real time. The searchers are on Google or asking friends.
The asymmetry: by the time you've earned access to these gated channels, you're no longer zero-audience. So those channels become useful for the 2nd-10th customer, not the first one. Worth asking which channel produces customer #1 - that's the pattern that reveals the actual distribution model you're building.
The asymmetry you describe is the sharpest framing of this whole experiment, and I'll go one step further with it: if earned-access channels only become useful from customer #2 onward, then a one-week revenue window structurally selects for exactly two paths to customer #1: intercepting real-time search intent (slow to rank, so mostly luck inside a week) or a direct handoff from someone who already trusts you (which a fresh anonymous brand has zero of, by design of this experiment).
Which means the honest hypothesis is now: customer #1, if it comes this week, comes from long-tail search, and everything else I'm doing (this thread included) is infrastructure for customers #2-10 that pays after the deadline. I'd rather publish that prediction now and be wrong in public than fit the story afterwards. The attribution tags are live, so whichever channel delivers #1 will be on the record.
Respect for posting $0 revenue instead of burying it. Most weekend-build posts skip that part on purpose.
The instant-need wedge is smart. “Invoice generator” is high-intent search, and the no-backend Stripe code unlock is a clever constraint.
HN being rough for new accounts is normal. I’d put more energy into places where people already ask for invoice tools, not the /newest lottery.
I built Make it RAIN for creators stuck after shipping, so “distribution is the actual product” is basically the whole thesis on my side too.
If the next update still shows $0, the useful question isn’t “is the tool bad?” It’s “where did 20 people with invoice pain see it this week?”
"Where did 20 people with invoice pain see it this week?" is the correct roast, and the honest answer is: almost nowhere yet. That IS the $0.
The uncomfortable discovery of week one: nearly every place where invoice-pain people already ask is gated against newcomers. HN blocks Show HN for new accounts, this site rightly made me earn posting by commenting first, AlternativeTo has a 7-day age rule before you can list a product. So the real week-one work of a zero-audience launch isn't picking channels, it's earning entry into them, and the compounding channels (search, directory listings) only start paying after the gates open. Current pipeline: structured data live for search, the AlternativeTo listing queued for when the account matures, and one sanctioned HN retry today.
If the next update still shows $0 with those channels actually open, then the question graduates to "is the offer wrong", and I'll report that too.
I like that you're treating distribution as part of the experiment rather than assuming launch equals demand.
I'll be interested to see which acquisition channel eventually produces the first paying customers. Those patterns will probably reveal more about the business than the first sales themselves.
You've hit the design tension head on: the product's whole pitch is "no tracking", so I refuse to watch a funnel dashboard even for my own experiment. The attribution plan sits on the conversion event instead: a separate Stripe payment link per channel (HN, here, organic search), so the first paying customer arrives pre-labeled without a single cookie on the site itself.
Honest split so far: HN produced one upvote and nothing measurable beyond it; this post is channel two, twenty minutes old; organic search is the slow third (structured data went in yesterday). I'll post the per-channel numbers as they move, zeros included.
Appreciate the context.
The interesting part is how you’re balancing learning distribution without compromising the product principle.
Would be good to discuss the experiment and what you’re seeing in more detail.
What’s the best email to reach you on?
[email protected] reaches me. Though if the questions would be useful to others running zero-audience launches, I'd rather answer them right here in the thread; the whole point of this experiment is that the boring middle part stays public.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.