The app itself is a simple ai dictation replacement keyboard. Great retention need to get to the store now.
Thanks in advance. Will test you app in return obv.
https://groups.google.com/g/ai-dictation-testing
https://play.google.com/store/apps/details?id=com.aidictation.app
https://play.google.com/apps/testing/com.aidictation.app
So I have a whole army of people registering with my service with Amex (probably stolen, but not flagged by Stripe).
Our MRR rose like 50% but I know in a month all of them will be reported for refund and I'll have to pay back.
How to fight it?
I keep circling that question and I'd love some real pushback, because from where I'm sitting it looks like the second thing. But I might be missing something obvious.
Quick context. I'm a solo founder running three projects at once. A native AI Mac app, an AI web platform, and a small marketing agency that helps promote the first two. They don't share much technically. Three Supabase projects, three Stripe accounts, a few single digit TB of data spread across them. But the questions I have about them every week are basically the same. Where did MRR move? Which cohorts converted? Which campaigns drove real usage, not just signups?
My current setup, mostly by accident, is pointing Codex at Supabase and Stripe and asking. It works surprisingly well. The thing I keep noticing is that most of the work isn't the SQL. It's me re-explaining the business every time. Which Stripe product maps to which app. What "active user" means this week. Which subscription states actually count as revenue. The agent is great at SQL. The slow part is teaching it what anything actually means.
The embedded side has the same shape. The agency's product ships reporting to clients, and right now that's Supabase queries with a UI on top. It works, but every new report quietly forks the metric definitions a little. Nothing dramatic. Just enough that revenue on the dashboard and revenue in the weekly export don't quite match if you squint.
So the thing I'd love input on, especially from people running internal and embedded analytics on a few TB of OLTP Postgres:
At this scale, is the right move a proper semantic layer (I'm mostly torn between Cube and dbt Semantic Layer) sitting between the raw data and everything downstream, so internal questions, embedded reports, and the LLM all hit the same metric definitions?
Or is that overkill for this shape, and the more honest answer is a typed metrics module in app code, a small analytical replica (DuckDB, ClickHouse, or just a read replica with the right indexes), and letting the LLM rebuild context per session?
Happy to be told I'm overthinking it. That would honestly be the best outcome.
I launched a native Mac dictation app on AppSumo recently.
This is not one of those "we made $300k in 60 days" posts. My numbers were much more normal:
But honestly, that made the launch more interesting to learn from. It was small enough that I could actually see where the assumptions broke.
I am writing this for founders who are considering AppSumo and trying to decide whether it is worth the time. My short answer: yes, I would still launch there, but I would prepare differently.
So this is not an anti-AppSumo post. It is also not a "do exactly what I did" post. It is just what I learned from one real launch.
I would not treat AppSumo as "put the product there and get sales." It is more like a stress test: pricing, positioning, support, product clarity, margins, and your ability to ignore the wrong feedback all get tested at the same time.
These are the questions I wish I had asked myself before going live.
It is easy to look at gross sales and feel good.
That is not the real number.
For a lifetime deal, I would now think about:
This matters a lot for AI products.
My app can work online and offline. Offline usage is cheap. Online transcription has real cost. That means "software has great margins" is not enough as an answer.
Personally, I would want gross margins closer to 80-90% before feeling comfortable with an LTD. If you are around 60%, especially with AI costs, the math can get weird fast.
The question I would ask is:
If the most active users keep using this for years, am I still happy I sold them lifetime access?
This was probably the most annoying lesson.
My app was Mac-only. We said it was Mac-only. People still bought it, complained that it did not support Windows, and left low reviews.
At first that felt unfair. But after thinking about it, it is just part of selling to a broad deal audience. People skim. People assume. People buy what they hope the product is, not always what you wrote.
If I launched again, I would be almost repetitive about things like:
Your listing should sell, but it should also filter.
I would add a very clear "not for you if..." section. Yes, that might reduce some purchases. But it can also prevent support tickets, refunds, and bad reviews from people who should not have bought the product in the first place.
Some AppSumo buyers were genuinely useful early users, so I do not want to overgeneralize.
Others were clearly trying to get as much value as possible for as little money as possible. That is not an insult. It is just how lifetime deal marketplaces work.
One pattern I saw: some users did not really care about the product as a Mac app. They wanted access to the underlying technology. Basically, "Can I get API-style access forever without paying a subscription?"
For AI/API products, that is dangerous.
I would now split feedback into three buckets:
The last one is the dangerous bucket.
If you treat every loud request as strategy, you can end up building for bargain hunters instead of the customers you actually want long term.
"Launch on AppSumo" is not a goal.
Are you trying to get:
Those are different goals.
If the goal is cash, margins and support load matter most.
If the goal is feedback, you need to know which feedback to ignore.
If the goal is validation, define what validation means before the launch. Otherwise you will retrofit the answer afterward.
For example:
I wish I had written down the win condition before going live.
This is a big one.
Not every feature belongs in an LTD.
I would be careful with:
My rule now would be:
If something creates ongoing cost or infrastructure-style access, it needs a cap, a paid tier, or it should stay out of the LTD.
Do not put subscription economics inside a lifetime deal just because a few people ask for "more value." That may make the offer look better for a week and make the business worse for years.
A launch makes everything feel urgent.
One bad review feels huge. One support ticket feels like a fire. One feature request can make you question your whole roadmap.
Before launching, I would prepare:
I did not have this as clearly defined as I should have. That made some feedback feel more important in the moment than it probably was.
My feature request rule would be something like:
I will only consider a request if:
- it comes from the target customer
- it fits the core promise of the product
- it does not hurt margins
- multiple people ask for it
- it would still make sense outside AppSumo
Without a rule like that, the launch can pull you all over the place.
Before going live, I would want clear answers to:
I would still launch on AppSumo.
But I would treat it as a high-pressure launch to a deal-oriented audience, not as automatic validation from my ideal customers.
The launch can be useful. It can also distort your roadmap if you confuse loud feedback with correct feedback.
If I did it again, I would go in with:
Curious from other founders who launched there: what do you wish you had asked yourself before going live?
I have been trying to understand the agentic analytics wave, and the more I read, the more it feels like the hard part is not really the agent.
The agent can plan, retry queries, write summaries, and chain steps together. That is useful, but it still breaks if it does not understand the actual business logic: what revenue means, which joins are valid, which filters matter, which metrics are trusted, and what each team is allowed to see.
That makes me wonder if the real product shift is semantic layers becoming the foundation for AI analytics.
I used to think about this mostly through BI tools and modeling layers: LookML, dbt Semantic Layer, Cube dev, MetricFlow, semantic views in warehouses, etc. Now a lot of that same category seems to be getting repackaged around agents and AI-native analytics.
Maybe that is not actually a pivot. Maybe the semantic layer was always the important part, and AI just made the need more obvious.
Curious how others see this:
- Is agentic analytics meaningfully different from BI + semantic layer + LLM orchestration?
- Do agents actually need a governed metric layer to be useful in production?
- Are semantic/modeling layers becoming AI infrastructure more than BI infrastructure?
- Has anyone seen this work beyond demos for real business users?
I am not asking from a vendor comparison angle. I am more interested in whether agentic analytics is a real architectural category or just the current name for putting agents on top of analytics tooling.
I’m building AI Dictation, a native Mac app that turns spoken thoughts into clean, formatted text.
I shared an earlier version here, but I now have better launch data from AppSumo and the positioning lesson is different than I expected.
Current May numbers:
The surprising part: the product is not being judged only as transcription software.
People care about accuracy, but they also care about whether the dictated text is usable after transcription. That means filler word cleanup, punctuation, grammar, formatting, personal vocabulary, and not having to rewrite every sentence manually.
I originally used this positioning:
“Grammarly for voice”
But the more practical promise may be stronger:
“Native Mac dictation that works online and offline”
The reason is reliability. If you are mid-thought and Wi-Fi drops, dictation should not break. The app can use cloud transcription when online, and fall back to offline transcription when internet is unavailable.
Current focus:
AppSumo page for context: https://appsumo.com/products/ai-dictation/
For other builders: when did you realize the feature you thought was the hook was not actually the hook buyers cared about?
I built AI Dictation because I wanted dictation that did not just transcribe words, but actually made spoken thoughts usable.
Most dictation tools still leave you with filler words, broken punctuation, awkward formatting, and text that needs cleanup before you can send it. The goal here is different: speak naturally, ramble a bit if needed, and get back clean text that is closer to an email, note, spec, comment, or message.
A few things it does:
The product is here: https://aidictation.com
I would appreciate feedback from other builders, especially on positioning. Does "Grammarly for voice" make the value clear, or would you describe it differently?