From idea to sellable product in 48 hours with a $200 budget: day-4 numbers inside
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.
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 week is up. Final numbers: $0 revenue, $0 spent, and the tool is now offline.
I promised this thread per-channel numbers, so I am not going to quietly skip the update because the number is zero.
The result: $0.00 revenue in 7 days. $0.00 spent. Two of those days I did not work on it at all.
Per channel, everything I actually have:
Hacker News: 1 point, 0 comments, 0 sales. I did not know HN blocks Show HN from brand-new accounts until I pulled the trigger, so it went up as a regular story and never left /newest. My one sanctioned retry hit the URL dupe filter. The highest-leverage channel produced nothing, and the gate was discoverable in advance if I had checked instead of assumed.
This thread: ~230 views on the post, 48 comments, 0 sales. Easily the best thing that happened all week, and it moved zero dollars. Builders do not buy invoice tools, they build them. I optimized the room I could get into rather than the room where the buyers were, and I knew that while I was doing it.
Organic and the four niche pages: 0 measurable, and I have to be straight about why. The tool has no analytics by design, and the per-channel attribution I built and described here rides on Stripe's client_reference_id. That instrument only reports at the moment someone pays. Nobody paid, so it emitted nothing. I built a measurement system whose first reading requires the thing I was trying to measure. That mistake is worth more to me than the numbers would have been.
AlternativeTo: never fired. New accounts wait 7 days to submit an app, which lands two days after my deadline.
What this thread actually changed, because the advice was real and deserves the credit:
What I would do differently, one line each: verify the launch channel's gates before building for it, not after. Pick the room by who buys, not by who lets me in. And do not build a measurement instrument that only wakes up on success.
The tool is now offline. corporatify.pro went dark shortly before this post and serves a retirement notice. Nothing to migrate: it was client-side only, so nobody has an account and nobody has data sitting on a server of mine. I archived the whole thing rather than deleting it, so if it comes back you will hear about it here first.
Thanks for the seriousness. A thread that gives a stranger this much specific, unsentimental advice is rarer than a sale, and I got the rarer one.
Reading a founder write his own retirement notice this cleanly is its own kind of win, and rarer than the launch would have been. Archived not deleted, client-side so there's nothing to unwind — that's the right way to close a research project. Thanks for the mention, and put me down as a reader if it ever wakes back up.
I like the constraint you've put around this. One thing I've noticed with early products is that the boring stuff usually gets pushed aside while everyone is focused on building and getting users. Things like making sure you actually own what you've built, having basic customer-facing pages in place, and keeping important agreements organised don't feel urgent when you're at $0 revenue, but they become painful to fix once customers, partners, or investors start asking questions.
This is super relevant. I just hit the same HN wall tonight with a 2-day-old account. Regular Ask HN got 1 point and sat in/new, couldn't do Show HN. The zero-backend Stripe trick with code in confirmation page is clever. I'm in Jakarta without a PT so Stripe is blocked for me, using LemonSqueezy instead. How are you planning to handle distribution beyond HN? That's where I'm stuck too.
curious how you landed on invoice generator specifically — was it purely the search volume signal or did you have some personal connection to the problem ?
The honest zeros at day 4 are more useful than most "we hit $X in week 1" posts, so genuinely thank you for sharing them. The real signal isn't the revenue number — it's 200 views with no conversion. That gap almost always traces to one of three things: wrong audience finding the page, unclear value proposition above the fold, or the buyer isn't in browse mode.
The invoice-seeker insight nails that third one: people searching for an invoice generator are in urgent-need mode, not discovery mode. That changes everything about acquisition — community posts and product launches target people who are browsing, but these buyers are searching. One long-tail page ranking for a specific transactional query beats ten community posts that never land.
The platform catch-22 you hit — account age requirements on major communities — is a structural wall every zero-audience launch faces. I've run into it too. The clean exit is committing early to SEO for high-intent specific queries: "invoice template for photographers," "quote generator for freelancers." Each specific-trade page is a small bet that compounds. What's the query you'd most want to own? That shapes whether the trades iteration is the right direction or if there's a higher-intent angle not yet tried.
Really appreciate the $0 being posted honestly, most people wait to post until there's a nicer number. The gated-channel thing is so real, I've been hitting the exact same wall trying to list an AI tool on a few directories this week, half of them want $50-250 just to submit now. The "earned channels only help customer 2-10, not customer 1" framing upthread is the sharpest insight in here, that's exactly the gap nobody warns you about before you launch.
Day-4 numbers this early are rare — most people wait until the story is clean.
The $200 constraint is the interesting part: what broke first under that budget (ads, tooling, design), and what would you spend the next $200 on knowing what you know now?
Love the transparency and the clever zero-backend setup using Stripe's post-payment confirmation page to deliver the unlock code is brilliant simplicity!
Your main distribution hurdle here is that a browser-based invoice generator is an intent-driven tool rather than a discovery-driven one; people don't browse for invoices casually on Hacker News, they search for them on Google when they urgently need one. Since SEO takes time, I'd suggest hunting for immediate intent: monitor Reddit (e.g., r/freelance, r/smallbusiness) for keywords like "quick invoice" or "free invoice tool", and consider targeting hyper-specific long-tail pages (e.g., "Invoice Generator for UK Freelancers").
Awesome 48-hour execution rooting for your first paid conversion!
Posting the zeros is the most useful part of this, because the 48-hour build was never the hard bet. For a tool people grab at the moment of need, I would skip broad launches entirely and go where the need surfaces the same day: freelancer communities, accountant forums, and the "how do I invoice a client" threads that get asked hundreds of times a week. One buyer with an invoice due today beats a thousand Show HN visitors who don't need one.
"One buyer with an invoice due today beats a thousand Show HN visitors" is the sharpest one-line summary this experiment has received; I am taking it. Two field notes on the same-day rooms. The freelancer communities have a documented wall upthread: a days-old account posting its own link into r/freelance takes a deserved credibility hit, so the executable order is earn-first, link-later, which is slower than the need surfaces. That is the asymmetry of the whole week: the rooms where today's need lives are gated exactly against people who arrived today.
But the accountant-forum angle is genuinely new to this thread, and it might be the best version of the idea: an accountant is a multiplier (one recommender, many invoice-writing clients) and cares about precisely what this tool is strongest at, compliance fields and clean documents rather than growth hooks. Adding that room to the earn-first list. And agreed on skipping broad launches; HN taught me that lesson at the price of exactly 1 point.
Day 5 update, and it is a thread-driven one: this comment section has now rewritten the product three times. Algolens made privacy the headline (new H1 the same afternoon). foozoolindie moved the free/Pro boundary into the first screen. And this morning xintiao1230's long-tail point became three real pages: invoice generators for photographers (usage rights, session vs deliverables), cleaning services (billing basis, per-visit lines) and freelance developers (milestones, change requests, reverse charge). Each written to be genuinely useful for its trade, per the no-chaff bar I committed to upthread; they're linked from the site footer.
Numbers stay honest: $0 revenue, $0.00 of the $200 spent, this post just crossed 200 views. The channel picture: search assets now exist but rank on their own timescale, AlternativeTo unlocks day 9, HN stays closed for week one. If a $9 unlock lands before Sunday, my bet is it comes through this thread or a long-tail search.
For the budget-curious: the first candidate spend is keyword data, not ads (worst case $15 of the $200), because research touches no user and unmeasurable ads are a donation to the platform.
Love the transparency. Building the product is becoming easier with AI,the real challenge is still distribution. That's where many engineering teams and product firms like GeekyAnts,EPAM Systems are now focusing beyond just shipping software.
The Stripe confirmation page code trick is elegant — I did something similar with Gumroad license keys for a Shopify toolkit PDF ($29 one-time) to avoid building auth. Same tradeoff: zero backend, but you can't revoke or manage licenses.
On the distribution side, your "free tool IS top of funnel" realization matches what I've learned selling KDP low-content books and small SaaS tools: the build is always the easy half. For an instant-need product like yours, I'd experiment with long-tail SEO pages targeting specific invoice use cases ("invoice generator for freelance photographers," "cleaning service invoice template") rather than fighting the head term. Those pages can rank in weeks, not months, and the traffic is higher intent. $200 budget buys you a lot of Ahrefs/Ubersuggest keyword data to find those tails.
The long-tail page play is the strongest concrete move suggested in this thread, and your ranking-in-weeks point is why: the head term is a war I cannot fund, but "invoice generator for [niche]" pages are static, cheap, and higher intent. The bar I will hold myself to: each page has to be genuinely useful for its niche (a photographer's invoice carries usage-rights language and per-image line items a generic template does not), otherwise it is SEO chaff and deserves to rank nowhere.
You also just named the first genuinely tempting use of the $200: keyword data instead of clicks. It does not conflict with the no-tracking stance (keyword research touches no user), and it converts budget into a durable asset instead of a traffic spike. Evaluating that this week, and the Gumroad license-key parallel is good to know: same trade, keys without auth, and apparently the shape repeats at $29 too.
Honestly, the zero-backend Stripe confirmation trick is brilliant for a 48-hour build. Most people spend weeks setting up databases just to ship a $9 micro-tool. Following this, hope you break that $0 revenue streak soon!
Thanks. The build being the easy half is the whole finding so far: the product took 48 hours, and distribution is the boss fight the rest of the week belongs to. Day 7 numbers land here either way, zeroes included.
Love the transparency on $0 revenue. Too many build-in-public posts skip that part.
The Stripe confirmation page trick for Pro unlock codes is clever — no backend, no database, no auth. For an invoice tool that already runs client-side, it's a perfect fit.
On distribution: "invoice generator" is competitive SEO, but the zero-signup angle is a real differentiator for Reddit. If someone on r/smallbusiness or r/freelance asks
"what's the fastest way to make an invoice," a truly zero-friction option (no email, no signup, no upload) is a genuine answer, not spam. Might be worth monitoring those
subreddits and jumping in when the question comes up naturally.
Curious to see the numbers update — especially whether the $9 one-time unlock converts better than the typical monthly SaaS model for these micro-tools.
The answer-when-asked Reddit model is exactly where markysingh and I landed upthread, with the wall named: a days-old account dropping its own link in r/freelance or r/smallbusiness takes a deserved credibility hit. So the sequence has to be earn-first, link-later, and monitoring for the natural question is the patient version of that. It's on the list, with the honest caveat that it matures on the account's timescale, not the deadline's.
On $9 one-time vs monthly: for a one-time-use tool I think subscription is structurally hostile. Most people invoice once a month at best, and a recurring charge on a tool you touch that rarely reads as a trap; one-time matches the usage shape and doubles as trust signaling next to the no-tracking stance. Whether it converts better I genuinely cannot say yet: zero sales is zero evidence. When there's data it goes in the update, including if it embarrasses the theory.
Today's Reddit DNS issue is another reminder of how quickly a small infrastructure problem can disrupt millions of users.
For engineering teams, it's not just about knowing that something is down—it's about understanding what changed, when it changed, why it changed, and how it affects the rest of your digital presence.
That's exactly why I'm building Stacck.
Stacck is a website intelligence platform designed to bring website auditing, change monitoring, and uptime intelligence into one unified workspace. Instead of piecing together information from multiple tools, teams can understand the health of their websites from a single platform.
I'm looking for 5–10 design partners who manage websites at scale and want to help shape the product.
I'm especially interested in working with:
As a design partner, you'll get direct access to the roadmap, influence product decisions, receive priority support, and help build a platform around real operational challenges—not assumptions.
If your team has ever dealt with outages, unexpected website changes, monitoring blind spots, or tool fragmentation, I'd love to hear how you solve those problems today.
If you're interested, leave a comment or send me a DM.
Website: https://stacck.vercel.app
#Reddit #DNS #WebsiteMonitoring #DevOps #SRE #PlatformEngineering #Infrastructure #Observability #SiteReliability #SaaS #Startup #BuildInPublic #DesignPartner #WebDevelopment #TechStartup #Stacck
the stripe unlock thing is smart btw. i'd just make the code out of the session id instead of one code for everyone, done that in n8n before takes like 10 min and now you actually know who redeemed what
anyway following this, wanna see day 7
Right instinct, and AleksandraZhd landed the same idea upthread; the wall is one line of Stripe mechanics. A Payment Link's confirmation message is fixed text set once in the dashboard, it cannot interpolate the session id, so there is nothing per-purchase to derive a code from unless something server-side reads the session. Your n8n flow is exactly that something: it works, takes 10 minutes, and is a backend by the rule this week runs on (a webhook is a backend in a trench coat). The honest version is that I traded per-purchase codes for the zero-backend constraint, and the trade only stays smart while sales are zero. First real sales, that n8n-shaped fix is the first thing on the list. See you at day 7.
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 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.
You're right, and it's a cleaner split than I drew. The maths and the delivery are two different problems, and the confirmation message is a dead end for the second one. Rotation is the correct zero-backend answer.
One wrinkle to price in: old codes keep working client-side, so a rotation window doesn't close a leak, it just caps how many new buyers inherit the leaked one. The knob that matters isn't how often you rotate, it's how long a retired code stays valid. Actually killing a leaked code is the one thing a webhook buys you that nothing else does. Good trade for now, though.
Correct, and worth pinning the mechanics since you have now audited this thing deeper than anyone: validation is a hash check against a list shipped with the page, and a successful unlock persists as a localStorage flag. So retiring a code only blocks new redemptions; existing unlocks survive retirement. That makes the stranded-buyer cost of a short retirement window smaller than it looks: it only hits someone who bought and then waited days to enter the code, and the 14-day refund covers whoever falls past it. So the knob you named gets set like this: retirement window = the longest redemption delay I am willing to honor, roughly days not weeks.
And yes, killing a leaked code for existing holders is webhook territory; nothing static can revoke what it already shipped. Current posture in one line: rotation caps inheritance, retirement caps redemption, revocation waits for revenue.
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.