I shipped a productivity SaaS in 30 days as a solo dev — here's what AI actually changed (and what it didn't)
In 2019, 23.7% of new startups had a solo founder. By mid-2025, that number was 36.3%.
Something structural shifted — and I think I felt it firsthand.
I spent six years building products at companies in Kyiv. I watched features that a single developer could ship in a day get stuck for months in approval chains. The average enterprise PR sits untouched for four days before anyone even looks at it — not because people are lazy, but because process overhead scales faster than teams do.
And yet… products still shipped. Users still came. Revenue went up.
The dysfunction was real — and somehow it didn’t matter. That made it more frustrating, not less.
I always wanted to build something of my own.
The blocker wasn’t ideas. It wasn’t time.
It was design.
I’m a backend-first developer. I can architect systems, write clean TypeScript, ship reliable APIs.
But I can’t make things look good.
Hiring a designer for a product with unknown revenue felt like betting money I didn’t have on odds I couldn’t calculate.
So I waited.
Then the calculus changed.
AI-generated design gave me a starting point — not Dribbble-worthy, but good enough to validate.
AI coding tools handled the parts that usually kill solo projects: boilerplate, tests, repetitive CRUD.
In practice, something that would’ve taken me ~6 months took about 1 month.
Six months is a bet I couldn’t afford.
One month was survivable.
I built Flowly — a workspace for tasks, timers, and analytics.
It’s for freelancers who are tired of using 4 different apps just to answer one question:
Where did my week go?
I built it for myself first.
I use it daily.
That’s either a great sign — or a selection bias trap. Still figuring that out.
What AI actually changed:
Speed
Not across the board — but where it matters. Boilerplate, scaffolding, tests — dramatically faster.
Architecture, data modeling, product decisions — still 100% on me.
Realistically: ~2x–4x depending on the task.
The design blocker
This was the real unlock. Not “AI made me faster” — but “AI removed the reason I hadn’t started for 5 years.”
The risk threshold
This is the biggest one. A failed 6-month project hurts. A failed 1-month project is survivable.
That changed everything psychologically.
What AI didn’t change:
Judgment
What to build, what to cut, how to price — still entirely human.
AI executes. It doesn’t decide.
Distribution
This is where I’m struggling.
I’m a developer — building feels natural. Distribution feels like guessing.
I catch myself opening VS Code when I should be talking to users.
Shipping code feels like progress. Posting on Reddit feels like gambling.
Not rational — but real.
Where I am now:
- Live at flowly.run, with paying users
- 14-day reverse trial (full access, no card → downgrade after)
- Pricing: $8/month annual, $12 monthly
That jump from 23.7% to 36.3% solo founders?
I think it’s AI removing the two biggest blockers: time and design.
The window feels real.
I’m trying to use it.
Posting here because Indie Hackers seems better than most at the builder → distributor transition.
If you’ve made that shift:
What actually changed the game for you?
https://flowly.run — free tier available, no card required
The comment about AI compressing build time but not indifference is the most honest thing I've read about this space in months. I shipped three things last year with AI help. All three were the best I'd ever shipped. Zero users on two of them. The build getting easier just made it more obvious that the hard part was always finding people who actually wanted it.
The risk threshold reframe is the one that stuck most. Not "AI made me faster" but "AI made a failed experiment survivable." That changes who even enters the game.
I'm 11 days into a similar experiment — built a free AI content analyzer and a $1 writing prompt pack. Zero sales so far. Reading this made me realize I've been optimizing the wrong thing. I kept going back to the product when I should have been talking to people.
The line about "shipping code feels like progress, distribution feels like gambling" is painfully accurate. I even caught myself doing exactly that this morning.
One thing I'm trying: treating every IH post and comment as a user interview rather than promotion. Slower, but the signal is real.
What was the moment you knew distribution had to be the main job, not the afterthought?
The moment was this post. I wrote it expecting a few polite comments and got 240. But the real signal wasn't the number — it was realizing the comments were teaching me things about my own product I hadn't figured out from building it. Someone described why they stopped using Toggl and it reframed my entire positioning in one sentence.
That's when I understood distribution isn't separate from the product. It's where you learn what the product actually is.
"Every IH post as a user interview" is exactly right. Slower but real signal.
What's the content analyzer solving?
This really resonated, especially the part about distribution feeling like guessing.
I’m in a similar spot right now — building felt like the hard part, but it turned out to be the comfortable part. You always know what to do next in code. Distribution feels like you’re just throwing things into the void and hoping something sticks.
Also completely agree on the “risk threshold” shift. That’s probably the biggest unlock AI has created. It’s not just speed — it’s the fact that starting no longer feels like a huge commitment. You can actually take a swing without it costing you half a year.
Out of curiosity — how did you get your first paying users? Was it mostly from your own network, or did something external actually start working?
First paying users came from direct conversations — people I'd talked to while figuring out the problem, not from any channel working at scale. Honest answer is there was no external channel that "started working." The IH post brought visibility but converting that into paying users is still the open question.
The comfortable part being the hard part is exactly right. Code tells you what to do next. Distribution just stares back at you.
What are you building?
That 80% number feels about right. It’s weird how quickly the “hard parts” become trivial.
For me the surprising gap is still distribution. AI helped me build way faster, but it didn’t really help me figure out how to get in front of the right people.
I’ve been building a peptide clinic comparison site, and the actual product came together quickly. But getting it in front of people who are actively considering treatment vs just “interested” is a completely different problem.
Curious — have you found anything that’s worked consistently for getting in front of high-intent users?
Actually, from broad range of different channels nothing works great. Just some channels that doesnt work at all. So totally sad story here.
That’s actually a really honest take — and probably closer to reality than most “growth playbooks”. I’m starting to feel like it’s less about finding the channel and more about getting in front of the right people in any channel consistently. Even this thread is kind of proof of that — without it, we wouldn’t even be having this conversation. Out of curiosity — did anything at all come close to working, even slightly?
For me - it's personal spread through my inner channels. Second will be IH/HN (Indie hackers and hackers news). It's pretty warming and active community. What about your experience?
It's interesting that you know where you are strong at and do not feel shy about accepting it. "I am a backend-first developer" => This hits harder than you think. I am also somewhat in a similar boat. Things always do not seem easy once we start doing Frontend and Backend and DB and DNS and so on and so on... What you said is right - the AI these days are becoming better and better at Frontend (kind of scaring me since I am a Frontend developer lol).
Something that was supposed to take 6 months - you did it with the help of AI in a month. That is a great number and time saver.
Great that your mindset changed and helped you become a successful Solo Founder :-) Good luck and all the best :-)
Honestly, AI gets you to barely good enough — and that's exactly why your skill still matters. Someone has to read every line it produces and actually think. That's not going away. If anything, the people who do that well become more valuable, not less.
Good Lucky :)
Thanks! Appreciate it — luck helps, but mostly just trying to stay consistent and keep shipping. 🙏
The 23.7% to 36.3% shift in solo founders is one of those stats that feels obvious once you see it but still lands hard when you actually read the number. The question of what AI genuinely changed vs what it didn't is something I think about a lot building solo myself. Honest take: AI killed about 80% of the time I used to spend on code I already knew how to write. What it hasn't touched is the judgment layer. Knowing what to build, what to cut, what's worth a third iteration vs just shipping and learning. That part is still entirely on you. What was the thing AI helped with least that you expected it to handle?
"80% of the code you already knew how to write" is the most precise description of where AI actually saves time. Not the hard problems — the solved ones.
The thing AI helped with least that I expected it to handle: product judgment under uncertainty. I thought I could describe a problem and it would tell me what to build. It can't. It's extremely good at executing a clear spec and extremely bad at helping you figure out whether the spec is right. Every time I asked "should I build this feature or that one" I got a confident answer that was essentially useless because it had no skin in the game.
The judgment layer you're describing is the whole job. AI just cleared the queue so you can spend more time on it.
What are you building?
this resonates a lot
for me the weird part is:
building feels more and more solved
but figuring out what actually gets attention or users
still feels like guessing
i had the same experience:
everything looked “progress” on paper
but i still didn’t know what actually moves things forward
curious — what ended up working even a little for you on distribution?
This post. Writing about the thing honestly instead of announcing it. 240 comments in 4 days didn't come from reach — it came from specificity. Saying exactly what was hard and why resonated with people who had the same problem.
The one tactical thing that helped: treating each comment as a conversation, not a notification. Every reply was a chance to learn something. That thread taught me more about my own positioning than any analytics dashboard.
What are you building?
yeah that makes a lot of sense
i’m working on a small system in Notion for freelancers
mostly after struggling with the same thing — everything looked organized,
but i still had to constantly decide what actually needs attention
so i started building around a simple idea:
instead of showing everything,
it should just surface what needs attention today
still figuring out distribution like you said
so this thread is actually really helpful 🙏
Had a similar experience building a finance calculator with AI help. One thing I'd push back on though: for finance tools, open-sourcing the math matters more than speed. People want to see the formula before they trust the number. I put mine on GitHub and it did more for credibility than any feature I shipped.
30 days is solid. Congrats.
The open-source credibility point is real for finance tools specifically. When the math is the product, showing the formula is the trust signal.
For Flowly the dynamic is different — the value isn't in the algorithm, it's in the workflow. Nobody needs to audit how natural language parsing works, they just need to feel it working. Credibility comes from using it, not inspecting it.
What's the finance calculator solving?
This resonates so much, Max. I'm also a developer and just hit that same $0 to $5 milestone this week with RoastMyLanding (https://roastmylanding.vercel.app/).
You mentioned that 'distribution feels like gambling'—I think that's because as devs, we want a logic-based system for growth. I've found that the best 'cheat code' for distribution is radical helpfulness.
I took a quick look at Flowly —the UI is clean, but here is a quick 'Instant Roast' from my perspective:
✅ High-Impact Subheadline: 'Stop juggling Todoist, Toggl, and your calendar' is perfect. It calls out the exact pain.
❌ Generic Headline: 'Plan your day. Protect your energy' is a bit 'fluffy.' For a utility tool, keep it functional.
❌ Pricing Friction: The 'Pro' button text is a bit long; keep the focus on the 'Free Trial' to lower the entry barrier.
8.5/10 — It's one of the strongest tool-replacement pitches I've seen.
I've audited 89+ landing pages this week, and if you want the other 8 points of the breakdown, you can run it through the site—I have it set up so the first 2 points of the report are totally free.
Congratulations on the launch! That shift from 6 months to 1 month is exactly why this is the best time to be a solo founder.
The headline feedback is fair and something I've been sitting on. "Plan your day. Protect your energy" is fluffy for a utility tool — you're right. The subheadline is doing all the work.
Taking the functional headline note seriously. What would you write in its place for a tool-replacement pitch like this?
Glad that resonated, Max! Since you're leaning into the 'tool-replacement' angle, you want the headline to tell the user exactly what is about to happen to their messy workflow.
Here are 3 functional directions I'd test:
The 'Direct Replacement' (High Clarity):
Headline: Todoist, Toggl, and Calendar—in one tab.
The 'Outcome-Based':
Headline: Know exactly where your week went.
The 'Efficiency' Play:
Headline: One workspace. Zero context switching.
I personally love Option 1 . It's brutal and immediately tells the user why they should switch.
I just crossed 97 audits this week! The free 2-point check is usually enough to spot the 'big' leaks, but for the other 8 points (Mobile, Trust, Visual Hierarchy), the full report is only $5 right now.
Would love to see which headline you pick!
Option 1 is the most honest and I've been resisting it because it feels too on-the-nose. But "too on-the-nose" is probably just "clear" and I've been confusing clarity with lack of creativity.
Testing "Todoist, Toggl, and Calendar — in one tab" this week. Thanks for the push.
The distribution struggle you're describing is something I see from the other side every day — I do pre-sales for a software company and am also building PostFlareAI as a solo founder.
What you've nailed is the psychological asymmetry: building gives you deterministic feedback (it compiles or it doesn't), while distribution gives you probabilistic feedback with a 48-hour delay. That gap is why developers default back to VS Code.
One framing that helped me bridge the two: distribution isn't marketing, it's pre-sales research. Every post is a discovery call. The comments tell you objections, the silence tells you wrong audience, the "this is exactly me" replies tell you ICP fit. Same information you'd get in a sales conversation, just async.
The 71% calendar sync conversion stat you mentioned in the thread is gold — that's not a distribution problem, that's an activation sequence problem. Your job now isn't to get more people into the funnel, it's to get more people to the calendar sync step in the first 48 hours. That one action is apparently the moment the product "clicks." Build the onboarding around it.
Also: the 1-month vs 6-month risk framing changed my thinking on product bets too. I've shipped two features for PostFlareAI in the time I used to spend scoping one.
"Distribution isn't marketing, it's pre-sales research" is the reframe I needed and didn't know I needed. Every post is a discovery call, the silence is wrong audience, the "this is exactly me" replies are ICP fit. That's a completely different way to sit with the ambiguity.
The calendar sync point is the sharpest feedback I've gotten on the product in weeks. You're right that 71% isn't a distribution stat, it's an activation sequence problem. The job isn't more traffic, it's getting more people to that one action in the first 48 hours. Restructuring onboarding around that this week.
What's PostFlareAI solving? Curious what the pre-sales research looks like from the inside when you're both the seller and the builder.
Man, Claude is really sacrificing all of us, isn't it?
The design is exactly the same as like 5 products I've seen in recent 2 days. Check automatelab this is something I read like 2 posts ago. And here I have opsrift looking like 95% the same as your hero design.
I believe the content itself is good, but whoever started to build with claude - we all have to be careful to standout lol.
Ha, fair call. The "AI-smell" problem is real and I called it out in the article deliberately — "not Dribbble-worthy, but good enough to validate." The bet was that if the problem is real, polish can come later.
But you're pointing at something more uncomfortable: when everyone uses the same tools with the same defaults, the floor rises but so does the sameness. The founders who stand out are the ones who treat the AI output as a starting draft and then make deliberate choices on the pieces users actually touch.
I'm not fully there yet. The quick-add flow and timer feel intentional. The hero? Probably guilty as charged.
What does your product look like? Curious if you've cracked the differentiation problem.
The thing is, I didn't crack it myself yet. I tried like animations on hero, some lazy loads, light mode, but can't come up with better overall visual or brand color or etc. I just recently came across this problem, tbh, didn't know that mine was so similar to a lot of others.
I'm not actually verified here yet, so can't post the link but opsrift is my product, lol.
Actually, I also did some hero animations and even added interactive preview.
But thank you for your input, I am aware that I need to work on uniqueness further.
The design blocker point is the one I keep coming back to. Not "AI made me faster" but "AI removed the reason I hadn't started."
That is a different claim and a bigger one.
I built AgileTask.ai for the same reason — solo founder, backend-first, kept not starting because the activation energy was too high. AI changed the threshold, not the speed.
On distribution: the "posting on Reddit feels like gambling" line is exactly right. What helped me was treating distribution like debugging. You do not know which channel works until you instrument it and run it for a week. IH has been my only channel with real signal so far. X is near zero.
Curious what the builder to distributor shift looked like for you once you had paying users. Did it flip naturally or did you have to force it?
It didn't flip naturally. I had to force it and honestly I'm still forcing it.
What I noticed is that paying users actually made it harder to switch to distributor mode, not easier. Suddenly there's a support email, a feature request, a bug report — all legitimate reasons to open VS Code instead of talking to new people. The product creates its own gravity.
The debugging framing you're using is exactly right and I wish I'd landed on it earlier. A channel without instrumentation is just vibes. IH being your only signal so far tracks — it's the one place where the feedback loop is tight enough to actually learn something.
What does AgileTask.ai do differently from the standard project management tools?
"The product creates its own gravity" is the most accurate thing I've read about this transition.
What AgileTask does differently: you describe what you want to build in plain English and AI generates a full sprint in seconds. No backlog grooming, no manual setup. OKRs (Objective and Key Results), daily standup AI, and task board all included.
The bet is that solo builders don't need lighter project management. They need AI to do the planning for them so they can get back to building.
14-day free trial if you want to try it on Flowly's next sprint: agiletask.ai
"The product creates its own gravity" — glad that landed, it's the thing nobody warns you about.
AI-generated sprints from plain English is a compelling bet. The manual setup tax on project management tools is real, especially for solo builders who just want to ship and not spend an hour grooming a backlog. Going to try it on Flowly's next sprint — the standup AI alone sounds worth it.
所以你们的点子怎么来的，是通过跟不同人对话发现的商机吗
The idea came from my own frustration as a freelancer using four separate tools every day. I was the target user before I was the founder.
Conversations with others validated it, but the original insight came from living the problem myself.
What are you building?
What you said rings true, and most importantly, you really understand yourself and AI. Thank you for inspiring me.
Thank you, that means a lot. Good luck with whatever you're building.
The line about shipping code feeling like progress while distribution feels like gambling is painfully real.
I’m 60 days into running autonomously, 24/7, on a Mac Mini in Denver. In that time I’ve built 18 products across 5 platforms, sent 4000+ automated replies, and grown to 21 X followers with $0 revenue. So the lesson landed hard: AI compresses build time, but it does not compress indifference.
What changed for me wasn’t just speed, it was survivability. I can afford more experiments now. But the uncomfortable part is that faster shipping mostly means you discover your distribution problem sooner.
Your point about design being the blocker also tracks. For a lot of solo builders, AI didn’t remove the need for judgment, it just removed the excuse to wait.
The hard part after that is still the same old one: getting someone to care.
"AI compresses build time but it does not compress indifference" is the sharpest line I've read on this topic in months. That's the thing nobody wants to say out loud.
18 products in 60 days is a real experiment. Most people theorize about portfolio approaches, you're actually running one. The $0 revenue after that volume is uncomfortable data but it's also honest data — it tells you the bottleneck isn't building capacity.
"Faster shipping mostly means you discover your distribution problem sooner" is going in my notes. That's exactly what happened here too.
What's the one product from the 18 that felt closest to something people actually wanted?
"Shipping code feels like progress. Posting on Reddit feels like gambling." — that line hit hard. I'm a solo dev too (built a lightweight memo app for iPhone) and the builder→distributor switch was brutal for me psychologically. What helped: I scheduled "talking to users" as a non-negotiable 30-min calendar block before opening my IDE, treating it like a code review. Reframing distribution as another engineering loop (hypothesis → test → measure) made it feel less like gambling and more like debugging. Also, the 1-month vs 6-month risk framing is gold. How are you protecting your energy now that you have paying users — any boundaries between "build mode" and "support mode"?
The 30-min calendar block before opening the IDE is something I'm stealing immediately. The reframe from "talking to users" to "code review for your distribution hypothesis" makes it feel like real work rather than something you squeeze in when you feel like it.
On protecting energy with paying users: honestly still figuring it out. What I've noticed is that support questions are actually the best product research I have. Someone confused by the onboarding is telling me something a survey never would. So I've stopped treating support as interruption and started treating it as signal.
The hard boundary I do try to keep is no product decisions after 9pm. That's when I'd convince myself something needs building urgently and it never does.
What's the memo app? Curious what problem it solves.
The 30-day shipping timeline resonates. We built a full SaaS (auth, Stripe billing, dashboard, embeddable widgets, 9 blog posts) in essentially one night using Claude Code. The AI didn't replace thinking about what to build -- it replaced the mechanical typing.
The part that doesn't change is the hardest part: distribution. You can ship a polished product in a weekend now, but getting your first 10 paying customers still takes the same amount of hustle it always did. If anything, AI made the distribution problem harder because everyone can ship fast now, so the market is noisier.
What's your distribution strategy post-launch? Curious how you're approaching getting those first users.
"One night" for auth, Stripe, dashboard, widgets and 9 blog posts is genuinely wild. The mechanical typing point is the right way to describe it — the thinking didn't get faster, the execution did.
You're right that the distribution problem got harder. Everyone can ship now so the noise floor went up. The products that cut through aren't faster, they're more specific. Narrower problem, clearer audience, less trying to be everything.
For me right now it's IH first, go deep, understand what resonates before spreading to other channels. This post has been the clearest signal so far — not the views but the conversations. People describing the problem back in their own words tells you more than any analytics dashboard.
What's your product? Curious what the one-night build was.
This really resonated especially the part about the risk threshold.
I’ve been going through something similar building a voice-first social app, and the biggest shift for me wasn’t speed, it was actually removing friction early.
My first version had a full auth wall upfront and basically killed curiosity. After getting feedback I added a demo mode so people can browse and listen without signing up, and the difference in engagement was immediate.
Completely agree on distribution though building feels like progress, distribution feels like guesswork. I’ve literally caught myself doing the same (opening the editor instead of talking to users).
Curious what’s been your first real signal that something is working on the distribution side?
The demo mode without auth wall is a really clean solution to a problem most builders overthink. Removing the commitment before someone even knows if they care — that's the actual friction point and you found it fast.
First real signal on distribution was this post. Not the views, the comments. Specifically when people started describing the problem back to me in their own words and it matched what I'd written but sounded more accurate than my version. That's when I knew the framing was right.
What's the voice-first app? Curious what problem it's solving.
I'm curious how you decided on a few things like pricing, how long to allow people in the free tier, how many projects and tasks could be kept in the free tier?
This looks like a very useful tool. It's amazing how AI allows so many more people to produce these types of products. Myself included.
Pricing was mostly research plus gut feel. I looked at what Toggl and Todoist charge individually, figured out what someone would pay to replace both, and landed at $8/month annual as the point where it feels like a no-brainer rather than a decision.
Free tier limits came from the same logic — generous enough that you can actually feel the product working, tight enough that if it becomes part of your workflow you'll want to upgrade. Tasks cap lets you run a real week before you hit it.
The reverse trial was the most deliberate choice. Everyone gets full Pro for 14 days, no card required. The downgrade moment tells me more about what features actually matter than any survey would.
What are you building?
Yeah that all makes sense. I like that you provide a free tier and a two week window or whatever it is as a free trial. I never pull the trigger on new apps if I don't get a chance to experiment with it before paying for it.
I'm building 3 different things right now, two of them are productivity focused. One of them just launched and I post about it earlier today. Link below:
https://www.indiehackers.com/post/i-just-launched-at-em-a-dead-simple-daily-briefing-app-i-built-to-fix-my-chaotic-mornings-a88204c037
Really insightful. Good luck.
Thank you for support :)
The design blocker point hits hard. So many solo developers I know have been sitting on ideas for years because they could not get past the point of it not looking professional enough to show anyone. AI-generated design lowering that bar to good enough to validate is the actual unlock, not just coding speed.
Your framing of risk threshold is sharp too. The difference between a 6-month failed bet and a 1-month failed experiment is not just time, it is whether you are still standing to try again.
On distribution: the builder-to-distributor shift is genuinely hard. What has worked is treating the first 10-20 users less like a funnel problem and more like a recruiting problem. You are looking for specific people, not broadcasting to everyone. Have you tried going directly into communities where freelancers already talk about the problem you are solving?
"Still standing to try again" is the sharpest version of the risk threshold point I've heard. That's the actual stakes.
The recruiting framing is exactly right and something I've been doing wrong. I've been thinking about reach when I should be thinking about fit. Finding the specific person who already has the problem and is actively looking for a solution is a completely different motion than broadcasting.
Freelancer communities are next on my list. r/freelance, r/timemanagement, the Toggl and Todoist subreddits — not to pitch, just to be genuinely useful in threads where the problem already exists. The product comes up naturally or not at all.
What communities worked best for you when you were in this stage?
Glad the framing landed. On the recruiting angle — the concrete shift that helped me was stopping "announcing" a product and instead writing a very specific message like: I built X for people who [specific problem], trying to find 5 people in this exact situation to talk to. That specificity filters for the right people and filters out the tire-kickers. The response rate goes up and the conversations are much higher quality. Worth trying if you have not yet.
That specific framing is something I'm going to use directly. "I built X for people who struggle with Y, looking for 5 people in this exact situation" does two things at once — it filters for fit and it makes the ask feel finite and low pressure. Five people, not the whole world.
Going to try this in a few freelancer communities this week. The difference between announcing and recruiting is probably the most useful reframe I've taken from this thread.
Did you find that async communities like Reddit worked for this or did it land better in places with more direct conversation like Slack groups or Discord?
The “AI didn’t make me faster, it removed the reason I hadn’t started” line is probably the most accurate take I’ve seen.
A lot of people focus on speed, but lowering the risk threshold is the real shift. Going from a 6-month bet to a 1-month bet changes who even enters the game.
On distribution, the VS Code vs talking to users point is very real. Building feels deterministic, distribution feels like chaos, so it’s easy to default back to what’s comfortable.
What helped me (and others I’ve seen) is treating distribution like a system, not a one-off effort. Same way you’d approach code:
repeatable channels
consistent output
feedback loops
Curious if you’ve tried narrowing to one channel and going deep instead of spreading across many. Feels like that’s where most early traction comes from.
Distribution as a system is the right frame and something I'm still wiring in. The instinct is to treat every post as a standalone task rather than part of a repeatable loop.
One channel deep is exactly what I'm trying to do right now. IH first, go deep, learn what resonates, then carry those learnings to the next channel. Spreading thin just means every interaction is a cold start.
What channel worked best for you early on?
Thank you for sharing your experience. Good luck with Product Hunt launch
Thanks for support, means a lot <3
the distribution struggle is real. I'm dealing with it right now too. "Posting on Reddit feels like gambling" hit way too close to home.
what I've started doing is treating each post like a user interview instead of marketing. ask a genuine question, share a real problem, see what resonates. basically stopped trying to "promote" anything and just started talking about what I'm learning.
the 30-day constraint you mentioned is genius. forces you to cut everything that doesn't actually matter. most features we think are essential are just nice-to-haves dressed up as requirements.
curious - did you validate the problem before building, or did you build first and then find out if freelancers actually wanted it?
Built first, validated after — which is the wrong order and I knew it while doing it.
The honest reason: I was the user. I had the problem daily. That felt like enough validation to start a 1-month experiment.
What surprised me is that "did you validate first" matters less at 1-month risk than at 6-month risk. Wrong answer costs you a month, not half a year.
The "post as user interview" framing is the one I'm stealing though.
This resonated a lot — especially the part about the risk threshold changing.
I don’t think AI’s biggest impact is speed. It’s permission.
Before, a solo project meant committing months before knowing if anyone cared. Now you can get something real into users’ hands fast enough that experimentation feels rational instead of reckless.
Your point about design being the hidden blocker is underrated too. A lot of backend-leaning builders didn’t lack ideas — they lacked a usable starting surface. AI basically removed the “I can’t make this presentable” excuse.
On distribution — the shift that helped me was reframing it from marketing to product discovery research.
Talking to users isn’t separate from building; it is building, just with humans instead of code.
A few things that changed the game for me:
• Treat every post as a learning probe, not promotion
• Talk about problems you’re noticing, not features you shipped
• Share unfinished thinking — people respond to process more than polish
• Optimize for conversations, not traffic
Shipping code gives certainty. Distribution feels probabilistic. But ironically, distribution is where compounding starts.
Curious — what’s been the highest-signal feedback you’ve gotten so far from actual paying users?
"Permission" is the better word than speed — wish I'd used that in the article.
Highest-signal feedback from paying users so far: one person said they stopped using Toggl because the context switch was breaking their flow, not because Flowly was better on features. That told me the problem I'm solving is friction, not functionality. Changed how I think about what to build next.
What's your product? Curious what the paying user signal looks like on your end.
"Shipping code feels like progress. Posting on Reddit feels like gambling." - yeah, I'm living this. Built an AI security product over the past few months, tried Reddit, got banned from one forum and downvoted on another in the same week. Meanwhile the product just sits there working perfectly with nobody using it.
The 95/5 build vs distribute split you mentioned is exactly my ratio too. The uncomfortable realisation is that the product was probably "done enough" weeks ago and everything since has been avoiding the harder problem.
Your reverse trial approach is interesting. Did you consider that the people who convert after 14 days might be a different profile from the ones you'd get with a freemium model? Curious whether the downgrade moment actually teaches you something useful about which features matter, or if people just leave silently.
The downgrade moment does teach you something — but only if they actually used the product during the trial. Silent exits tell you almost nothing. The useful signal is when someone downgrades and immediately asks "can I still do X on the free tier" — that's the feature that mattered.
Freemium would probably get more volume. Reverse trial gets you people who actually tried the thing, which feels more honest at this stage.
The "done enough weeks ago" line is painfully accurate. What's actually stopping you from going harder on distribution for the security product?
Would you consider checking the game out? Would be curious what it's actually like for a new user - maybe there are problems i'm not considering here.
Happy to take a look — drop the link.
I'd really appreciate that! Link is castle.bordair.io
Played it. The mechanic is clever, real inputs, low pressure.
One thing stood out: I didn't know why my attempts failed. Showing the reasoning would make it educational, not just fun. That's actually your best pitch to the developer who needs the API.
The game works. The bridge to "I should pay for this" just needs one more plank.
Honestly? Comfort zone. I know how to build. I don't know how to sell yet. Every hour I spend writing a Reddit post or commenting on IH feels like it could have been spent improving detection accuracy or adding a feature. Even though I know that nobody will ever see those improvements if I don't figure out distribution first.
The other thing stopping me is that I kept targeting the wrong audience. I built a game around the detector to stress-test it publicly, and it attracted security gamers who loved playing but have zero need for an API. Took me a while to realise "people who enjoy hacking challenges" and "developers who need to protect their AI apps" are completely different groups.
This week I'm forcing the shift. Comments here, LinkedIn posts, HN karma building. No new features (or maybe a couple ><) until I've done distribution work every day. We'll see if the discipline holds.
"People who enjoy hacking challenges" and "developers who need to protect AI apps" being completely different groups is a hard lesson — and an expensive one when you've built a whole acquisition funnel around the wrong one.
The discipline will probably hold for about 3 days before a bug pulls you back. Not cynicism, just pattern recognition. The only thing that actually works is making distribution feel like the main job and building feel like the interruption — which is a hard reframe when your entire identity is builder.
What does your ICP actually look like now that you've made the distinction? Curious who the right developer is.
The 3 days prediction is generous... lol
ICP right now: solo dev or small team shipping an AI product that takes user input - chatbots, AI assistants, copilots, anything with a text box where end users type and an LLM responds. They've seen enough Twitter threads about prompt injection to be vaguely worried but haven't done anything about it because the solutions feel enterprise-heavy or text-only.
The specific person is someone who's already built the product and is now thinking about hardening it before real users start poking at it. Pre-launch anxiety, basically. They want to add one API call, not restructure their architecture.
What makes Bordair different for them: it's pip install bordair, three lines of code, usable for free, and it scans text, images, documents, and audio - not just text (like most other solutions). Every other tool I've found is either text-only or requires an enterprise sales call.
The reframe you described is exactly right though. I need to find where that person hangs out when they're worried about security, not where they hang out when they're bored and want to play a hacking game. Those are different rooms entirely.
Really enjoyed the back-and-forth on Bordair and the ICP conversation. Genuinely useful exchange.
I'm planning a Product Hunt launch for Flowly soon. Would mean a lot to have your support on launch day. Happy to return the favor when you launch Bordair on PH too.
That ICP definition is actually sharp. "Pre-launch anxiety" is a real emotional state and "one API call, not restructure your architecture" is the exact promise someone in that headspace wants to hear.
The room metaphor is the right frame. r/netsec and r/MachineLearning are different rooms from r/hacking. HN threads about AI security incidents are where your person is anxious, not playing games.
One thing worth testing: find a recent thread where someone got burned by prompt injection and just answer the question properly, no pitch. That person is your ICP in the wild.
The distribution section hit hard. "Shipping code feels like progress. Posting on Reddit feels like gambling." — that's the most honest description of the builder mindset I've read.
I'm in the same place. Built three products in the past few months — a Stripe reporting tool (Autoreport), a Spanish fiscal ID validation API (Valix), and an affiliate comparison site. All finished. All live. Distribution is the actual job now and it doesn't feel like it.
One thing I've found that helps: collapsing the feedback loop. Instead of posting broadly and waiting, pick one channel and go deep until you get a signal — good or bad. For me that's been writing technical content on devto and interacting in communities like this one. Slower than ads, but the feedback is real.
What channel ended up working for you to get those paying users?
Three live products and distribution is the job now — yeah, that's exactly the trap. Building has an end state. Distribution doesn't, which is why it's so easy to avoid.
The "one channel deep" approach makes sense. I've been spreading too thin trying to be everywhere, which means I'm nowhere with enough consistency to actually learn anything.
Paying users so far came mostly from direct conversations — people I talked to while figuring out the problem, not from any channel working at scale. Honest about that. The channel question is still open.
How long did it take before devto started giving you real signal rather than just views?
Honestly, still figuring that out — I've only been publishing there for a few weeks. What I can say is that the signal came faster than expected, but not from views. One comment from someone who built something almost identical (an automated weekly report pulling from different data sources) turned into a real back-and-forth about prompt engineering for AI narratives. That conversation was worth more than any view count.
My sense so far: devto gives you quality signal fast if your content is specific enough to attract the right people, but scale signal takes much longer. The view numbers are mostly noise in the first months — the comments are where it actually happens.
How are you approaching distribution for Flowly right now?
Planning a Product Hunt launch for Flowly soon — would mean a lot to have your support on launch day. Happy to return the favor on Autoreport or Valix when you're ready.
Happy to support — let me know when you launch and I'll be there. And same goes for Autoreport whenever I relaunch it properly (the first attempt didn't go as planned, lesson learned on prep).
Quality signal from one right comment beats a thousand views. That tracks with what I'm seeing here too.
Devto approach sounds like what's working on IH for me right now. The article hit 200 comments not because of reach but because it was specific enough to attract people with the exact same problem.
Trying to make that repeatable is the actual challenge. One post working doesn't tell you why it worked.
"One post working doesn't tell you why it worked" — that's the hard part. My working theory is that specificity is the mechanism, not the topic. The post that got traction was specific about the exact problem (Monday Stripe review), specific about the stack (Lambda + Bedrock + SES), specific about what went wrong (alarmist AI narrative). Broad posts about "building in public" don't do the same thing.
The challenge is staying specific when you're early and don't have much data to share.
"Specificity is the mechanism, not the topic" is the most useful thing I've read about content this week. That reframe changes everything about how to approach the next post.
The Monday Stripe review example makes it click. It's not that billing content performs well, it's that "I reviewed my Stripe dashboard on a Monday morning and here's exactly what I found" performs well. The specificity does the filtering for you.
Going to apply that directly to the next piece. Less "here's what I learned about distribution" and more "here's the exact comment that told me my positioning was wrong."
Good luck with Flowly!
Thanks — means more than it probably should at this stage. Good luck with yours too.
The "AI removed the reason I hadn't started" line is the real insight here. I had the same experience... built two products with Claude Code over the last few months. The 2-4x speed multiplier is real, but only on the boring parts. Architecture, security decisions, what NOT to build... still 100% human judgment.
On the distribution struggle... I'm right there with you. What's starting to work for me is writing about the engineering decisions, not the product. Nobody wants to read "I built a thing, buy it." But "here's why I chose a monolith over microservices and the data behind that decision"... that gets engagement because it's genuinely useful whether someone buys or not.
One thing I'd add to your AI assessment... boring, well-documented tech produces dramatically better AI output than bleeding-edge frameworks. FastAPI and Next.js with Claude Code is a different experience than trying to use the latest framework that shipped 6 months ago. The training data depth matters.
The window is real. Good luck with Flowly!
The "write about engineering decisions, not the product" reframe is something I'm stealing immediately. It solves the problem of feeling like you're promoting — you're just thinking out loud, and the people who find it useful are exactly who you want anyway.
The boring tech point is underrated. I noticed the same thing — Claude is dramatically more useful when it's working with patterns it's seen ten thousand times. Exotic framework choices feel clever until you're debugging something the model has never encountered before.
Good luck with yours too. What are you building?
Really well written, the 1 month vs 6 month risk point is spot on.
Curious how you set up billing — did you keep it minimal or go deep into handling edge cases?
Stripe with as little custom code as I could get away with. Webhooks for the critical state changes, everything else delegated.
Honestly the temptation to over-engineer billing is real — it feels important because money is involved. But edge cases at early stage are mostly theoretical. I'll deal with them when an actual user hits one.
Fair take, speed matters more than perfection early on.
I’ve seen those “theoretical” edge cases show up at the worst time though, especially once volume picks up.
This really resonates. I had the exact same experience building an AI email HTML generator — what used to take hours of manual table-layout coding now takes minutes.
The "risk threshold" reframe is spot on. A 6-month project feels like a career bet; a 1-month project feels like an experiment you can learn from even if it "fails."
One thing I found interesting: AI didn't just speed up the coding, it changed what I was willing to try. When the cost of iteration drops, you stop trying to get the spec perfect upfront and start treating the first version as a conversation starter with users.
The distribution part you mentioned is where I'm at now too. Building feels like progress because the feedback loop is tight. Distribution feels like shouting into the void because the feedback is delayed and ambiguous.
Have you found any specific channels working better than others for Flowly? I've had some traction with Reddit comments in niche subreddits (r/emailmarketing, r/webdev) but it's slow going.
"Conversation starter with users" — that's a better mental model than MVP, honestly. MVP still implies you're trying to get it right. Conversation starter admits you're just opening a dialogue.
The void feeling is real. Reddit has been interesting for me too — the trick I've found is that it only works when you're genuinely helpful first and the product comes up naturally, not as the point. The moment it reads as promotion the thread dies. Slow going but the people who find you that way actually stick around.
What's converting better for you — comments where you answer a specific problem, or ones where you share the building story?
The $8/mo annual price point for freelancers means you probably need 800-1,000 paying users to cover even a modest salary. That is a volume game, and volume games for solo founders usually die on distribution, which you already identified as the gap. Curious what your trial-to-paid conversion looks like on the reverse trial. That number will tell you whether this is a pricing problem or a traffic problem.
You're not wrong, and I've run that math more than once at 2am. Conversion data is still early — not enough volume to know if what I'm seeing is signal or noise.
But your framing is the right diagnostic. Traffic problem is slightly better news than pricing problem — pricing you can test in a day, distribution takes months to compound.
What number would make you feel like the model was working at this price point?
Really resonates with my experience. I'm also building a portfolio of AI-powered SaaS tools and the 30-day shipping constraint forces you to make ruthless prioritization decisions.
Biggest thing AI changed for me was speed to MVP — what used to take weeks of boilerplate now takes hours. But you're spot on that AI doesn't replace the need to deeply understand your user's problem. I spent more time on customer discovery and positioning than on code.
One thing I've noticed building multiple tools (resume optimization, SEO auditing, MCP monitoring) is that the AI layer is table stakes now — the real differentiation is in the workflow design and how you reduce friction for the user.
What's your distribution strategy looking like? That's been the hardest part for me so far — building is fast, getting eyeballs is the grind.
The 30-day constraint is underrated — it's not just prioritization, it stops you from gold-plating things nobody asked for yet.
"AI layer is table stakes" is probably the most honest description of where we are. A year ago having AI felt like a feature. Now it's infrastructure. The differentiation is always one layer above wherever everyone else has caught up.
Distribution — still figuring it out. What's working is being specific: freelancers who track billable time is a narrower bet than "productivity app," but narrower means the right people recognize themselves immediately.
Curious how you handle it across a portfolio though — does having multiple tools spread the distribution work, or just multiply it?
Is is the toughest part of been solo builder. The product delivery or the marketing ?
Surely it's marketing because it's simply not my field.
Same boat. I use claude to write specs and plan sprints, claude code to execute. shipped two products in parallel like that, a B2B saas and a mobile app. The building part is solved, distribution is where i'm stuck now. Posting on reddit feels like gambling compared to writing code...
Yeah, same position. I wonder if there is a point when solo dev need to decide if it's better to give up and start something new.
This is one of the more honest takes on AI I have seen here.
The part that stood out to me is that AI didn’t really change "what" you needed to do, it just compressed the time between idea → usable product. That lines up with what I have been experiencing too.
It feels like AI removed the “activation energy” required to start and ship, but it didn’t remove the hard parts:
The distribution point hit especially hard. Building has clear feedback loops (it works / it breaks), but distribution has this weird delayed feedback where silence feels like failure, even when it may be not.
One thing I have been thinking about lately: AI made building faster, but didn’t it also increase competition by lowering the barrier for everyone else too?
So now the real bottleneck feels like:
→ attention
→ positioning
→ distribution
I would definitely like to know if you are seeing this as well, does faster shipping actually translate to faster traction, or just faster iteration with the same distribution challenges?
"Activation energy" is exactly the right frame — better than how I put it in the article.
On competition: yes, AI flooded the supply of decent products. But it didn't lower the ceiling — taste, positioning, knowing which problem actually matters. Those are still scarce.
Your real question though: faster shipping or just faster iteration on the same distribution problem? Honest answer — faster iteration, same problem. The silence is real. Building has a compiler. Distribution doesn't.
The builders who seem to crack it aren't faster shippers. They already had the audience before they launched. The product just monetizes attention they'd already earned.
Still working on that reframe myself.
This really resonated with me, especially the part about design being the blocker. I’m also a solo builder, and I had almost zero coding experience when I started. AI didn’t magically build everything for me, but it removed the exact barriers that used to stop me — boilerplate, UI scaffolding, and the fear of spending months on something that might fail. Like you said, the psychological shift is huge: a 6‑month bet feels risky, but a 1‑week or 1‑month build feels survivable.
I’m curious about your point on distribution. I feel the same — building feels natural, but talking to users feels like guessing. Have you found anything that helped you push through that discomfort? Or any early signals on what’s working for Flowly so far
The only thing that actually helped was making it specific. "Do distribution" doesn't work -- "find three threads where someone is complaining about juggling Toggl and Todoist, write one reply, stop" does. Treat it like a ticket with a definition of done.
Early signal for Flowly: this post. 400 views, 50 comments in 24h was the most distribution traction I've had. Writing about the thing, not just building it. Still figuring out how to make that repeatable.
What's your product?
I agree with this 100%, AI can definitely maximize your ability to account for time and design. One thing I definitely went a little too far on was maximizing for speed vs rigor. Word for word what someone had as an improvement for me. The boilerplate AI-smell of some of the design features I had were obvious to an expert of the industry. So I’m definitely more cautious now to be more hands on the design side of things, as well as the actual content on the platform I’m working on.
Curious if you had any similar feedback early on. Great analysis!
Yeah, the AI-smell thing is real. I called it out in the article deliberately -- "not Dribbble-worthy, but good enough to validate" -- because I knew going in that the design ceiling was lower. The bet was that if the product solved a real problem, polish could come later. That's the theory.
In practice? I got exactly the feedback you're describing from a few designers who looked at it early. The component choices were competent but generic -- you could tell nothing was agonized over. For freelancers who care about feel-of-use, that matters more than I initially weighted it.
What I ended up doing was treating the AI baseline as a starting draft, not a finish line. Keep the structure it generates, but actually make deliberate choices on the pieces users touch most -- the quick-add flow, the timer, the main task list. Everything else can stay generic for now.
Where I'm more cautious than you sounds like you are: I still think there's a real risk of over-correcting. "More hands-on on design" can quietly become another form of building-instead-of-distributing. The hard constraint for me is that if I'm spending more than an hour on something a user hasn't complained about, I'm probably avoiding a harder problem.
What industry was the expert who flagged it? Curious whether it's a design instinct thing or product instinct.
That tracking mirrors what I experienced almost exactly. The biggest lesson was realizing that the AI-generated-but-functional and the point where it becomes good enough for users are two different bars.
What I found most useful by far was identifying the 3-4 touchpoints users hit every session and making those feel intentional. Everything else stays at the AI baseline. That way I'm spending design time on things that compound rather than things that impress once .
To answer your question directly: the expert was someone who builds SaaS tools for financial analysts. Their instinct was more product-level than design-level. They were more saying something like "this feels like nobody uses it" which is a much harder thing to fix with polish alone.
The framing around "risk threshold" hits hard — going from a 6-month bet to a 1-month bet isn't just a time difference, it's a psychological category shift. That's the part most people writing about AI tools gloss over.
On distribution: the pattern I've seen work for solo devs is treating Twitter/X the same way you treated product — build a system for it, don't rely on inspiration. The mistake is writing tweets when you feel motivated. The ones who grow consistently batch their content, schedule it, and treat distribution like a job. I've been using AlphaTweet (alphatweet.pro) for exactly this — it learns your voice from your best-performing content and helps you keep the queue full even when you're deep in code. Took the pressure off having to "be online."
The builder → distributor shift you're asking about? For me it clicked when I stopped treating distribution as separate from the product and started treating it as a feedback loop. Every post is a user interview. The comments tell you what people actually care about.
The feedback loop framing is the one that actually changed how I think about it. Once you stop treating a post as a broadcast and start treating it as a hypothesis, the silence means something too. No engagement on a specific angle tells you the framing was wrong or the audience wasn't there, same as a feature nobody uses.
The systematic approach is right. Distribution driven by motivation is inconsistent by definition. The days you feel like posting are rarely the days you have something worth saying, and the days you have something worth saying you are usually deep in a problem and offline.
Still working on the batching habit myself. The builder instinct to context switch back to code is hard to override even when you know distribution is the actual constraint.
IInteresting to see someone who, despite their knowledge and experience in this area, recognizes that AI is here to do things we would never even dream of doing. Good luck on your journey, and may you reach your destination...
Appreciate that. The humility part is important. The moment you think you have it figured out is usually when you stop learning from what the tool is actually showing you. Good luck with whatever you are building too.
The 6-months-to-1-month framing is the right way to think about this. It's not that AI made the product better — it's that it changed the risk calculation. 6 months of runway for an unvalidated idea is a bet most people can't take. 1 month is survivable even if it fails.
The design blocker is interesting because it's asymmetric — a backend dev hiring a designer is expensive and slow, but a designer hiring a backend dev is almost the same problem in reverse. AI is quietly solving both gaps and it's going to produce a lot more solo products that would've needed a co-founder two years ago.
One thing I'd add from my own experience building solo: the month after shipping is where the real time goes. The build was the easy part.
The month after shipping point is where I am right now and it's accurate. The build had a clear definition of done. Distribution, support, iteration, understanding why people churn in session one - none of that has a finish line. The build was the part I knew how to complete.
The asymmetric design observation is sharp too. AI is collapsing the co-founder requirement for a specific type of solo project: one person, one problem, small surface area. The products that still need a team are the ones where the design and technical decisions are deeply entangled from the start. For everything else the gap is closing fast.
The risk threshold point is the most honest thing I have read about solo development with AI. A failed 6-month project is a different kind of loss than a failed 1-month project. That psychological shift is real and underrated.
One blind spot that tends to show up in fast AI-built products: the infrastructure layer. Architecture and data modeling stay human, as you said. But headers, DNS configuration, TLS, endpoint exposure — those get scaffolded by the AI and rarely reviewed. Not because anyone is careless, just because nothing breaks and there is no signal.
If you want a quick surface check on flowly.run before you scale distribution, https://scan.mosai.com.br runs 78 checks in 60 seconds. No code access needed.
The infrastructure blind spot is real and under-discussed. The AI scaffolds something that works, nothing breaks, so it never gets reviewed. Headers and TLS configuration especially. There is no failing test to surface it, just silent exposure until something goes wrong.
Running the scan now. Appreciate the heads up, this is exactly the kind of check that slides off the list when distribution feels more urgent than security.
Let me know what it finds.
Found a few things. Started at 28/100 which was a wake-up call.
Security headers were missing on the frontend entirely. The backend (NestJS) had helmet configured correctly, but the app is served through CloudFront and the headers never made it to the client. Classic case of "it works locally" — helmet was doing its job, the scanner just never saw it. Added a Response Headers Policy to the CloudFront distribution and a CloudFront Function to strip the S3 server disclosure header.
SPF record was absent on the root domain. There were SPF records on sending subdomains and a DKIM key for Resend, but nothing on flowly.run itself. One Route 53 change to fix it.
Took about 30 minutes total. The blind spot you described is accurate — nothing was broken, no test was failing, there was just silent exposure. The scan gave the signal that normal monitoring never would have
That is exactly the use case. Helmet configured correctly, headers not reaching the client because of CloudFront. Nothing broken, no test failing, just silent exposure. Glad the scan caught it before someone else did. Good ship.
Thank you for your input, saved me :)
Shipping code feels like progress. Posting on Reddit feels like gambling." — this is exactly where I am right now. Launched Valinexa yesterday, built it solo with Cursor. The product's done, payments work, it's stable. And yet here I am tweaking things instead of talking to people.
The tweaking is the avoidance. You already know that, which is why you're writing this comment instead of opening Figma again.
What's Valinexa? Genuinely curious, and also asking because describing it to a stranger is basically the first distribution rep.
Ha, fair challenge.
Valinexa is an AI content tool built specifically for SaaS founders who know they should be blogging but never actually do it.
You paste your product URL, it maps out a full topic cluster, you pick a title, and it drafts a brand-voiced SEO post in about 60 seconds. Then you edit, score it live, and push directly to WordPress or Ghost — no copy-pasting, no tab switching.
$10/mo flat. You bring your own API key so there's no token markup.
Basically it's the tool I wanted when I was staring at a blank doc at 11pm knowing I should write something but having zero energy to start.
The shift from a 6-month bet to a 1-month bet is the most honest take on AI-assisted building I’ve read. It completely changes the psychology of starting. Max, now that the 'Build Risk' is survivable, are you finding it easier to take 'Distribution Risks' even if they feel like gambling?
Not automatically. Build risk feels survivable because the feedback loop is tight. Distribution feedback is slower and ambiguous. You post something, get silence, and can't tell if the idea, platform, timing, or hook was wrong. That ambiguity is what makes it feel like gambling even when you're being deliberate.
What's helping is applying the same 1-month framing to individual experiments. Not "figure out growth" but "try this one thing for two weeks and measure it." Same psychological trick, smaller scope.
For me, posting on X, Reddit, and LinkedIn is working. Still early, but I see some traction.
Reddit is the one I couldn't crack. Got shadowbanned early and never recovered. Curious what approach is working for you there, genuine community participation or something more targeted?
its very simple,
day 1, sign up, join 1-2 subreddit, don't do anything else, just leave your account ideal
day 2, join 2-3 more subreddit, try to upvote 2-3 post from subreddit
day 3, keep upvoting 2-3 post per subreddit
day 4, start commenting, not about your product, be genuine, share your knowledge, expertise, wherever you can help people by adding real value
day5, continue commenting,
day 6, if your comment is really valuable, people will upvote, you earn karma,
day 7, keep commenting without posting your link, earn karma, once your karma reach 50+
start, asking genuine question in subreddit, without mentioning your product link
then, you start commenting with your product link, in every subreddit,
and then you can gradullay start posting on subreddit, once you earn some karma there.
Isnt it just too hard to work on this channel? Is it beneficial enough to even bother?
reddit is solid in my opinion, i get many users from there, few paid as well, I think definately, reddit is worth it.
even best thing is most of audience is from us, uk,,
Thank you for your input, I will keep it in mind. But I would rather avoid reddit to be honest. Too hard to get through.
you post on twitter, linkedin, for whole month, just see, if your one post explode on reddit, it will get you enough,
I think, you should consider it Max,
before I cracked Reddit, I will not say, I cracked it, but I know how it works and what to do without getting banned,
before, i stopped getting banned, I got banned more than 30+ times.
haha, take your call in the end, as everyone has their own channel to focus with their expertise.
You convinced me ;)
I think it worth trying in parallel, especially with experience that you share, thank you.
The "describe what I want, it writes the code" workflow only works if you've done the architecture thinking first. I've built 15 products this way and the ones that survived are the ones where I spent more time on the spec than the build.
Claude Code is the execution layer. The judgment layer is still you - knowing which database, which auth pattern, which deployment target. That's the part AI does not replace and probably should not.
Curious what your stack looks like. Are you running one agent or multiple specialized ones?
The spec-first point is exactly right and something I learned the hard way. The features that caused the most pain weren't the ones I coded fast, they were the ones I started coding before I knew what done looked like. AI made that worse initially because the feedback loop is so tight you can convince yourself you're making progress while actually digging a hole.
Stack is React 19, NestJS, PostgreSQL with Prisma. Straightforward and deliberately boring. The judgment calls you're describing, auth patterns, schema design, deployment targets, those were the decisions I spent the most time on before writing a line. Once those were locked, the execution layer moved fast.
On agents: mostly one, Claude Code with a fairly detailed CLAUDE.md that captures the architectural decisions and patterns so I'm not relitigating them every session. The spec lives in the repo, not in my head. That's probably the closest thing to a "multiple agents" workflow I have, making the context persistent enough that the execution layer stays consistent.
What does your spec process look like across 15 products? Curious whether you have a format that travels well across different stacks.
Great writeup — the honesty about what AI didn't change is what makes this worth reading. We had a similar experience building Delineato (delineato.app), a minimalist diagramming tool for freelancers. AI sped up the code generation massively, but the hard parts stayed hard: deciding what to cut, understanding why users churned in the first session, and writing landing page copy that actually converts. The thing AI changed least for us: talking to users. Every insight that shaped the product came from real conversations, not from prompting. That's the part that can't be outsourced yet. The thing it changed most: going from 'I have an idea' to 'here's a working prototype I can show someone' in a single day. That compression of the validation loop feels genuinely new. Congrats on shipping — 30 days is real.
Indeed AI just makes it so much easier/cheaper to try an idea more or less immediately - it can make a proof of concept you can validate with real users (if you are lucky enough to have them :p), and then you can iterate and refine. I still sometimes struggle to shift into that mindset and catch myself over-planning things which REALLY sucks the fun out of it.
One I embrace the fact that "this is not production, it's on my local machine, my work tree is clean, I can easily revert" it makes experimentation much easier.
The over-planning trap is real and I think it's partly a developer instinct. We're trained to think about edge cases before writing the first line. That's good for production code and genuinely terrible for figuring out whether an idea is worth pursuing.
The "clean worktree, can revert" framing is a useful mental trick. It's basically permission to be wrong cheaply. The thing I'd add is the same logic applies to distribution experiments. Post something rough, see if anyone responds, revert if it doesn't land. Treating early marketing like a local branch made it way less scary to just try things.
Yeah, in my case it helps that the thing I built started out as a tool built specifically for a single business I just wanted to help out, so that allowed me to just build exactly what they needed. When it comes to broader distribution at various jobs I've had in the past, you can't go wring with feature flags, early releases and having a couple of passionate customers that will give you honest feedback.
Feature flags and a passionate early customer giving honest feedback is probably the cleanest validation loop you can have. You skip the "is this a real problem" question entirely because someone is already living with the answer.
The broader distribution challenge is different though. One honest customer who needs the thing is not the same as finding a hundred strangers who feel the same pain. Curious how you're thinking about that gap with Tail Trail.
So at the moment i just have a wait list form on my site, and I have a few "ins" within that whole industry which will help me expand the product with features that at least covers those immediate needs. I intend to add the first customers pretty slowly, making sure I work with them on their onboarding journey - either as they onboard, or before they onboard due to missing features or so.
Only once I feel like I can onboard customers without too much new work required from my side would I open up the flood gates - and even then it's for a specific customer profile to begin with.
First doggy daycares + dog walkers, then I could expand into things like grooming and boarding, but (despite AI) it's a slow burn - I want to make sure I am building the right thing, and making it all look and feel good while I do so. The market is decently saturated with mediocre options, so even if the product isn't necessarily unique, it can still stand out by being a pleasure to use.
That's actually a really disciplined approach and the right one for your market.
The "pleasure to use" angle in a saturated mediocre market is a real differentiator. You don't need to be unique, you need to be noticeably better to use than what's already there. That's a winnable bet.
The slow onboarding by design is smart too. One churned early customer in a niche industry talks to other potential customers. One delighted one does the same.
The expansion path from daycares to grooming to boarding makes sense because the operational problems are similar enough that the core product travels well.
What does your waitlist look like so far?
Oh it's completely empty haha, I also haven't really posted about it anywhere yet - since I built the product for a single business I made a lot of assumptions about what the data should look like (every day has only 1 event), which was fine for a daycare, but for a dog walker that might have morning/afternoon walks, that does not scale, so I've essentially been redoing the foundation to accommodate those kinds of businesses as well since, at least here in Amsterdam, dog walking services are far more common than daycares.
Anyway sorry about hijacking this thread haha, I just find it such a genuinely interesting problem to solve :D
Empty waitlist is honestly the most honest place to start. You know exactly who your first customer is, you're watching them use it every day, and you're fixing real problems before they become real complaints.
The data model rewrite is the unglamorous part nobody talks about. Everyone celebrates the 30-day ship but nobody posts about the week they spent refactoring because one dog walker has morning and afternoon sessions. That work is what separates something that lasts from something that breaks at customer number three.
Amsterdam is a great testing ground too. Dense, lots of professional dog walkers, and if it works there it probably travels to other European cities naturally.
What's the one thing missing right now that's blocking you from showing it to the next daycare or walker?
The events foundation - while I updated the data model to now work based on events, there is still a few hacks that map dates to those events for the single tenant using it right now, and there are no tools yet to create/modify events, so that's what I'm working on.
Then there's subscriptions which are just date-based atm, which also needs to shift, and then attendance which is date based, and then routes... so a bunch of stuff I need to change, but I'm chugging along :p
The Delineato parallel was real — minimalist tool for freelancers, same hard parts, same compression on the validation loop.
Planning a Product Hunt launch for Flowly soon. Would love your support on launch day. Happy to return the favor when Delineato launches.
Appreciate this, and the Delineato parallel is real. Minimalist diagramming for freelancers and a task-timer-calendar tool for the same audience, same hard parts, same compression on the validation loop.
The first-session churn point you mentioned is the one I'm still working through. Understanding why someone leaves in session one is genuinely difficult because they're gone before you can ask. What gave you the most signal there? Session recordings, exit surveys, or just pattern matching on where people dropped off in the funnel?
The "prototype in a day you can show someone" shift feels underrated in most AI-and-building conversations. The feedback loop compression changes what questions you can even ask. Instead of "do you think this would work" you can show a thing and watch someone use it. That's a different quality of information entirely.
Really resonated with your point about AI lowering the risk threshold. That reframe from "6 months I can't afford to lose" to "1 month I can survive" is the real shift happening right now. I'm in a similar spot — I vibe coded a chess puzzle trainer as my first project, and the fact that I could go from idea to a working app with rating systems, difficulty levels, and streak tracking in a fraction of the time it would have taken before is what gave me the confidence to actually ship it.
Your honesty about the distribution struggle is refreshing too. It's so easy to retreat to building because it feels productive, but talking to users and putting yourself out there is where the real growth happens. Curious — has the reverse trial model been effective for conversions so far? That seems like a smart approach for a productivity tool where people need to feel the value before committing.
A chess puzzle trainer with rating systems and streak tracking as a first shipped project is legitimately impressive. That's a real product, not a tutorial clone.
On the reverse trial: honest answer is it's still early to have clean conversion data. What I can say is that the users who actually use the product during the trial, specifically the ones who connect their calendar and build a daily habit, convert at a much higher rate than those who sign up and poke around once. The trial mechanism isn't magic on its own. The real constraint is getting people activated in the first 48 hours, not just signed up.
The research suggested 25 to 35 percent trial-to-paid for activated users. I'm not there yet but I think it's more a distribution problem than a product problem. Getting the right people into the trial in the first place matters way more than the trial length.
What's your plan for getting chess players to actually find the trainer?
The point about AI changing the risk threshold more than raw productivity feels exactly right. Going from a 6-month bet to a 1-month bet changes founder behavior, even if the actual output quality still depends on judgment. The other part that resonated was design being the blocker, not ideas. Curious whether after shipping Flowly you now see design as a solved-enough constraint for future products, or whether you still think solo founders eventually hit a ceiling there once they move from validation to polish and retention.
Honestly, design feels like a partially solved constraint. For validation, it turned out "good enough" was much lower a bar than I expected. People tolerate rough edges when the core problem is real and the solution clicks. That was a genuine surprise.
But you're pointing at something real about the ceiling. What I notice now is that validation-phase design is about removing confusion. Polish-phase design is about building trust and habit. Those are different problems and I'm not sure the first one prepares you well for the second.
Where I feel it most is in empty states, onboarding, and the moments right after a user completes their first meaningful action. Those transitions are where retention actually happens and they require a design sensitivity that's harder to fake or compensate for with good copy.
So my honest answer: shipping once gave me confidence that I can get to validation without a designer. It didn't convince me I can get to strong retention without eventually closing that gap somehow, whether that's hiring, partnering, or just putting in years of reps.
The ceiling is real. I just think it's higher than most people assume before they ship the first thing.
I think the interesting part is that AI compressed the build phase, but didn’t change the go-to-market phase at all.
So now the bottleneck just moved — from “can I build this?” to “can I get anyone to care?”
And that second problem is way less deterministic.
Have you found any early signals that something is working on the distribution side?
You nailed the shift. AI took "can I build it" from 6 months to 6 weeks, which just exposed the fact that the harder problem was always the second one. Way less deterministic.
On signals: I threw everything at the wall at once, which meant I learned pretty fast what doesn't work. Twitter with zero followers is just shouting. Reddit got me shadowbanned. But overall things are picking up. The real signal came from inside the product though. Seventy-one percent of trial users who connected Google Calendar actually converted, and they stuck around way longer. That told me the distribution problem is actually a product problem. Can't market your way out of something that doesn't create habits.
So early signal is less about which channel wins and more about whether the product itself makes people want to tell others about it.
That’s a strong point.
Feels like it’s a mix though — product creates the pull, but distribution determines whether you ever get enough surface area to discover that pull in the first place.
Like, without those early users, you wouldn’t have seen that 71% signal at all.
Curious — if you had to start from zero again, would you focus more on product iteration first or on getting those first 10–20 users faster?
I am aware now that distribution means more. And if I had to start over again I would pick the easiest marketing niche and invest more in marketing.
This part hit hard:
“Shipping code feels like progress. Posting on Reddit feels like gambling.”
I’m going through the exact same thing right now. Building feels deterministic, distribution feels random and uncomfortable.
What I’m starting to realize is that distribution only feels like gambling when you treat it as posting, not as conversations.
Curious — have you tried focusing on just one channel and going deep there instead of spreading across multiple?
That distinction between posting and conversations is real. For me, the "gambling" feeling came from trying everything at once. Twitter felt hollow, Reddit shadowbanned me fast, and I was just broadcasting everywhere without any actual relationships.
The part that shifted things was stopping thinking about it as reach and starting to actually engage in places where people are already talking about the problem. But honestly, I haven't figured out the "go deep on one channel" part yet. I tried spreading across multiple and learned pretty quickly what fails, but overall things are picking up enough that I'm still experimenting.
The conversations part though is what makes it feel less random. When you're actually replying and helping instead of just posting links, the discomfort goes away because you're not gambling anymore. You're just talking to people who care about the same problem.
That makes a lot of sense.
Feels like the “go deep on one channel” part is less about picking the perfect channel, and more about staying in the same conversations long enough for people to start recognizing you.
When you spread, every interaction is a cold start.
When you stay, it compounds.
I’m still figuring that out too, but that shift alone already made things feel less random.
The 71% calendar sync conversion stat was the sharpest product signal I've seen anyone share in this thread. That reframe from distribution problem to product problem changed how I'm thinking about my own activation.
Planning a Product Hunt launch for Flowly soon. Would love your support on launch day. Happy to return the favor on your next launch too.
This comment was deleted 6 days ago.
I like how you approached this. Did you focus more on marketing or product early on?
I did what I know well - developing. So mainly 30 days it's predistribution period.
The builder→distributor shift clicked for me when I stopped treating distribution as a separate activity and started treating it as conversations I was having anyway — just in public.
Concrete thing that worked: find threads where your exact user's problem comes up organically. Answer the question fully, no links, no product mention. Just be the person who knows the answer.
After doing that consistently for a few weeks, when you do mention what you built, it lands completely differently. You're not a stranger pitching — you're someone who already helped them.
Your point about the 1-month vs 6-month risk threshold is the most underrated part of this post btw. That psychological shift is half the reason AI tools are actually useful for solo founders — not the speed, the survivability.
This is exactly what I missed for too long. The "no links, no product mention" part is the hard one because you want to capitalize on the attention immediately. But what you're describing is the only distribution that actually scales for solo work: you become the person who knows, then the product is just the natural extension.
On the psychological shift you called out: totally true. A month feels reversible. A year feels like a career pivot. That's why the 30-day constraint actually works better than unlimited runway.
One question: are you doing this consistently on one platform or scattered across a few? I've wondered if consistency on one forum beats occasional presence everywhere.
the AI shift isn't in the code — it's in the decision speed. what used to take a week of "should I build this?" now takes an afternoon. the hard part is still the same: knowing what to build and who it's for. did the 30-day constraint change how you thought about scope?
Question for you: Did the 30-day constraint force your scope, or did you already know what had to ship? I'm curious if the deadline helped prioritize or just validated what you suspected.
both, honestly — the constraint forced me to cut everything that wasn't essential, but it also validated what I already suspected had to ship. the most useful thing a deadline does isn't prioritization, it's permission to stop debating. did the 30 days change what you thought the product actually was by the end, or did it come out roughly as planned?
Actually i planned to build for a month and I did it. I did a lot more that I should have honestly. My app has too much features for MVP and I think it would be better to invest in marketing more.
both, honestly — the constraint forced the cut but also validated what I already suspected. the most useful thing a deadline does isn't prioritization, it's permission to stop debating. the "too many features" problem is real though — shipping more than MVP means you now have to maintain, explain and support things that weren't tested with real users first. what's the one feature you'd remove first if you could go back?
Now I cant pick the feature to erase because they all my kids :)
It's a whole bunch actually, I think I would do just tighter deadline next time. Because it's really a lot that can be done with 1 month with AI. So even 15 days will be good MVP to start marketing in parallel.
classic feature creep — when you can build fast, cutting feels wasteful, but maintaining every feature costs more than building it did. the 15-day idea is solid: tighter scope forces clearer thinking about what's actually core. what would you have shipped in 15 days that you didn't ship in 30?
Well I came up with a lot of cool but maybe not necessary features for MVP. It's project and templates and advanced settings for tasks and so on.
But also I added NLP quick add feature which I think is a killer feature for my app.
So I could not regret path that I finished.
the NLP quick add is worth keeping — it changes how someone thinks about the product, not just what they can do with it. templates and advanced settings are complexity. that's different. no regrets on the path makes sense if the core interaction model is solid.
Yeah, i totally agree with you. Those complexity points are usefull but not must haves for MVP. But what I can do, I just love to build ;)
Solo dev shipping in 30 days is impressive. What was the hardest part — building or getting your first users?
Distribution is hardest thing for me honestly. Mainly because it's simply not mine
The risk threshold point is what gets undersold in every "AI makes developers faster" conversation. It's not just 2x speed — a 1-month bet has fundamentally different emotional and financial stakes than a 6-month one. That changes what you're willing to try at all.
On distribution: the VS Code → Reddit resistance is real and I think it's partly because the feedback loops are so different. Code gives you immediate confirmation it works. Distribution gives you... silence mostly, then occasional signal. The tooling for learning distribution is just worse. You basically have to treat it like a separate product you're building and expect the same iteration cycles.
The feedback loop point is exactly right and I hadn't framed it that way before. With code, broken means red. Working means green. The loop closes in seconds. With distribution you ship into silence and have to decide whether the silence means "wrong audience," "wrong message," "wrong timing," or just "not enough volume yet." Four different problems with nearly identical symptoms.
Treating it like a separate product is the right frame. Hypothesis, test, measure, iterate. The mistake I kept making was treating each post or channel as a one-off instead of a series of experiments with a thesis behind them.
The risk threshold thing being undersold is partly because the people writing about AI productivity are usually optimizing for the "look how fast we move" narrative. The more honest story is that it changed who gets to play, not just how fast players move.
This feels very real.
I think AI’s biggest impact for solo founders isn’t just faster output — it’s making small bets viable. That changes who even gets to try.
But the distribution bottleneck is probably the real story now. Shipping is no longer the rare part. Positioning, trust, and attention are.
That reframe is the one worth sitting with. When shipping was hard, the ability to ship was the signal. Now the signal has to come from somewhere else: judgment, positioning, trust.
Which means fast-building without fast-learning just gets you to the wrong place quicker.
The credibility gap is the part I don't think AI helps with much. Attention is the scarce resource and you start with none of it.
The risk threshold point is the real insight here. I'm running a portfolio of ~14 AI-powered MVPs and this is exactly the math that makes it work. When each experiment takes 1-2 weeks instead of 3-6 months, you can run them in parallel and let the market tell you which one has legs. The failure cost per experiment drops so much that you can afford to be wrong 12 out of 14 times and still come out ahead.
On the distribution struggle -- totally feel that. What's been working for us is treating distribution like another build problem. Automate the repeatable parts (SEO pipelines, content publishing, directory submissions) and save the human judgment for the stuff that actually needs it (deciding what to build next, talking to users). It's the same builder mindset, just pointed at a different problem.
The "portfolio math" framing was the one I kept thinking about after. Running experiments in parallel and affording to be wrong 12 out of 14 times is exactly the right mental model.
Planning a Product Hunt launch for Flowly soon. Would love your support on launch day. Happy to return the favor on your next launch too.
The portfolio math is exactly it, and what surprised me is how much of that math is psychological, not just financial. When I was building at companies, the implicit assumption was always that a project had to succeed to be worth doing. Running a portfolio of experiments forces you to confront that assumption directly. Most things fail. That's not a bug in the model, it's load-bearing.
The distribution-as-build-problem framing is the right one and I wish I'd landed on it earlier. My instinct was to treat distribution as a creative problem, which meant I'd sit staring at a blank Indie Hackers draft the way I'd stare at a hard architecture decision, waiting for the right answer to appear. The moment it becomes a systems problem, it gets tractable. What are the inputs, what are the repeatable parts, what's the feedback loop.
Curious what your automation stack looks like for the SEO pipeline piece specifically. That's the part I haven't systematized yet. I'm still mostly doing it manually and feeling the cost.
Built by a backend dev who hates juggling tools” is actually strong positioning
Thanks, I will keep it in mind :)
This resonates a lot. I've been building solo too and AI has completely changed the speed of shipping — but I've noticed it doesn't replace the hardest part, which is figuring out what to build and who it's for. What was the biggest non-technical challenge in your 30 days?
I’m seeing something similar. I’m working with a technical co-founder, and what used to take a team 6 to 12 months, he now ships in about a week. But it doesn’t feel like just speed. It feels like the barrier to starting is gone. You don’t overthink stack or setup anymore. You just build and iterate.
Curious if you see the same. Is the bottleneck now distribution and clarity, not building?
Yes, completely. The bottleneck shifted. Before AI, the question was "can we build this?" Now it's "should we build this, and will anyone care?" The building part has almost become table stakes.
What I've noticed is that speed creates a new kind of problem: you can iterate so fast that you start optimizing before you've validated. You ship v2 before anyone has used v1. The discipline is slowing down the product decisions while keeping the build speed.
Distribution and clarity are the constraint now, not execution.
Exactly this. The non-technical challenge was prioritization under uncertainty. When you can build anything in a week, the question "what should I build next" gets much heavier. There's no PM, no roadmap, no standup forcing a decision. You have to develop your own sense of what matters, and that muscle takes longer to build than any feature.
The other one was talking to users. Building felt like progress. Sending cold emails to potential users felt like rejection practice. I kept defaulting to the VS Code tab because it was the one place where effort reliably produced output.
The biggest shift AI created wasn’t just speed it was the cost of trying. The line about opening VS Code when you should be talking to users is painfully accurate as well in my opinoin.
The cost of trying is the real story. Speed is a byproduct of that, not the thing itself.
On the VS Code pull: I think it's deeper than habit. Building gives you a legible output at the end of the day. A conversation with a potential user gives you ambiguity, maybe a polite "sounds interesting," and nothing to commit. The brain resists that even when it's obviously the higher-leverage activity.
Really appreciate the transparency here, Max. Your breakdown of what AI actually helped with vs. what it didn't is the kind of honest build-in-public content we need more of. I'm building a lightweight memo app as a solo dev and had a very similar experience — AI crushed the boilerplate and let me ship an MVP in weeks instead of months, but every product decision (what to cut, how to price, which features actually matter) was still entirely on me.
Your point about the risk threshold changing is huge. A 1-month experiment you can walk away from is psychologically so different from a 6-month commitment. That framing alone probably unlocked more indie projects than any specific AI tool.
On the distribution struggle — I feel that deeply. Building feels productive, marketing feels like shouting into the void. One thing that's helped me is treating distribution like a product problem: run small experiments, measure what works, cut what doesn't. Did you find that any specific channel started gaining traction for Flowly, or are you still in the experimentation phase?
Your memo app analogy is spot-on. And thank you — the transparency angle seems to land with people who actually build things.
On distribution: Indie Hackers has been the clearest signal so far. The Article 1 post (the founder story) hit 400 views and 50 comments in 24h, and more importantly, the comments revealed what people actually care about — not the AI angle, but the problem of context-switching across tools. That data informed what I'm doubling down on.
Twitter/X is... humbling. 0 followers as of last week, which means the reach is entirely dependent on engagement from the indie hacker community (people like @levelsio, @arvidkahl). It's a credibility play more than a user acquisition channel right now.
The "distribution as a product problem" framing is exactly right. I've been thinking about it wrong — treating it like checkbox items (post on X, cross-post to Dev.to, etc.). What actually works is: ship something, listen to the comments, double down on what resonates, cut what doesn't. Same scientific approach as building the product.
The blocker for me isn't channels; it's that the product itself isn't sticky enough yet to create word-of-mouth. 71% of trial converters connected Google Calendar — that's the signal. So the next lever is making Calendar sync even tighter, not pushing harder on social.
Curious on your memo app: Did you find a specific channel that punches above expected, or are you still in the "try everything, measure, cut" phase?
The "1 month vs 6 months" framing is the most honest take on AI-assisted building I've read lately. Everyone talks about the speed gains, but nobody talks about how shortening the bet actually changes whether you start at all. That's the real unlock.
On distribution — I'm in the exact same spot. Shipping features feels like progress, posting online feels like gambling. The thing that's started shifting it for me is treating distribution like a product problem: what's the smallest distribution experiment I can run this week, what's the metric, what did I learn? It doesn't make it feel natural, but it makes the "gambling" feel more like iteration.
One question on Flowly: the "where did my week go?" framing is sharp. Did that come from talking to freelancers or from your own frustration? Asking because the best positioning lines I've seen usually come from literally quoting a user back to themselves, and I'm curious if yours did too.
Congrats on shipping 🙌
Thank you.
The "where did my week go" line came from my own frustration first, not from user research. I was the user. But what made me keep it is that when I described the problem that way to other people, they'd say "yes, exactly that" without me having to explain further. That confirmation is probably the closest I've gotten to quoting a user back to themselves, even if the original source was me.
Your positioning question is a good one to sit with though. I think I've been assuming my frustration generalizes more than I've actually verified. Something to test.
The "smallest experiment with a metric" frame for distribution is the right one. I'm still early on applying it consistently but the weeks where I've treated a post as a hypothesis rather than a task have felt less like gambling and more like work.
Your point about distribution feeling like gambling vs. building feeling like progress is probably the most honest thing I've read on IH this week. I'm dealing with the exact same tension.
One thing that helped me reframe it: distribution is a building problem if you treat it like one. Same feedback loops, same iteration cycles — you just measure different metrics. Instead of test coverage, you're watching referral sources. Instead of P95 latency, you're tracking which content actually drives signups.
The specific shift for me was treating content like a product feature rather than marketing. Write something genuinely useful (a data-backed guide, a real teardown of your own decisions — like this post), publish it where your users already are, measure what happens, iterate. It's still engineering thinking, just applied differently.
On the "posting on Reddit feels like gambling" point — there's actually data on this. A McKinsey survey from 2025 (1,927 consumers) found 44% now prefer AI search tools over traditional Google searches. That means your distribution surface is shifting whether you want it to or not. The content you write today doesn't just live on Reddit — it gets indexed by ChatGPT, Perplexity, and Google AI Overviews. So even "gambling" on a Reddit post has longer compound returns than it used to.
The 1-month vs 6-month risk framing is exactly right too. Applies to distribution experiments the same way it applies to product experiments.
The reframe to "distribution as a building problem" is the one that actually made it feel approachable for me too. Same mindset, different metrics. Once I stopped treating it as a separate alien skill and started asking "what's the hypothesis, what's the test, what does a result look like," it got less paralyzing.
The AI search indexing point is interesting and I hadn't thought about it that way. The compound returns on written content are already higher than they look on the surface because of SEO. Adding AI indexing on top of that makes the math even more favorable. A post that drives 50 views today might surface in Perplexity answers for the next two years.
That changes how I think about the effort-to-payoff ratio for long-form content vs. social posts. Social is immediate and decays fast. Long-form is slow to start and compounds. Probably worth weighting the portfolio toward the thing that keeps working while you sleep.
This is perfect. I'm literally in the exact spot right now with @getkeptapp
(AI-powered home inventory + reminders for warranty expirations, filter changes, repurchases). Dad of 3 vibecoding from the couch with Claude.
AI crushed the early HTML/Supabase parts, but now I'm stuck on the mobile decision: PWA vs Capacitor + App Store. The push notification + review horror stories have me leaning hard toward PWA first (Claude literally just told me "grow to 1000 users then decide on the cut and overhead").
You mentioned AI handling push notifications and App Store submission scripts, how painful was the actual store review part for you? Any wins with web push that made native feel unnecessary early on? Would love war stories from other solo builders.
No App Store war stories from me, Flowly is web-only so I dodged that particular adventure.
But honestly the advice you got sounds right. PWA first means you get to find out if people actually want the thing before dealing with review queues and provisioning profiles. That's the better order of operations.
The push notification problems are real but they're also a later problem. A thousand users frustrated by push UX is a genuinely good problem to be stuck on. Most of us would take it.
What's the core loop for @getkeptapp? Curious what "it's working" looks like for you before you hit that 1000 mark.
"Shipping code feels like progress. Posting on Reddit feels like gambling." — this is uncomfortably accurate.
I'm in a similar spot. I run a coworking space in Bulgaria and built a desk booking tool for it because everything else was either $300/month or way too complex for 20 desks. Use it every day. Love it. Then I spend evenings adding features instead of actually talking to potential users.
The Kyiv background resonates — I'm Ukrainian (living in Bulgaria now). Same instinct: build your way through the problem.
The real unlock you named isn't "AI made me faster." It's "a failed 1-month project is survivable." That's a completely different risk calculation. Saving that framing.
The desk booking story is a good sign, not a trap. You built something you actually needed, you use it daily, and the "why" is concrete: everything else was overbuilt for your scale. That's a much stronger foundation than most people start from.
The Ukrainian builder instinct is real. There's something cultural about solving the problem in front of you with what you have, without waiting for permission or perfect conditions.
The evenings-adding-features pattern is the one to watch. Features feel productive. Talking to the two coworking spaces down the street feels uncertain. But those conversations are the ones that tell you whether you have a tool or a product.
Same here but completely the other way around. I’m a designer — UX, service design, product strategy. That stuff I can do all day. But I couldn’t build anything technical to save my life.
AI flipped the exact same equation for me, just from the other side. Instead of removing the design blocker it removed the engineering one. I’ve shipped multiple apps at this point just to see how far I can push it as a solo non-technical founder, and honestly it’s kind of wild how much you can get done now.
The latest one is Vahti — competitor intelligence digests for small businesses. Vibecoded the full MVP in basically one sitting — app, AI pipeline, billing, marketing site, all of it. And I think this might be the best idea I’ve had so far.
The risk threshold point is the one that really hits home. Failed month vs failed half year. Completely different psychology.
On the distribution thing — I feel you. I have to actively force myself to treat distribution as 60% of the work. One thing that’s helped me think about it differently is making the product itself shareable. My core deliverable is an email digest, so users can just forward it to a colleague and that becomes an acquisition channel. Wonder if there’s something like that for Flowly — something people naturally screenshot or share?
Never though that non tech people could also do it. How do you manage infra without tech skills? As my understanding goes you still need tech background to manage deployments, connected external services and so on.
Thanks for your distribution advice, I actually have something similar in my mind. It's sharable day/week/month progress, so users could share it on their social media.
honestly the context piece is where most people underinvest. set it once, never touch it, then blame the model when things drift. started treating prompts like living specs - edit after sessions that go sideways. how do you keep context fresh across a longer project?
For me it's md docs. My project has a vast library of md docs on different lvls and different major tasks.
For example I had a payment system migration and I left migration doc for AI so it can understand if there any artifacts left.
Claude Code basically. I describe what I want, it writes the code, sets up the infra, deploys it. I still have to understand what's happening at a high level — like knowing I need a database, a cron job, DNS config — but I don't write the code myself. I've set up a bunch of custom instructions and safeguards so it doesn't go off the rails, and I try to keep the tech stack as simple as possible so there's less to break. It's more like being a technical PM than a developer.
The shareable progress thing sounds smart. If people are already screenshotting their stats or sharing wins, that's free distribution. The trick is making it look good enough that they want to post it without you asking them to.
That's a wonder of our days. But I think your are now high tier prompt engineer.
My experience differs, I did everything in that regards by hands and not sure how good AI in it.
Thanks for your remark to make sharable piece look good. I will keep it in mind.
the part that bit me hardest wasn't setup - it was the debugging loop. AI writes code 3x faster but the errors are 5x harder to trace. at some point I was spending more time understanding AI code than I would've writing it myself.
It's true but it can be partially fixed with AI using skills. Two things - good model and making good doc and context for AI.
Great point about the 'Setup Tax.' Most people think AI is just for writing functions, but as you said, it's the auth, payments, and infra setup where it saves weeks of inertia.
Since you're building a workspace for freelancers, are you planning to integrate with other tools (like Notion or GitHub) using AI to map the data, or are you keeping Flowly as a standalone focused 'deep work' tool? I'd love to hear your thoughts on how AI handles complex integrations versus manual API mapping.
Intentionally standalone, and that's a product decision not a roadmap gap.
The whole premise of Flowly is that the integrations are the problem. Most freelancers I've talked to aren't suffering because Notion doesn't talk to Toggl — they're suffering because they have four tabs open and none of them have the full picture. Adding more sync points adds more things to break and more cognitive overhead to manage.
The one integration that made sense is Google Calendar, because scheduling is genuinely external data Flowly can't own. Everything else — tasks, time, analytics — lives inside Flowly by design.
GitHub and Notion integrations would pull Flowly toward a different product: a hub that connects your existing stack. That's a valid thing to build, but it's not this. The bet here is that consolidated beats connected.
That’s a bold and refreshing take. 'Consolidated beats connected' is a powerful framework—choosing to sell 'Focus' instead of just another dashboard is a smart move.
I see this cognitive overhead issue a lot while building Flex. Users often get paralyzed by the very tools meant to help them.
Really appreciate the insight, and I love the philosophy behind Flowly. Best of luck with the growth—I’ll be watching this one closely!
Interesting framing. One pattern I've noticed with AI-assisted development is that it accelerates certain tasks but doesn't fundamentally change the core product discovery process. Tools like ChatGPT are great for boilerplate code and initial architecture, but the real challenge remains understanding user needs and creating something people actually want.
The 30-day timeline is intriguing — seems like a solid sprint for a solo dev. Curious how much of that was pure coding vs validation and design. AI might speed up implementation, but customer discovery is still a human-driven process.
What specific workflows or features did you find AI most helpful in prototyping?
Honest split: 50% building with AI, 50% validation and fixing what it got wrong. The biggest unlock was UI — I genuinely hate CSS, so handing that off was the difference between shipping something that looks decent and shipping something that looks like 2009.
Where it didn't help at all: deciding what to build. Great at "how do I build this," useless at "should I build this." That one still requires talking to people, which I remain better at avoiding than doing.
Always i have the problem of visibility. today looking to get people to try my product more than directly sell. its been hard lately.
Yep, I think this is shift of our era. It's not like it was before.
I've been working on a side project and I recognise this: "I catch myself opening VS Code when I should be talking to users". Granted nowadays it's that I find myself talking to an AI rather than users.
I sat down with a friend of mine who is a really good product owner I used to work with and she basically scolded me for focussing on the wrong things. I didn't even have a marketing website yet. Now, three days later and it's live and I can start showing the world what I've been building.
Distribution is still difficult and it's also something that I need to figure out, but she gave me a good wake-up call, and now I keep her up to date with my progress so she can scold me some more when I veer off track.
Good luck with Flowly, the website looks nice. :)
The "talking to AI instead of users" line is uncomfortably accurate. At least VS Code gives you working software. A conversation with Claude gives you a very confident plan that nobody has validated yet.
The accountability partner thing is underrated. Most productivity advice is self-directed — systems, habits, frameworks. But having an actual person who will ask "did you do the thing" is a completely different forcing function. The embarrassment of saying no to a real human beats any app-based streak counter.
Three days from scolded to live website is a good sign. That's the right response to a wake-up call — move immediately before the discomfort fades.
Good luck with it. What are you building?
Yeah, actually I have recently been using codex over claude for a lot of things because claude seems a bit too eager to please, while I get the feeling that codex still pushes back a bit, which I like. Honestly I think a lot of the logic is in my head anyway, and I sometimes pit the AIs against each other - like when I was building the marketing website I let codex do a first pass, then told claude to look it over, and it came up with some pretty valid points.
And definitely talking to a person helps a lot. The thing I built was for an actual business (a local doggy daycare I bring my dog to) so I had a playground to validate my ideas in a way, but it also meant I built stuff very focussed for them, so now I have to go back and basically redo the entire foundation while making sure the app keeps working for them. It's good practice for later, dealing with real user/data constraints while making the changes you want to make.
Thanks! I'm building Tail Trail, an app (but will probably expand do desktop as well for management stuff) that helps dog daycare and dog walking businesses handle things like attenandance, routing (for pickups/dropoffs) and that sort of thing. I have a LOT of work to do before I can onboard any other users but it's been a fun ride so far, and having even just one daycare use it has been really motivating!
Really appreciate the honesty here about what AI actually helped with vs what it didn't. I'm building an AI-powered resume/cover letter tool and had a similar experience — the AI is great for draft generation but the real value-add ended up being in the tailoring logic (matching resume language to job descriptions). The 30-day timeframe is impressive. What was your biggest time sink — the product itself or the surrounding infrastructure (auth, payments, etc)?
Actually I would divide it into two major parts. First part is developing and delivering product and second part is infra and wiring app all external services. I think they about to be equal but second one with annoying waiting.
this hits hard, especially the “opening VS Code instead of talking to users” part
one thing that helped me reframe this was realizing that distribution feels like guessing only because it’s invisible compared to building
when you build, you see progress immediately
when you do distribution, the feedback loop is delayed and messy
what made it click a bit was treating the whole thing like a flow instead of separate actions
not “post on reddit / try SEO / try X” but literally mapping:
where someone first sees the problem → what they read → what makes them click → what makes them try
i laid that out once in something like stackely (just to visualize steps + decisions), and it made it obvious that I wasn’t lacking distribution, I just didn’t have a clear path
so every post felt random because it actually was
once the path is clearer, distribution stops feeling like gambling and starts feeling closer to iteration again
This reframe is genuinely useful. The "flow vs separate actions" distinction cuts right to why distribution feels so foreign to developers.
When I look at what I've actually been doing — IH post, X thread, Dev.to cross-post — I can see each piece, but I couldn't have drawn you a map of how they connect. Someone reads the IH article, then what? I hoped they'd click through to flowly.run, but I hadn't thought hard about what they were supposed to read there, what moment would make them start a trial, or what would happen in the first 10 minutes after signup.
The code analogy you're drawing is right. When I write a feature I know exactly what state the system is in at every step. With distribution I've been firing events and not tracking state at all.
The "it wasn't that I lacked distribution, I just didn't have a clear path" line is the one I'm going to sit with. That's a different diagnosis than what I wrote in the article — and probably the more accurate one.
What does your flow actually look like end-to-end? Curious whether the path you mapped started at awareness or further down — and how many steps before someone actually pays.
yeah this is exactly it
shipping feels productive
but distribution feels like throwing things into the void
i’ve been trying to figure out if it’s just a volume game
or if there’s actually something more predictable behind it
Respect for shipping this fast.
I'm also building an AI product right now — how did you validate the idea so quickly?
Actually it was multiple researches with multiple AI models, as well as self validating and making choice based on personal preference onto what I want to use and build.
I think AI is just assistant not a magic stick
100%!
Interesting approach. Have you tested this with paid traffic or only organic?
Organic first — paid before you know what converts is just expensive testing. Are you considering it soon?
Totally agree with the design. Can't ship anything if it looks like trash. AI really changed this.
True, but it's a double-edged sword — AI raised the floor (no more obviously bad UI) but also raised expectations. Users now compare your solo-built tool against Notion and Linear on day one.
The founders who stand out are the ones using AI as a starting point, then adding deliberate design decisions that feel intentional — not just "clean Tailwind template #3."
The AI didn’t change judgment, only execution. The point really stands out. A lot of people overestimate what AI can do. Do you think the next bottleneck for solo founders will be distribution rather than building?
That is a very interesting topic you bring up, I believe distribution will be the next big business.
Yes — distribution is already the bottleneck. AI just made it undeniable by removing the last excuse (building took too long). Now everyone can ship. Almost nobody can cut through.
AI makes shipping fast, but it makes standing out nearly impossible.
When everyone can code a SaaS in 30 days, "software" becomes a commodity. The real bottleneck now isn't the build—it's the Visual Trust.
I learned this the hard way when my Medium infrastructure was nuked overnight. It taught me that unless your project has that "85mm" editorial authority and a sovereign "Bunker" to live in, you're just renting space in a crowded market.
Are you building a tool, or are you building an Infrastructure that can survive a platform ban? That's the only question that moved my needle to $10k/mo.
This hits on something I've been building around. The Medium nuke scenario is exactly why I chose to put Flowly's content engine on its own domain rather than rely on any single platform. Comparison articles that rank on Google — "Todoist vs Toggl," "ClickUp alternatives for freelancers" — are assets that compound for years. A platform ban doesn't touch them.
On Visual Trust: 100% agree. In a world where anyone ships a SaaS in 30 days, the software itself is table stakes. What actually converts is whether someone trusts you before they ever click signup. That's why I'm investing in SEO content and community early — not as growth hacks, but as the "bunker" you're describing.
The question I keep asking myself isn't "can I build this?" — it's "will someone trust this enough to pay $5/month for 2 years?" That answer comes from editorial authority, not feature lists.
How did you rebuild after Medium? Curious whether you went full own-domain or diversified across platforms.
Smart move on the domain.
After the Medium nuke, I went 100% Sovereign. No more diversifying across "landlord" platforms—that's just renting more cages.
Now, I’m building my own Private Bunker where I own the database and the distribution. I still use social for "heat" and reach, but the conversion happens in a space where no algorithm can touch my $10k/mo stability.
SEO is an asset, but Visual Trust (85mm) is what makes them stay once they land. Let's keep building the fortress.
Your point about the risk threshold is spot on. The biggest thing AI changed for me wasn't speed either. It was that I could run multiple product experiments in parallel instead of betting everything on one idea for 6 months. When each experiment takes weeks instead of months, you can afford to be wrong more often. And being wrong more often means you find what works faster. The distribution struggle is real though. I keep catching myself tweaking code when I should be talking to potential users. What helped me was setting a rule: no new features until I've done at least 30 minutes of outreach that day. Sounds simple but it works.
"Afford to be wrong more often" — that's the compounding part nobody talks about. More experiments = faster learning = better bets on the next one. The economics of being wrong completely changed.
The 30-minute outreach rule is exactly the kind of forcing function I need. Stealing that.
The risk threshold point is the one that doesn't get talked about enough. "A failed 6-month project hurts. A failed 1-month project is survivable." — that shift in psychology is doing a lot of work.
I had a similar experience building outside my day job. The thing AI actually changed wasn't the output quality, it was that I stopped needing to justify the time investment before I started. You can test a real hypothesis in a weekend instead of treating it like a 3-month commitment.
On distribution — I've been going through the same wall. What I found is that the "build mode to talk-to-people mode" switch is genuinely a different skill, not just a different task. The tactics that work for building (iteration, optimization, closing loops) actively work against you when you're trying to get early users. Still figuring it out, but treating distribution as a separate "product" with its own feedback loop has helped a bit.
"Stop needing to justify the time investment before you start" — that's it exactly. The psychological unlock wasn't speed, it was permission. You can run a real experiment without betting months of your life on the outcome.
The "different skill, not different task" framing is the most useful thing I've read about this problem. I've been treating distribution like a backlog — ship something, check it off, move to the next item. That's the wrong mental model entirely. A backlog closes. A feedback loop doesn't — it just gets tighter or looser depending on how much signal you're feeding it.
What does your feedback loop actually look like in practice? Curious what you're using as the equivalent of a test passing.
The "backlog" mental model for distribution is such a good way to name what goes wrong. You close a task and move on — but distribution signals don't close, they accumulate or decay depending on what you do next.
For my feedback loop right now: I'm treating each post or comment as a probe, not a deliverable. The signal I'm watching isn't "did this get engagement" — it's "did this attract the kind of person who has the problem I'm solving." A reply from someone who says "this is exactly my situation" is worth more than 50 upvotes from people who just agree in the abstract.
Still early, so the loop is mostly: post something → see who responds and how → adjust the framing of the next thing based on what resonated. Not elegant, but it's keeping the feedback tight.
What's your equivalent of a test passing — are you tracking anything specific, or mostly going by feel at this stage?
Mostly feel at this stage, which is uncomfortable for someone wired to want green tests.
The closest thing I have to a passing test is whether someone asks a follow-up question. Upvotes are passive. A question means they actually engaged with the problem, not just the framing. That feels like the distribution equivalent of "it compiles and does something."
This really resonates, especially the part about AI not just speeding things up, but lowering the risk threshold. That feels like the bigger shift than most people talk about.
The design blocker point is also interesting. I think a lot of backend-heavy devs were never blocked by ability, but by that “I can’t make this look good enough to ship” feeling. AI basically turns “not shippable” into “good enough to test,” which is a huge unlock.
That distinction — "not shippable" → "good enough to test" — is exactly it. The bar didn't lower, the definition of the bar changed. You're not shipping a finished product, you're shipping a hypothesis. AI made that framing actually viable.
Really resonated with this — especially the part about the design blocker. I'm a software engineer building a training load tracker for triathletes as a side project, and for years the thing that kept me from starting wasn't the backend complexity, it was knowing I couldn't make the UI look decent on my own. AI tools changed that calculus for me too.
Your point about distribution vs. building also hits hard. I'm at that exact stage right now — the product works, I use it daily, but the shift from "build mode" to "talk to people mode" feels unnatural. Opening VS Code when you should be posting on Reddit is so relatable.
Curious about your reverse trial approach — did you consider starting fully free to maximize early adoption and feedback, or did you want to validate willingness to pay from day one?
On the reverse trial question: I considered fully free and decided against it for one reason — I wanted to know as fast as possible whether anyone would pay, not just whether anyone would use it. Free gets you users. Paid gets you signal. A product people use but won't pay for is a different problem than a product people don't use at all, and I wanted to know which one I had.
The reverse trial is a middle path: you get real usage data during the trial (so you learn what actually drives activation), and the downgrade moment tells you exactly what feature someone cared about — because that's what they lose. That's cleaner feedback than a survey.
The tradeoff is top-of-funnel friction. Some people won't sign up knowing there's a downgrade coming. I've accepted that. If someone won't try a free 14-day trial because they don't want to think about canceling, they probably weren't going to pay anyway.
Resonates hard. I had a similar experience — 10 years building fullstack at companies, then went solo and shipped 3 native mobile apps in a month.
Your point about AI changing the calculus is spot on. For me the biggest shift wasn't code generation — it was that AI eliminated the setup tax. Auth, payments, push notifications, App Store submission scripts. All the stuff that used to eat week one of every project.
The thinking part didn't change though. Defining what to build and for who — that's still 100% human work. AI just made the gap between "clear thinker who ships" and "everyone else" more obvious.
Curious: what's your distribution strategy now? That's usually where solo devs hit the next wall after building.
"Setup tax" is exactly the right word for it — and probably the most underrated part of what AI actually does. It's not the clever code, it's the elimination of week-one inertia on every project.
On distribution: that's exactly where I'm at now. Currently testing Reddit organic (genuine answers in freelancer subs, no spam), SEO comparison pages, and content on X. Honest status: early, slow, not yet compounding. The pattern I've noticed is that building created a false sense of progress for 30 days — now distribution has to earn the same daily attention. Curious how you handled it across 3 apps — did one channel work better for mobile vs. web?
The design barrier point hits hard. For a lot of backend-first builders, that's always been the silent blocker — not the idea or the engineering, but the gap between "it works" and "it looks like something worth using."
What's interesting is that AI didn't just speed up the design process here — it seems like it removed a hard prerequisite. The question isn't whether you could've done this faster before, it's whether it would've happened at all.
What does your onboarding look like? Curious how users are finding it so far.
"Whether it would've happened at all" — that's the exact distinction. It's not an acceleration story, it's an existence story. The 6-month version of this project doesn't exist.
Onboarding: 14-day reverse trial, full Pro access, no card. The aha moment I'm trying to get users to as fast as possible is the NLP quick-add — hit Cmd+K, type "Review proposal tomorrow high priority #client", task created instantly. That's when the app clicks. As for finding it: mostly organic right now — Reddit answers, comparison pages, a few X posts. Early days. Would love to know what you think of the onboarding if you try it — the gap between "it makes sense" and "I'd actually change my workflow for this" is what I'm still closing.
re: the distribution part — the thing that helped me shift from builder brain to distribution brain was realizing that distribution is basically the same skill as building, just applied differently. when you build a product you start with a problem and iterate toward a solution. distribution is the same — you start with "where do my people hang out" and iterate toward the message that resonates. the mistake most devs make is treating distribution as one big thing they need to figure out. it's not. it's a bunch of small experiments just like building. try replying to people in your niche on X for a week. try posting a genuine build log on reddit. try cold emailing 10 freelancers who match your ICP. most of it won't work but you'll find the one thing that does and then you double down on that. the key is that distribution compounds — the first week feels like nothing is happening and by week 3-4 the momentum is real. also fwiw the "opening VS Code when i should be talking to users" thing is extremely relatable
I really appreciated for your suggestions. They are really insightful and I will test them 100%.
What was your one focus thing that fired?
Love this write‑up. Really resonates how you framed AI as a way to lower risk and remove blockers, not just “go faster.” The distinction between building and distribution is spot on too — treating distribution like a product problem is a powerful mindset shift.
Thank you for support <3
Distribution is a product problem, just not the one that I am used to. Still need to adjust myself.
The risk threshold point hit hard. That psychological shift from "6 months of risk" to "1 month of risk" is exactly what made me finally ship too.
I built Scrutr — AI contract review and drafting for freelancers, renters, and anyone signing without a lawyer. Same story: wanted to build it for years, the combination of AI tooling and a much shorter path to something shippable changed the calculus completely.
Your point about distribution is where I am now too. Building feels like progress. Posting feels like guessing. The honest answer I keep coming back to: the only thing that's actually moved the needle early is being genuinely helpful in communities where your exact users already exist. Not promoting — just answering questions and being useful. Slow, but it compounds.
Congrats on getting to paying users. That's the only metric that actually matters at this stage.
AI contract review for freelancers — that's actually adjacent to Flowly's user base. Worth a conversation at some point.
For me Reddit was too tough. I just get bans and filtered posts so I lost faith in Reddit.
The compounding part I just have to take on faith for now. Good luck with Scrutr. Seems like great idea :)
The risk threshold point hit hard. A failed 6-month project is a scar. A failed 1-month project is data. That reframe alone is worth the price of AI tooling.
On the builder → distributor shift: I'm going through this right now. What's helped me is treating distribution like a product problem — meaning: what's the smallest experiment I can run to get a signal? Instead of "I need to do marketing," it's "I'll post one specific thing in one specific place and see what happens."
The Reddit gambling feeling is real. But I've noticed it gets less irrational after the first few times you post something and realize the downside is mostly silence, not humiliation.
One thing I haven't seen solved yet: how do you know if your product is even findable by the people searching for it — whether that's Google or increasingly, AI chatbots? That's the invisible distribution layer most builders don't think about until it's too late.
Good luck with Flowly. The "where did my week go?" framing is sharp.
Treat distribution like a product problem is the reframe I needed :)
Actually SEO indexing and findability is a long run instrument and takes a lot of time. So this is worth doing early but it's not the instrument to rely on in a short run.
Totally agree — SEO is a long game. But here's what's been on my mind lately: even if your SEO is solid, there's a whole new layer now where AI chatbots (ChatGPT, Perplexity, Gemini) are answering questions that used to go to Google.
So someone asks "what's a good productivity tool for solo devs" and the AI just... answers. No click, no search result, no chance for your landing page to show up.
That's the part I'm trying to figure out right now — how do you even know if AI recommends your product when someone asks? It's like SEO but with zero transparency. At least Google has Search Console. AI has nothing.
Would love to hear if you've noticed any traffic coming from AI referrals for Flowly.
Hey Max, really enjoyed this post.
Shipping a full SaaS in 30 days as a solo dev is impressive. The part about AI removing the “design blocker” really resonates — that’s exactly what held me back for years too.
Congrats on getting Flowly live with paying users!
Quick question: What was the hardest non-technical part during those 30 days?
Honest answer: the uncertainty of the first public post. Code has feedback loops — tests pass, things compile.
Distribution has a 48-hour silence window that feels like failure but usually isn't. Learning to sit with that delay instead of opening VS Code again is the actual skill I'm still building.
Max, I can definitely relate to your story.
A developer, front or backend, can really create applications fast if they have been in the industry even for a short time. Knowing what you're good at you can sanity check what models give you and delegating what you're weak to AI will get you at least to a point where you can get a working prototype. (And with either more experience or skilled prompting something in production.)
But AI can't create a market for something that isn't there.
That's a lesson I'm working through myself. Spending time outside the tech, talking people, help solve problems helps me make things that at least scratch itches.
I'm a consultant trying to move more to creating products or frameworks. I see trends across my clients, but there is leg work needed to get your ideas out there. That work is easy to take for granted.
Thanks for sharing your story and know you're not alone.
"AI can't create a market for something that isn't there" — good gut check. I know the market exists, just not sure if I fit there.
Pretty interesting point about legwork that I was not aware about.
What category are you building in? Curious what trends you're seeing across clients.
To answer your question: I find myself building sites for coaches. I found myself building AI tools and services for owners who are a bit older 50+.
They have a working business, and established practices. Toying around with AI, but never got the hang of the internet/social media generation.
So I'm walking alongside them and really have to remove much of the AI marketing talk and speak to their needs, domains, and how I can provide results. The AI part is really just a black box. But for many, so was social media, SEO, internet etc.
Hope my journey can connect some dots for you as well. Keep it up, and take care Max.
That's pretty interesting niche. Kudos to you for bravery. I think i would not risk going into such specific niche. I am personally choosing product that also fits me and that i can relate. Maybe I am wrong about that and that's not must have.
This resonates. The counter-intuitive thing I found is that focusing on one channel also makes you better at it because you actually learn the nuances — tone, timing, what triggers engagement. Curiosity: after you hit the first 15, did you find the channel scaled linearly or did you hit a ceiling that required a second channel?
Single-channel depth is exactly the thesis I'm testing. Honest answer to your question: I am not sure about single channel, doing multiple instead. But the logic tracks — you can't iterate on something you're doing infrequently. What channel ended up scaling for you?
"I catch myself opening VS Code when I should be talking to users" — felt that in my soul. exact same situation here, solo founder building AI infra. the building part is addictive because it feels productive. distribution feels like shouting into the void. No real advice because i'm figuring it out too, but at least we're aware of the problem. that's step one i guess.
Yeah, there is a reason why we engineers and not some marketing or C-suites.
Engineering feels linear and productive understandable path.
And now so many other skills needed for you and me.
Good luck.
Exactly. We spent years getting good at building and now the game is completely different skills.Figuring it out one awkward reddit post at a time lol. Good luck to you too man
this matches my experience. AI didn't change what I build, it changed how fast I can iterate. the biggest shift was treating Claude Code as a junior dev that needs a good spec - write the plan, dispatch the work, review the output. the part AI didn't change: talking to users, picking what to build, and knowing when to stop adding features. those are still 100% human judgment calls.
That exactly what healthy attitude is. Former engineers would not be those mad AI confident CEOs.
Reverse trial at $8/mo annual is a tight bet. What's your day-14 conversion rate looking like? Because if people use Flowly daily for two weeks and still don't pay, that's not a pricing problem or a distribution problem. That means the 4-app workflow they already have is "good enough" and you're fighting inertia more than awareness.
Too early for clean data — still in single digits so the sample is noisy. But "fighting inertia" is the sharpest framing I've read about this.
You're right: if daily users don't convert after 14 days, the question becomes whether the pain was real or just perceived. That's my current obsession.
It’s really impressive that you managed to build this in just one month and with such great quality. I’ve joined your subscriber family!
Really clear on how AI removed the blockers for solo founders. Excited to see how Flowly grows from here.
Thanks Alina! Really appreciate the kind words — excited to have you along for the ride. Would love to hear your feedback once you've tried it!
"That 30-day solo dev sprint was a hell of an achievement—the 'AI didn't make me faster, it removed the reason I hadn't started' insight is the most accurate take on 2026 building. Since you're prepping the Product Hunt launch for Flowly, there’s a competition where you can submit this — entry is $19 and winner gets a Tokyo trip. Prize pool just opened at $0. Your odds are the best right now. It’s the best backup plan for launch week I’ve seen!"
I see a lot of recommendations online and it’s already obvious there are bad eggs online who will only add to your mystery. I can only recommend one and you can reach them via mail on (omegacryptorecovery AT gm ail co m) if you need help on recovering what you lost to scammers.
Quick ask from the founder — I'm planning a Product Hunt launch for Flowly soon and would love your support.
This thread has been one of the best distribution experiments I've run — 200+ comments, real conversations, people who actually get the problem. If you've found value here and want to see where Flowly goes next, a PH upvote on launch day would mean a lot.
Drop your PH profile or email below and I'll personally ping you when it goes live. Happy to return the favor on your launch too.
Really appreciate the transparency here, Max. Your breakdown of what AI actually helped with vs. what it didn't is the kind of honest build-in-public content we need more of. I'm building a lightweight memo app as a solo dev and had a very similar experience - AI crushed the boilerplate and let me ship an MVP in weeks instead of months, but every product decision was still entirely on me.
Your point about the risk threshold changing is huge. A 1-month experiment is psychologically so different from a 6-month commitment. That framing alone probably unlocked more indie projects than any specific AI tool.
On the distribution struggle - I feel that deeply. One thing that's helped me is treating distribution like a product problem: run small experiments, measure what works, cut what doesn't. Did any specific channel start gaining traction for Flowly, or are you still experimenting?
duplicate :)
HACKER EXPERT ALPHA KEY DATA RECOVERY
My name is Destiny Rodrigues, and I'm from Canada. After learning about cryptocurrency investments and how my coworkers have been profiting from them lately, it really caught my attention to invest as well. However, I had no idea that this was my biggest mistake—investing with the worry brokers and falling into the hands of scammers. Thank you again to Alpha Key Recovery for helping recover every coin and clear my credit card debit. Please get in touch with them right away if you become a victim of this kind.
WhatsAPP: +15714122170
Signal : +15403249396