23,000 Reddit views gave me 14 downloads. Here is what I learned.
I launched my macOS app on Product Hunt today.
I am not writing this as a clean success story, because it is not one. I am writing it because I think I made a mistake many technical founders make: I spent a lot of time making the product better, and only later understood how brutal the visibility problem really is.
TimeBill is a native Mac app for freelancers to track billable hours, create invoices, and export timesheets locally. No account, no cloud dashboard, no SaaS lock-in.
I still believe the positioning makes sense. Client names, hourly rates, project notes, invoices and timesheets are not just generic productivity data. They reveal a lot about your business and your clients. So my bet was that a local-first Mac app could be valuable for freelancers who do not want every sensitive workflow to become another cloud subscription.
It is already in the Mac App Store and covers the core workflow: tracking work, organizing projects, creating invoices, exporting timesheets and keeping the data local. I also built the invoice model around EN 16931 because European e-invoicing support is on the roadmap.
But the hard part has not been building the app. It has been getting anyone to care.
A while ago I posted about TimeBill on Reddit. One post got around 23,000 views. At first that sounded huge to me. In reality it produced around 14 downloads. Some useful feedback, some nice comments, but not meaningful traction.
That was the first lesson: views are not demand.
Later I looked more seriously at the funnel. My App Store numbers were actually not terrible in isolation: 309 product page views led to 63 downloads, so about 20.4% page-to-download conversion. Those 63 downloads led to 16 paying users, so about 25.4% download-to-paid conversion. Realized profit per paying user was about $9, which means the expected profit per download was around $2.29, and the expected profit per App Store view was around $0.47, or roughly €0.43.
On paper, that does not look hopeless.
The problem is getting qualified people to that App Store page cheaply enough.
I tried Reddit Ads. The campaign spent €94.79, got 65,628 impressions, 153 clicks, a €0.62 CPC and a 0.233% CTR. Again, not absurd numbers. But for my funnel and current revenue per buyer, even that CPC is already too high unless the traffic is very qualified. And for a macOS app, a lot of traffic is simply structurally bad. Mobile users cannot install it. People browse casually. They click, but they are not necessarily in a buying moment.
This is where the small-number economics became painful.
If one App Store view is worth roughly €0.43 to me, then a €0.62 ad click is already upside down before even considering that not every ad click becomes a clean App Store product page view. The math can work only if I improve revenue per buyer, improve conversion, reduce CPC, or find much more qualified traffic. Preferably all of them.
That is the part that hurt, because the product can be decent and the funnel can even look okay, but the business still fails if distribution is too expensive or too weak.
Over the last weeks I kept improving the things I could control. I rewrote the website, built more focused landing pages, added small free SEO tools, worked on App Store keywords, screenshots, subtitles and copy, tested Reddit and Google Ads assumptions, and tried different positioning angles: native Mac app, local-first invoicing, privacy-friendly freelancer tool, time tracking plus invoices, alternative to bloated SaaS tools.
Some of these angles sound strong to me. But the market does not care what sounds strong to the maker. It only cares whether the right person sees it at the right moment and understands the value fast enough.
Today I launched on Product Hunt, and I had to adjust my expectations there too. I hoped Product Hunt might be the missing publicity boost. Now I think it is more of a momentum amplifier. If you already have a community, newsletter, customer base or active maker network, Product Hunt gives that momentum a visible place to gather. If you come in cold, you are still mostly pushing the rock yourself.
My current takeaway is simple:
A launch does not really validate the product. A launch validates your distribution.
That is uncomfortable, because building is the part I know how to do. Distribution is the part where there is no compiler error, no failing test, and no obvious fix. Just tiny numbers, leaky funnels and a lot of ambiguity.
So the thing I would tell other technical founders is this: do not wait until the product feels “ready” before you take distribution seriously. A polished product with no audience is still almost invisible. And a tiny audience with a clear pain may be worth more than a beautiful app shown to 65,000 mostly indifferent people.
I am still proud of TimeBill. I still believe local-first software has a place, especially for sensitive business workflows. But I am also trying to be honest about the real bottleneck.
For me, it is not shipping. It is earning attention from the right people.
For context, this is today’s Product Hunt launch:
https://www.producthunt.com/products/timebill?utm_source=other&utm_medium=social
Maybe the mistake is treating distribution as something that starts after launch.
For a technical founder, "the product is almost ready" feels like progress. But from the outside, nobody has any reason to care yet. I’m starting to think the audience-building part has to be treated almost like a second product, not like marketing polish at the end.
This is a strong breakdown because the real issue is not “Reddit didn’t work.” It’s that TimeBill has a qualified-intent problem. The funnel after the App Store page actually looks decent, but the traffic source is bringing too many people who are curious, mobile, or not actively dealing with billing pain.
The local-first angle is the strongest differentiator, but I’d make it less abstract. “Private time tracking” is useful, but “your client names, rates, invoices, and project notes should not live in another SaaS dashboard” is much sharper. That makes the privacy claim feel directly tied to freelancer money and client trust.
One thing I’d watch is the name TimeBill. It explains the feature set, but it also keeps the product in a small utility frame. If this grows into a broader local-first freelancer finance/workflow product, a cleaner standalone brand like Xevoa.com would probably age better than a descriptive name tied only to time and billing.
Thanks, that is a really useful way to think about it.
I agree that a broader local-first finance/workflow product could probably benefit from a cleaner, more brandable name over time. The part I am balancing against that right now is App Store Optimization.
For a Mac App Store product, discovery is still very search-driven, and people often search in literal terms: time tracking, billable hours, invoice app, billing, freelancer invoices, and so on. So with TimeBill, the tradeoff is that the name is more descriptive than brand-like, but it also explains the category immediately and fits the search intent around the app.
If the product grows into a broader local-first freelancer finance workflow, I agree the naming question becomes more interesting again.
That makes sense, especially for Mac App Store discovery.
The only thing I’d separate is search intent from brand memory.
People may search literal terms like time tracking, billing, invoice app, or billable hours, but that does not mean the product name itself has to carry all of that weight.
You can still capture ASO through subtitle, keywords, screenshots, and first-line copy while letting the brand become more ownable.
The risk with TimeBill is not that it is unclear. It is very clear. The risk is that it may be remembered as a small utility, even if the product later becomes a private local-first workflow layer for freelancer money, client records, and project history.
So I’d probably keep the descriptive layer for App Store discovery, but pressure-test whether the actual brand should stay descriptive forever.
If users only need a time billing app, TimeBill works.
If they start trusting it with client names, rates, invoices, notes, and local financial workflow, the naming ceiling gets much more real.
That distinction between search intent and brand memory is helpful.
Do you mean that you would keep TimeBill as the descriptive product/app name for now, but potentially build a more recognizable umbrella brand around the broader local-first freelancer finance workflow over time?
That is the part I am unsure about. For App Store Optimization, the descriptive name still feels useful. But I can see your point that if users eventually trust the product with client records, rates, invoices, notes and financial history, the brand may need to feel bigger than just time + billing.
Yes, that is exactly how I’d think about it.
TimeBill can still do useful work at the App Store/search layer because it matches what people already look for: time tracking, billing, invoices, billable hours.
But the broader brand should probably not be trapped inside those words if the product expands.
The real long-term promise sounds more like local-first freelancer finance workflow: client records, rates, invoices, project history, notes, and billing context staying private and under the user’s control.
That is bigger than “time plus billing.”
So I’d separate the two layers:
TimeBill can be the descriptive entry point for search.
But if the product becomes a trusted local-first operating layer for freelancers, I’d want a broader brand above it. That is where something like Xevoa.com would make more sense because it feels more like a clean software/workflow brand than a utility name.
The question I’d pressure-test is: do you want users to remember the function they searched for, or the system they trust with their client and money workflow?