21
155 Comments

I'm a solo founder. It took me 9 months and at least 3 stack rewrites to ship my SaaS.

I am a solo founder. Nine months ago I started building an SEO tool. Two weeks ago I got my first Stripe payment. In between, I rewrote the stack maybe three times and built things I had never touched before: a backend, a database, webhooks. All of it for the first time, with AI as my teacher.

I am not a developer and I am not a CSS person. I came in with 15 years of SEO experience, some project management, and a digital illustration hobby. Everything technical I figured out as I went.

The product is IvaBot - an SEO tool with three modules (technical audit, content coverage, content generation). Checks how ready a site is to be cited by AI engines like ChatGPT and Perplexity. Pay-as-you-go from $5, no subscription. https://ivabot.xyz

Everyone here ships in 2-3 months. I took 9!

What I tried first (and threw away)
Plan A: a Telegram chatbot. Realized about 10 people would actually use it.
Plan B: a Typebot chat embedded on a Webflow landing. Built the whole decision tree inside Typebot's free tier. That phase taught me how to write prompts, structure logic, make HTTP requests, parse JSON, set up webhooks, work with a real database. ChatGPT was my teacher for 6 months.
Stack: Webflow + Typebot + Memberstack (auth) + Stripe + Supabase + SerpDev + Make.
Monthly cost: ~$200/month before a single sale. Unsustainable.
A designer friend did a rough homepage draft for free, then I was on my own. Copied his tokens into Webflow, built everything else, drew the logo, made all the homepage illustrations by hand.

What changed: switching to Claude

Moved development work to Claude. Build sped up significantly.
Rebuilt the backend. Files to GitHub. Killed Typebot. Killed Memberstack (Supabase Auth instead). Swapped SerpDev for DataForSEO (PAYG, much cheaper).
New monthly cost: ~$40/month. Around 5x reduction.

Where it is now

Launched April 29, 2026 with live Stripe
First paying transaction two weeks ago
One blog post going slightly viral about how ChatGPT, Perplexity, Claude, and Google AI cite different sources for the same query
First impressions and clicks from Google showing in Search Console

Three modules, $5 starting price, pay-as-you-go. Built for solo founders and small businesses because every other tool in this space starts at $50-300/month, and I know the pain.

What I would do differently

GitHub repo on day one. Not a no-code stack.
Skip Memberstack. Spend that money on Claude credits and build auth properly.
Think about security from day one, not bolt it on later.
Use Claude earlier.

What's next

Product Hunt launch May 27. Next month: expanding Content Coverage with bigger automated checks for AI citation readiness, and a chat widget for the blog (grounded in site content).

Why I'm posting this

I do this alone. My partner is patient but tired of hearing about Stripe webhooks. I do not really have anyone to talk shop with.
Would appreciate honest feedback on the product, stories from other slow solo founders, or just a "yeah, this is hard", that works too.
Anyone else done a 6-9 month solo build? How did you balance dev time against marketing time?

on May 19, 2026
  1. 2

    First of all, I genuinely have to say this: indie hacking is really not easy.

    Seeing you receive your first Stripe payment instantly reminded me of the first sponsorship payment I ever got myself. Only people who’ve actually built something on their own understand how much that first dollar is truly worth.

    Your post honestly made my brain buzz because it felt way too relatable. I come from an architecture background, and now I’m basically a passion-driven “vibe coder.” For the past two months, I’ve been grinding away on an AI translation SaaS focused on long-form documents.

    A lot of people have told me: “LLMs are already so powerful — who would even use your tool? There’s no future in this product.”

    I don’t see it that way.

    My idea came from a very simple frustration: AI has made translation easier, but serious external-facing content still can’t be handled as effortlessly as one-click machine translation promises.

    For SaaS teams, founders, technical writers, and global businesses, translation is not just about converting words. It affects trust, product understanding, documentation quality, terminology consistency, and ultimately a company’s professional image in foreign markets.

    During testing, several professional translators gave my product surprisingly high praise. Some of them even joked that tools like this might eventually replace their jobs. Honestly, I think their concern is valid — because I truly believe in what I’m building.

    Along the way, AI has also been my only full-stack mentor.

    Back then, constantly seeing people on X bragging about “launching a micro SaaS in 48 hours” genuinely made me anxious. But reading that it took you 9 months to figure out Auth, databases, and webhooks from scratch honestly gave me relief. That’s the raw, unfiltered reality for founders like us who didn’t come from traditional technical backgrounds.

    What’s even crazier is that our products somehow collided in the funniest possible way.

    Right at this moment, I’m sitting in front of my computer doing a huge amount of GEO work (Generative Engine Optimization) — wrestling with Codex prompts, modifying robots.txt to allow GPTBot and ClaudeBot crawling, and tweaking JSON-LD structured data so AI engines can better reference my site in the future.

    Then I refreshed X and saw your post about building IvaBot — a tool that audits a website’s “AI citation readiness.” That honestly felt like some kind of weird quantum entanglement inside the coding universe. I’m definitely going to try your product later today.

    As for balancing coding and marketing: honestly, I’m struggling with it too.

    Hiding behind code and chatting with LLMs feels comfortable because there’s instant feedback. Marketing feels like shouting into an empty wilderness most of the time. When I improve my code, I can immediately see my product moving closer to the vision in my head. With promotion, it often feels like punching into cotton.

    Right now, I’m forcing myself to treat marketing like manual labor. I spend 90% of my energy learning distribution and promotion. On days when I’m focused on SEO and Twitter growth, I strictly ban myself from opening the code editor at all. I physically separate the two worlds.
    good luck with your Product Hunt launch on May 27th. Your family might already be tired of hearing Stripe webhook errors all day, but somewhere across the planet, there’s another slow-moving indie builder cheering for you.

    Keep going.

    1. 1

      Your message is so warm and close to me. This is exactly why I came to Indie Hackers - somewhere inside hoping there are others like me out there. I felt every line. I see your experience, your path, your skills, but I also saw the emotional part that solo founders usually keep hidden inside. That's what got to me.

      I also want to say your translation idea makes huge sense. Part of my work at a previous company unexpectedly involved translating text for vulnerable people - refugees and migrants. And I know that machine translation, even with AI, still doesn't quite reach. Even if AI is a breakthrough, it's still too robotic, too averaged out. The meaning behind your tool resonates with me.

      And yes, I love that GEO came up here. I'm sure you know a lot on this topic, but I gathered my own knowledge and test results into this article on the IvaBot blog: https://ivabot.xyz/blog/geo-seo-how-to-get-cited-by-ai - and there are more on related topics. Not all of it is applied to my own tool yet, that's on the roadmap. You might find some fresh angles.
      And please, give me feedback after you try the tool. Your comment matters to me.

      1. 1

        I actually just put your tool to the test! I ran my project's landing page through IvaBot, and it generated a clean report for me named "IvaBot-Audit-goodtrans.app-2026-05-24".

        I’m super happy to report that GoodTrans passed 9 out of 11 checks! The breakdown of meta tags and H1-H3 hierarchy was incredibly clear and reassuring for an indie hacker. It did catch an important warning regarding my page speed and image optimization. I'm actually feeding those exact recommendations into Codex right now to compress my assets to WebP and set up lazy loading.

        IvaBot is incredibly practical for solo developers who need a quick, no-nonsense sanity check on their technical SEO. You’ve built something genuinely useful here. Consider me a long-term user—I will definitely continue to pay for and use your tool as I keep launching more products this year.

        Rooting for your success, and let's crush it on our indie journeys!

        1. 1

          This made my evening, thank you for actually running it and writing back so openly.

          9 out of 11 is a strong result. Page speed is the most common warning I see, especially on beautiful sites with dynamic content and lots of script-loaded tools. As long as it doesn’t hurt the user, it’s fixable. WebP + lazy loading is the right move, and feeding the report into Codex is exactly the workflow I hoped people would use.

          Since you’re deep in GEO work, try other module: "Content Coverage & AI Readiness". The 14 AI Readiness checks (extractable passages, TL;DR signals, comparison tables, HowTo schema, etc.) are built for exactly what you’re doing.

          Also looked at goodtrans.app - the design is genuinely clean.

          Would you be open to me using your comment as the first testimonial on the IvaBot site? As a thank-you, I’d add a Mini credit pack (5 credits, $5) to your account. IH doesn’t have DMs, find me on LinkedIn (Galyna Arikh) or reply with the email you signed up with.

          Rooting for GoodTrans on the 27th.

          1. 1

            I am very honored that you have chosen to share my review as the first user review on the IvaBot website. I haven’t yet created a LinkedIn account, but I will contact you once I get one. I would also be happy to offer you some “goodtrans” translation credits. After all, my product might not be useful for everyone, hehe.

            1. 1

              Thank you for the kind offer, really appreciate the support. Let's stay in touch, ping me on LinkedIn once you're set up 🙌

  2. 2

    Honestly, I think a lot more founders are going through this than people admit.

    AI and modern tooling have dramatically lowered the barrier to building, but they also make it easier to start moving before the product structure, architecture, or long-term workflow is fully thought through.

    The hard part is that early momentum feels productive… until rewrites start compounding.

    One thing I keep noticing is that the real cost usually isn’t the rewrite itself — it’s all the lost time from changing assumptions:

    • product direction
    • workflow design
    • architecture
    • data structure
    • user expectations

    That’s a big part of why we’ve been thinking so much about upfront product clarity and structured planning while building Agiloop. Not heavyweight requirements — just enough alignment that the system can evolve without constantly restarting.

    1. 1

      Can't disagree. And now that experience is part of me. I made plenty of mistakes on the first product, learned a lot, and there's still a lot ahead. But the truth is exactly what I'd do differently next time: plan clearly, draft, test with real users for real feedback, and lock in upfront product clarity before diving deeper.

      You've reinforced the conclusions I'm taking away from this thread and from this whole experience.

  3. 2

    Three rewrites in nine months sounds slow until you count what the first two taught you about your own data model. Mine took two rewrites before the schema stopped fighting me, and the third took a weekend because by then I knew the shape of the thing. The 9 months bought the last 2 days.

    1. 1

      Haha, yes! Today I added new parts to my AI Readiness audit in half a day. Six months ago that would have taken weeks. Good observation!

      And honestly I appreciate that part of the journey. I learned a lot of skills along the way that I would not have picked up any other way.

      One more thing on this. I think I will keep changing and rewriting forever, but with much better understanding each time. I am a perfectionist at heart and I always want to make it better than it was. Not sure if that is a good thing or a bad thing.

      1. 1

        The bad kind of rewrite is redoing the same layer for the same reason. The good kind is what you just described: half a day for something that used to take weeks, because the schema finally stopped fighting you. Perfectionism only costs you when you can't tell those two apart.

        1. 1

          The diagnostic is sharp. I can map my own rewrites onto it. The pricing one was the bad kind for a while, I kept redoing it for the same reason (assuming subscription was the only model) until I questioned the assumption itself. The auth rewrite was the good kind: each version taught me something the previous one couldn't, and the final one took days instead of weeks.
          Knowing which is which is the actual skill.

  4. 2

    Nine months solo with three stack rewrites and you shipped and got a real Stripe payment. That is the path. Most people reading this have not done what you did.

    One thing I would add to your 'what I would do differently' list: validate payment intent before building, not after. Not 'people said they would pay' -- actual money in an account, before the product exists. I am testing this right now with BillWatch, a federal bill tracker for small business owners. Landing page only, no product yet, pre-orders at /month. Every person who pre-orders tells me something the waitlist-only people never would -- the ones who paid are compliance folks and accountants, not the politically engaged founders I assumed were my audience. That reshaped the whole product.

    The 9 months makes sense when you were also learning full-stack from scratch. The right question now is: what is the cheapest test to find out if someone will pay for module 4 before you build it? The first Stripe payment you got is not the ceiling -- it is the starting point for figuring out who actually has the problem badly enough to solve it.

    billwatch-landing.vercel.app -- not to pitch, just to show what I mean by 'landing page only.'

    1. 1

      Quick follow-up question if you have a moment: where did you drive traffic to the BillWatch landing page for the pre-orders? That's the part I keep getting stuck on, building a validation page is easy, getting enough relevant eyeballs to it without an audience is the hard part. Curious what worked for you.

    2. 1

      Pre-orders before product is one of the cleanest validation methods. The compliance-vs-founders surprise from BillWatch is the kind of signal nothing else gives you.

      Honest answer: validation worked backwards for me, partly because IvaBot is also a tool I built for myself. I work as an SEO specialist and run audits like these constantly. So beyond making SEO accessible for non-SEO people, usually small businesses, I was always going to use this tool myself. Whether other people pay or not is the second question.

      Your point still stands for anyone building something they will not use. Validate first, then invest. My situation was just different, I would have built it anyway.
      The landing page approach for BillWatch is sharp. Going to take a look.

  5. 2

    Slow solo here too. Three months on a Telegram quiz platform in production with paying users — and the build path was basically "rewrite everything once I knew what I actually needed." Your 9 months isn't slow. It's the realistic number when you're learning the tools while you're building with them. On dev vs marketing: I underestimated marketing by an order of magnitude. I had a working product for months before anyone outside my network heard of it. The thing I'm betting on now is that writing publicly about the technical decisions reaches more people than writing about the product itself. The blog post you mentioned (ChatGPT/Perplexity/Claude/Google citing different sources for the same query) is actually your real positioning. Every other SEO tool optimizes for Google rank. Yours measures readiness for AI citation — that comparative data IS the differentiator. A monthly version of that report, broken down by industry, would probably do more for top-of-funnel than any paid ad.
    Congrats on the first Stripe payment. That one hits different after 9 months alone with the doubts.

    1. 1

      This is the most useful comment in the thread, thank you. The "writing about technical decisions reaches more than writing about the product" point is one I needed to hear. I've been overthinking the line between honest engineering posts and content marketing, and you just made it obvious they're the same thing if the engineering is honest enough.

      The monthly comparative report idea is sharp. AI citation patterns by industry would compound in a way ads never will. Going to sit with that.
      Three months solo with paying users is a real ship too. Good luck with what's next!

      1. 1

        That overthink is a trap I lived in for months — built the product, told no one, kept telling myself I'd "do marketing later." Your reframe is cleaner than what I'd landed on. I'd convinced myself the technical posts were "documenting" (safe, virtuous) and the marketing posts were "selling" (cringe). Calling them the same thing if the engineering is honest collapses the false dichotomy. Stealing this framing — and testing it this week. If you ship the monthly comparative report, I'll subscribe. That angle is too rare to leave on the table.
        Good luck with the Product Hunt launch — May 27 is right around the corner.

        1. 1

          Noted on the monthly report - that's the kind of accountability that turns "good idea I might do" into "thing I actually ship." I'll keep you posted when it's ready.

          Thanks for spending the time in this thread! Most of what stays with me from today is going to come from this exchange.

          1. 2

            Likewise — most of what I'm carrying out of this thread is your "honest engineering IS the marketing" reframe. That's going to shape what I write next week.

  6. 2

    Nine months is not slow — it is honest. The founders I have consulted with who shipped in 6 weeks usually spent the next 6 months untangling tech debt that blocked every feature they wanted to build next. You built something real and got a paying customer. That is the actual benchmark.

    On dev vs marketing balance: strict time-boxing works better than splitting every day. A week of focused build followed by a week of focused outreach tends to produce better output than 4 hours of each daily. Context switching at this stage is genuinely expensive.

    The stack cost reduction is underrated as a signal. Going from $200 to $40/month before revenue is the kind of infrastructure discipline that keeps you in the game long enough to find product-market fit. Most no-code-heavy stacks quietly become anchors around month 8-12 when you need to add something the tools do not support.

    The AI citation readiness angle is real and differentiated. Curious: are you tracking which content attributes (structure, source links, entity density) correlate most with getting cited across different AI engines? That data would be genuinely valuable product signal.

    1. 1

      Thanks for this, the 9 months framing especially! That's the part I needed to hear today, the constant "shipped in 6 weeks" stories are exhausting when you know what it actually takes solo.

      The time-boxing point lands too. I had been splitting days and feeling the cost without naming it. Switching to week blocks.

      On the correlations question: not yet at the scale to claim real patterns from my own data. Working from my own testing and 2026 benchmarks for now, which point to a consistent stack of factors (structure, schema, original data, depth, freshness, author signals). The next module I'm building is around exactly that, surfacing which of those are missing on a given page. The data will sharpen as more sites use it.

      1. 2

        The approach of grounding in benchmark data first, then letting product usage sharpen the signal, is exactly how good data products get built — start with hypotheses, validate with real usage over time.

        Of those six factors you mentioned, freshness and author signals are probably the most underweighted by traditional SEO tools. Most platforms still treat a page as a static object, but AI engines seem to reward "live" content and identifiable expertise behind the writing.

        Good luck with the Product Hunt launch on May 27 — shipping solo through 9 months and 3 stack rewrites to get there is genuinely impressive work.

        1. 1

          Thanks for the PH wishes and the framing in the previous reply. This is the kind of conversation I was hoping for when I posted.

          1. 2

            That's great to hear. The fact that you shipped through 3 stack rewrites is a real signal — most people would have quit at the second. Good luck with what comes next.

  7. 1

    Nine months solo, non-dev, three rewrites, learning the backend from scratch with AI as your teacher — and a live Stripe payment at the end of it. That's not slow, that's stubborn in the best way. Respect.
    On the dev-vs-marketing balance, I went the other way and it's its own kind of hard. I'm a non-dev solo founder too, and I got so scared of the "build for 9 months then hope someone wants it" trap that I flipped the order: landing page + waitlist first, see if strangers will actually give me an email, then build. The downside is it feels backwards — you're "marketing" something that doesn't exist yet, and some days that feels fake. But it's already saved me from one build into silence.
    No clean answer on the balance, honestly. But the $200 → $40 cut after moving to Claude + a real stack hit home — went through almost the exact same "my no-code bill is eating me alive before a single sale" moment.

    1. 1

      Thanks for the support. Actually someone in this thread already raised the same idea- landing page first, sell before you build and it makes a lot of sense.

      My original goal was to make something simple, and something I could use myself. Each rewrite made it better, and at some point I started building for the user too, not just for me. So even if no one signs up, I'll keep using IvaBot for my own SEO audits and tests. That's been a quiet safety net through the whole 9 months, the tool earns its keep either way.

      Where did you find your audience to test whether your tool was needed? That's the part I'm worst at, and I'd genuinely like to hear how you got those first emails on the waitlist.

  8. 1

    My first batch image processing tool was launched in just one weekend, and it has been iterated for five months. It is still being iterated and its features are being added. At first, I didn't pay much attention to the promotion and operation of this tool. As a result, almost no one knew about it or used it. Later, I started to add effective and useful backlinks, and the site ranking improved slightly. The number of clicks increased, and I occasionally received feedback from users. I am not currently running this business full-time; I am just doing it part-time. However, I do my side hustle whenever I have free time. I persist in doing things that may fail, because if I don't do them, I will not have the opportunity to change the status quo.
    I usually work on my product tools after my family goes to sleep at night and get up an hour or two earlier in the morning. I also use my commute to communicate with AI and learn more about SEO. As a front-end application development engineer with 10+ years of experience, I have a lot of knowledge to learn.

    1. 1

      Respect for the part-time grind, those late-night and pre-family-wakeup hours are how most of us actually ship. The backlinks-then-clicks pattern matches my experience exactly: writing alone doesn't move much in year one without outreach in parallel.

      1. 1

        Yes, at first I only focused on technical output and completely ignored promotional work. Later, I gradually realized that I should try my best to promote what I output. Without promotion, no one would know.

        1. 1

          The market is so saturated now that proper SEO and marketing aren’t optional anymore. Since I published that post, I’ve been actively sending cold emails, posting on LinkedIn, writing SEO articles for organic traffic, and working on AI Readiness - trying every channel in parallel. And as you pointed out, backlinks and mentions are one of the foundations of it all.

          Wishing you steady growth on your batch image tool - five months of iteration on a side project while working full-time and raising a family is the kind of persistence that eventually compounds.

          And to make the point: it’s Sunday evening here, and I’m opening the laptop again to get a bit more done. :)

  9. 1

    I have been a software developer for decades and fluent in servers, networking and cloud services as well. I just built a new type of relationship app in 4 months. 16-22 hours per day for 4 months, so probably close to the same man-hours that you put in.

    I was completely focused on building everything from the schema to the CSS. Marketing is now what I need and I find that harder than building awesome software.

    I also started using Claude about half way through to speed up the front end development, as that is my weakest coding ability. He definitely sped things up, but he also has some very bad habits I had to talk him out of.

    1. tendency to replace an entire module rather than fix the one line that was wrong. This is bad if you have already tested that module, you now need to retest everything in that module and anything that relies upon it.
    2. inconsistency code style. Doesn't matter if you don't care to understand the code itself, but if you intend to do manual maintenance in the future, having similar things work in a similar way will certainly help you understand what is going on.
    3. guessing when debugging. A certain amount of guess-work is normal when debugging, but it is better to check what the cause could be and investigate that. Also randomly changing your code while guessing can break things that were working previously. After 3 guesses, I ask him if he is guessing and he admits it and we then investigate rather than guessing. It is faster that way.
    4. he can overly complicate things. Knowing how to code gives me an advantage when he brings back code that is inefficient. I can ask him why, or explain a better way of doing things and he responds well to that critique. Be especially careful with database retrievals, as he sometimes pulls back more rows, or unnecessary columns which will slow down your database at scale. You may not notice it today with 1,000 users, but when you have 1 million users and everything crawls, this is why.
    5. generic variable naming conventions. It took a while to get him to stop naming functions and variables as generic versions, when I knew we would need a similar function or variable in a different module. This would lead to confusion later on and very likely the introduction of bugs. Suggest better names if you don't like what he came up with.

    That was more than I intended. It got away from me, yeah. Claude is an excellent tool for development, the best I have found, just be aware he is at the same level as a 6 month in Junior Developer, not even an intermediate developer and he needs supervision and direction to excel.

    So well done on getting something working. Getting something working as a non-developer in 9 months is amazing!

    I wish you the best in getting the marketing done and people using your product.

    I am just starting with the marketing and as capable as I am, marketing is not my strong suit, and not where I should be focusing my efforts. I think I need to find someone to help me with that.

    1. 1

      Thank you for such a detailed comment. And yes, I completely agree. Even without knowing how to work with code, I noticed the same patterns. Generic variable naming conventions killed me every time. Overcomplicating code - yes, also noticed. Reaching for complex paths when simple ones are right there - went through that too. But I learned to see it, sometimes intuitively sensing we're going the wrong direction.

      I'd add one more point. I put my entire SEO experience into prompts, as much as I could. And built a chain: trigger → process prompt → take data received from user → process further, and so on. And Claude kept stubbornly cutting them, removing things that are super important for audits. And instead of telling me that, we together hunted for errors in the code. That drove me out of my mind a thousand times until we understood each other. So yes, Claude is an amazing tool, but you also need to watch, direct, and prompt. For me it was like a helper who is also learning.
      Wishing you success with the marketing side. I'm in the same boat - finding it harder than building. Good luck!

      1. 1

        I have seen similar shortcuts when dealing with Claude. I ended up talking with him for a long while and having him build a context file about me. That helps now because he knows my background and experience and no longer treats me like someone new to coding.
        Context files are super important when working with Claude. I let him build them with what is important for him to remember. He tends to get the nuance more correct if I phrase it like that.
        You can load multiple context files into a conversation, so usually it is the one about me, and the project context file. Sometimes I add something else relevant, like a specification on the specific piece we are working on. It saves a lot of time and frustration.
        Every new conversation with him starts out a little rocky when building code. I have learned what rules I need to reiterate to him and now we get moving in the right direction in the first 20 minutes instead of 90 minutes. I will keep refining that, although I see that a lot of those rules have made it into the context file now.
        Talk with Claude like a real partner and he will respond much better than if you demand results from a tool.

        1. 1

          After your first comment I went to check my prompts - some of mine are up to 25,000 words, tuned to the millimeter. And in one of my tools Claude had quietly compressed a 25k prompt down to 12k. I had no backup. It took me two days to rebuild it piece by piece.

          The funny part: he knew the rule “don’t touch the prompts.” He just decided it applied to the edge functions but not to the Make scenario. So my spec rules got a lot more explicit yesterday.

          I agree structured specs helps a lot, but even then it can lag.
          Still, I think Claude is a genuinely brilliant tool, and I’m grateful to it for opening up possibilities I couldn’t have reached alone.

  10. 1

    Nine months is almost exactly our timeline too. We rebuilt the data layer three times - started monitoring everything (news, social, legal databases) and ended up doing one thing: Congressional bill tracking by keyword and sponsor, delivered to Gmail or SMS.

    The convergence that unlocked the first Stripe payment was the same pattern you're describing. Narrowing scope until the value became undeniable rather than impressive. The rewrites weren't wasted - they taught us what the product actually was.

    First payment is a real signal. Most founders hit it and then immediately try to expand scope again. The rare move is to go narrower still until the retention proves out. Congrats on getting there.

    1. 1

      Going from "monitoring everything" to "Congressional bills by keyword and sponsor delivered to Gmail or SMS" is exactly the kind of convergence that takes nine months because the first eight teach you what to cut. The rewrites aren't waste, they're how you find the spine of the thing.

      The "go narrower after first payment, not wider" warning lands hard. My instinct after the first Stripe charge was the opposite - three modules, expand each, add a fourth. I'm sitting with that this week. If I had to pick the one module that delivered the most undeniable value, it would be the Content Coverage & AI Readiness audit, because that's the part nobody else is doing right now. Worth thinking about what gets cut versus what gets sharpened.

      Good luck with the bill tracker. The Gmail-or-SMS delivery is the right call - meeting people where they already are.

  11. 1

    Honestly, this was refreshing to read because it sounds much closer to real solo-founder building than the “built in 14 days, hit $20k MRR” stories we constantly see online.

    The part that stood out most:

    “AI was my teacher.”

    I think we’re entering a phase where non-traditional builders can finally execute ideas that previously required full engineering teams — not because AI replaces expertise, but because it reduces the fear barrier to learning and building.

    Also relatable:
    rewriting stacks, rebuilding systems, realizing the first architecture wasn’t scalable, spending months learning things nobody sees from the outside.

    People usually celebrate launches.
    Very few talk honestly about the messy middle.

    And honestly? Getting the first Stripe payment after building something alone for months is a huge milestone.

    Wishing you a great Product Hunt launch 🚀

    1. 1

      Thank you for putting it that way. You touched on the role of AI in the new world really well. I'd add one thing, beyond reducing the fear barrier to learning and building, AI opens the door to creativity itself. You don't need a big budget anymore to create something interesting. Solo founders have more free hands now, and probably more competition too. But that's what makes it interesting.

  12. 1

    The stack rewrites are so relatable — I think every dev secretly believes the next framework will be the one that finally ships. Glad you pushed through anyway.

    1. 1

      Haha, this might sound strange, but I'm so glad I'm not alone in this. Reading the comments here has been the biggest unexpected gift of the post - most of what I'd been telling myself privately turned out to be the universal solo founder experience.

  13. 1

    The blog post about how ChatGPT, Perplexity, Claude, and Google AI cite different sources for the same query is your strongest asset going into the May 27 PH launch — it demonstrates the exact problem IvaBot solves instead of just describing it, and SEO founders are already searching for that data. Leading with the comparative engine-citation finding as the hook will give PH visitors a specific reason to care before they’ve heard the pitch in a way that “AI citation readiness tool” on its own won’t.

    One thing worth solving before the launch: PAYG at $5 creates low first-purchase friction, but audits aren’t naturally recurring events. The retention trigger probably isn’t a reminder to run another audit — it’s a change in how a specific AI engine weights citations. Even a lightweight email alert for that (score drop, competitor gains a citation you lost) would shift IvaBot from a one-time diagnostic to a monitoring habit, which is a completely different retention story.

    1. 1

      Both points land. The second one shifts how I'd thought about the retention layer - reminder-to-re-audit puts the work on the user, a change-in-engine-weighting or competitor-gain alert puts the work on me to notice something they would have missed. Real difference in product behavior. Adding to the change detection notes.

      On the blog data as hook for May 27: agreed. The comparative engine finding is what people already lean in for. Reworking the PH first comment to lead with that, not with the modules. Thank you for this comment!

  14. 1

    The 9 months isn't really the build, it's the apprenticeship. You shipped two things at once: the product, and yourself as someone who can build the product. The first one converts to MRR. The second compounds into every project that comes next at maybe 10x the speed. Most founders only count the first. The second is where the real return on the 9 months lives.

    1. 1

      The second one is the part I haven't been counting. The product feels visible because it has a URL and a price, but the version of me that exists now didn't exist nine months ago. That person used to outsource every technical decision and feel small in conversations with developers. This one debugged Stripe webhooks at 2 a.m. last week and felt fine about it.

      I'll remember this comment the next time I'm tempted to apologize for the timeline.

  15. 1

    The 'everyone ships in 2-3 months' line is mostly survivorship bias. Most don't ship at all. 9 months solo, no dev background, three pivots, and a Stripe charge at the end is a fast outcome by any honest measure. The real asset you built isn't the stack, it's 15 years of SEO judgment baked into the audit logic. Competitors with twice your engineering speed can't replicate that. Next move I'd focus on: find 10 SEO consultants who already audit client sites manually, give them free credits, and let them sell IvaBot for you. Distribution is now your bottleneck, not code.

    1. 1

      Yes, the 15 years are real, and honestly some things are still hard to fully automate. After enough years in SEO you build a kind of intuition that's hard to put into rules. I tried to bake into IvaBot the things I actually look at and consider important when I run audits manually. The rest is on my list to refine and improve over time.

      The consultant channel idea is sharp. Not for this month, I want the first 10 direct buyers to find enough value first, before asking consultants to put their reputation behind the tool. But the model is clean: people who already audit manually are the right wedge. Going into the long-term notes.

  16. 1

    Adding to this - three things worth setting up before that next signup, and they're not feature work, so they don't conflict with the "distribution first" focus this thread keeps landing on:

    One: authorization on every endpoint, not just authentication. Being logged in isn't a check. Every request that reads or writes a record needs to verify this user owns that record.

    Two: signature validation on every webhook you accept. Stripe especially. Without it, anyone who knows the URL can post fake payment events at your endpoint. Stripe's library has a one-liner for it.

    Three: secrets in environment variables, never in the repo. Rotate anything that's ever been committed, including to a private repo, because private repos are one careless invitation away from public.

    These aren't AI-code bugs. They're move-fast bugs that AI made easier to ship, because the model will happily generate the auth-check-free endpoint and won't flag what's missing. Worth an evening of your time.

    1. 1

      Thank you! doing the full checkup based on this list. These are exactly the things I wouldn't have caught on my own. Neither ChatGPT nor Claude sees the full picture at once, they happily generate the auth-free code and never flag what's missing.

      Really appreciate you writing it out.

      1. 1

        Glad it's useful. The fastest test for #1 is logging in as two different users and trying to access each other's IDs. Tells you immediately if there's a gap. Good luck with the checkup.

        1. 1

          doing doublecheck! Thanks

  17. 1

    This hit close to home. I'm a solo founder too — built LifePilot (iOS app that turns goals into 4 daily actions) and today is literally my first real public launch on Uneed. No team, no launch squad, I'm even traveling alone while watching the upvote counter.

    The 9 months and 3 rewrites part is real for everyone who builds without a team. You just don't see it from outside. Congrats on the first Stripe payment — that one always feels different.

    If you're curious how a solo launch looks in real time: https://www.uneed.best/product/lifepilot-ai-planner

    1. 1

      Solo launch in real time and traveling alone while watching the counter is the most honest version of "indie hacking" I've read today. Going to check LifePilot - turning goals into 4 daily actions is the kind of constraint that makes a product actually useful.
      Hope the counter moves the way you want. Either way, you shipped, and that's the part that stays.

      1. 2

        That last line is going straight into my notes. Thank you — genuinely. Hope you find something useful in LifePilot.

  18. 1

    The $200 to $40/month optimization is incredible. The key insight here that often gets missed: you didn't need a no-code tool to validate, you needed to learn how to build. Using Claude to learn the fundamentals while building (webhooks, HTTP, JSON parsing, etc.) is exactly the right approach for a non-technical founder. Most people get stuck trying to outsource all the learning. Your timeline (9 months from zero to paying customers) is legit solid, especially launching with live Stripe payments and already with viral traction (that ChatGPT/Perplexity blog post). One question: are you planning to keep the $5 entry point, or does the May 27 PH launch change pricing strategy?

    1. 1

      The "didn't need a no-code tool, needed to learn how to build" point is the sharpest version of that idea in this thread. Most people frame it as outsourcing speed, you framed it as outsourcing learning, which is exactly the trap.

      Keeping the $5 entry point through PH and beyond. The work I'm focused on isn't price level but conversion - first audit ROI, score-gap visualization, change detection so users have a reason to come back. Will revisit pricing only after I see what the second-purchase rate actually looks like.

  19. 1

    Congrats on shipping. 9 months feels long when you read it back, but the lessons compound. My first product took 8 months and my 8th took 4 weeks because the same boring problems repeat (auth, billing, error tracking, legal pages, basic analytics, a working landing).

    Two things that helped me cut time the most after product number 3:

    1. A ship-ready checklist locked in stone. Auth + Stripe + Sentry + privacy/terms + plausible. If any of those is missing I'm not done. If I'm tempted to add anything beyond, it goes to v2.

    2. No stack rewrites after week 1. The cost of switching from Typebot to Claude was probably worth it for you because the unit economics changed, but if I had done that 3 times in product number 1 I would have quit. After week 1 I force myself to ship on whatever ugly thing I picked first.

    On IvaBot: the PAYG at $5 against $50-300/mo competitors is a real wedge, the audience just needs to see that comparison front and center. Most SEO founders I know will pay $5 to test a tool but never sign up for $50/mo from a name they have not heard of.

    Good luck with the next two weeks of traffic. The second paying customer is usually the hardest one because it confirms the first was not a fluke.

    1. 1

      Eight products in is the kind of pattern recognition I'm still building. The locked ship-ready checklist is going into my notes: Auth, Stripe, error tracking, legal, analytics - every "but one more thing" goes to v2. That single rule would have saved me weeks.
      The $5 versus $50-300 comparison front and center is something I've been treating as a footnote. It should be the headline. Going to rework the landing around it before PH.

      "Second paying customer confirms the first wasn't a fluke" — that's the words I needed for the next 30 days. Watching for it.

  20. 1

    The $200 to $40 stack switch is an underrated milestone — it's not just about cost savings, it shows you understood your product well enough to cut the dependencies you no longer needed. And the 9-month timeline is something to own, not apologize for: you weren't slow, you were teaching yourself a completely new discipline while shipping something real. That Typebot phase where ChatGPT was your teacher for 6 months clearly laid the foundation that made the Claude rewrite possible — most people skip that kind of deep hands-on learning and pay for it later in technical debt. Congrats on the first paying customer, that's the real milestone.

    1. 1

      The Typebot phase as foundational learning is the version of that argument I needed to hear today. Spent months wondering if those six months were wasted, and the answer that keeps coming back through this thread is: only if you didn't learn anything. I did, and now the second-time decisions are faster because of it.

      Cutting dependencies you no longer need is a different muscle from picking them in the first place. Thanks for the read.

  21. 1

    9 months doesn't sound slow to me — it sounds honest.

    I'm also building solo right now. Just launched an AI citation tracking tool
    (which is funny because your IvaBot literally checks AI citation readiness —
    we're solving adjacent problems from different angles).

    The stack rewrite cycle hit close to home. I went through similar phases
    before finding a setup that actually worked. And the moment you said
    "my partner is tired of hearing about Stripe webhooks" — I felt that deeply.

    One thing that helped me: I stopped thinking of rewrites as failures and
    started calling them "paid education." You clearly learned something real
    at each stage — the Typebot phase alone sounds like it taught you more
    than any course would have.

    Congrats on the first Stripe payment. That one hits different.

    1. 1

      Adjacent angles is a generous read - citation tracking and citation readiness are two halves of the same workflow that nobody is putting together yet. The "paid education" reframe is the cleanest version of that idea I have heard in this thread. Going to sit with that one.

      Good luck with the launch! If you want to compare notes on this market at some point, happy to.

  22. 1

    this post is very refreshing, alot of people can learn secondhand through you

  23. 1

    3 stack rewrites — I felt that. I come from industrial automation (PLCs, SCADA systems) and building a SaaS was a completely different world. The hardest part wasn't learning React or setting up Stripe — it was the constant second-guessing about whether the architecture would hold up once real users showed up.

    What finally got me to stop rewriting and start shipping was accepting that version 1 doesn't need to be perfect. It needs to exist. Congrats on getting it out the door. That takes more courage than most people realize.

    1. 1

      "Version 1 doesn't need to be perfect. It needs to exist" - that landed for me too. You can always come back to fix things. The point is to show up to the world.
      Industrial automation to SaaS is a brutal context switch. PLCs and SCADA teach a different kind of thinking, deterministic, deadline-physical. SaaS is the opposite, shipping into uncertainty. Respect for making that transition.

  24. 1

    This felt very real to read. I think a lot of solo founders quietly go through the rewrite phase but never talk about it publicly. The $200 → $40/month cost drop also stood out, that kind of discipline matters way more than people realize early on.

    Congrats on the first Stripe payment. That’s a huge milestone.

    1. 1

      "A lot of solo founders quietly go through the rewrite phase but never talk about it publicly" - you put that well. It's exactly because of this post that I realised I'm not alone. Usually people only share successful successes, and against that background I was sure I was doing something wrong.

      Hope your comment and the others here reach solo founders who are struggling right now.

  25. 1

    On the PAYG pricing, smart for first-purchase friction but the trap for audit tools is that audits aren't naturally recurring. Someone runs the audit, applies whatever the report flags, and that's it. No reason to come back until something changes on the site. The retention play for IvaBot probably isn't pricing tiers but a change detection layer that pings users when their score drops or when their competitors get cited and they don't. That turns a one-time tool into a monitoring habit. PH launch traffic will tell you who buys once. The next 30 days will tell you who buys twice.

    1. 1

      "Audits aren't naturally recurring" is exactly right and it's been quietly worrying me. Change detection is already on my roadmap - pinging users when their score drops after they apply fixes. The competitor citation alert is a sharper angle I hadn't worked out yet. Turns "run it once" into "leave it watching."

      "Buys once vs buys twice" is the cleanest framing of retention I have seen. Writing it down as the metric to watch through June.

  26. 1

    Great post! I really resonate with the struggle of stack rewrites. I’m currently building my first SaaS for local businesses, and I also went through some challenges while containerizing it for Azure deployment. It’s definitely not easy to ship, but the learning process is worth it. Congrats on finally launching!

    1. 1

      Local businesses is a market with real problems and real budgets, but distribution is harder because they're not on platforms like IH. Containerization pain for Azure stays with you. The learning sticks though.
      Good luck with the launch!

      1. 2

        mine were the same - different wrong assumption each time. three sprint planner versions and i'm still not sure i got the core use case right

  27. 1

    Nine months solo is not slow. It is honest. The
    people who "ship in 2-3 months" are usually
    shipping a landing page, not a working product with
    three modules, Stripe integration, and a real
    backend.

    I am months into building protocol infrastructure
    as a solo founder. Claude changed my velocity too.
    The shift from "AI as a curiosity" to "AI as a
    daily implementation tool" is the single biggest
    productivity unlock I have found. Your cost drop
    from $200/month to $40/month by cutting the no-code
    stack and building properly with Claude is a
    pattern I think more solo founders will follow.

    To your question about balancing dev time against
    marketing time: I spent the first 5 months on pure
    dev with zero public presence. Started posting a few
    weeks ago. The mistake was not starting
    conversations earlier, because the feedback changes
    how you explain and position the product. You do
    not need to stop building to do marketing. You just
    need to talk about what you are building while you
    build it. Even one post a week changes the
    trajectory.

    Congrats on the first Stripe payment. That is the
    hardest one to get.

    1. 1

      The "talk about it while you build it" point is the one I wish I had read 8 months ago. I went silent for the first 7 months convinced I needed "something worth showing" before posting, and that delay cost me the feedback that would have changed how I positioned the product. One post a week sounds small until you compound it over a year of build time.
      Good luck with the protocol infrastructure - that's a brutal but well-defined market.

      1. 2

        Exactly. The compounding effect is real. Good luck
        with the Product Hunt launch on the 27th.

  28. 1

    i feel you on the github usage and the rewrite. My first rewrite was thanks to GPT Codex after i gave it full control and it messed up my code.( actual deletion of code files)

    1. 1

      Actual file deletion is the kind of trauma you don't forget. I had a smaller version of that with overwrites. Now I backup everything before any AI touches it and never give full write access without a git checkpoint. Hard lesson.

  29. 1

    9 months as a non-developer with 3 rewrites is not slow, it's the actual pace. The 2-3 month ship stories are selection bias, we only hear the fast launches because slow ones get abandoned before they post about them. The Typebot phase wasn't wasted either, every prompt and webhook you wrote is muscle that compounds on the next thing you build. The trap now is going back to product, more modules, more polish, when the bottleneck is distribution. Your first Stripe payment is the signal to spend the next 90 days finding ten more of that exact buyer, not adding features.

    1. 1

      The selection bias point explains why every fast-launch story made me feel slow while building. The Typebot reframe is also kinder than I'd been allowing it to be.
      But the 90-day frame is the most concrete piece of advice in this thread. Ten more of that exact buyer is a measurable goal, not vibes. Going to write it down where I can see it.

  30. 1

    9 months and 3 rewrites without quitting is the actual skill. I've been building PM tools on the side for 2 years - rewrites are where you figure out what the thing actually is. congrats on the first Stripe.

    1. 1

      "Rewrites are where you figure out what the thing actually is" is the cleanest way to put it. Mine were less about code quality and more about each one teaching me which assumption was wrong underneath. Two years of side PM tools probably gives you that pattern recognition faster than I got it.
      Thanks for the read.

  31. 1

    Really resonated with this, especially the 9 months and 3 rewrites part. I'm in a similar spot, solo founder, built an e-signature tool, just launched it a couple of weeks ago. The stack decisions alone can eat months. I started with the right stack luckily (Next.js + Neon + Vercel) so I avoided the rewrite pain, but the distribution side is where I'm struggling now. Every platform has restrictions for new accounts - Reddit flags you for spam, HN won't let you comment on your own post, directories need 7-day-old accounts. Building was maybe 30% of the work. The "what I would do differently" section hit hard, especially "think about security from day one." Good luck with the PH launch on the 27th!

    1. 1

      Next.js + Neon + Vercel from day one is the dream, congrats on avoiding the rewrite tax most of us paid in tuition.
      Distribution restrictions you listed match my experience. Reddit treats new accounts as read-only, directories want 7-30 day account age. The workaround working for me is writing publicly on Indie Hackers, this post is the example. Content plus community, no platform restrictions apply.
      Good luck with the launch!

      1. 2

        Thanks! That's a good point about writing publicly — Indie Hackers does feel like the least restrictive platform for founders. I might steal that approach. My PH launch is actually May 26th (day before yours!) so we're almost in sync. Would be curious to compare notes after both launches. Good luck with IvaBot!

  32. 1

    9 months is real, and not that slow if the product came out right. Dev vs. marketing balance is the right question, but here's what took me too long to learn: marketing doesn't start after you ship. The best product decisions I ever made came from customer conversations I had while still building, even one call a week. Not for validation theater, just to stay honest about who you're actually building for. Did you talk to potential users during the build, or mostly after launch?

    1. 1

      Honest answer is mostly after launch. During the build I had friends and former colleagues test it, but that's a different kind of feedback, they want you to succeed, so they soften the rough edges instead of naming them. I'm only now starting to get feedback from people with no relationship to me, and it's a different signal entirely.

      The "validation theater" framing lands. Most of what I did before launch was emotionally biased toward "is this good enough to ship," not "is this what they actually need."

  33. 1

    the blog post about how ChatGPT, Perplexity, Claude, and Google AI cite different sources for the same query going slightly viral makes sense because nobody has good data on that yet and it's the question every SEO person is quietly panicking about. how did you find it, did you write it before or after the product launched and how much traffic did slightly viral actually mean in absolute terms? asking because that content strategy is probably your best distribution channel right now and it would be worth understanding what made that specific post work

    1. 1

      Honestly, as an SEO specialist I could see what was getting urgent in the field and it was also something I genuinely wanted to understand for myself. I ran some tests on other sites and did a deep research pass, which helped me see the topic from multiple angles. The post ended up partly filling a real gap in that niche.

      On the traffic question, I'd rather not give numbers that overstate what it was. Honest answer is that I'm still in the early window where content compounds slowly. The point I'm taking from your comment is that this content angle is worth investing in more seriously as a channel.

  34. 1

    9 months from scratch plus learning and coming up with a saas product is just awesome. Will definitely try as I am a seo lead. Will give my feedback on this

    1. 1

      Thank you! As an SEO lead you're exactly the audience I built this for, so your feedback would mean a lot. The Core Audit is the fastest one to run if you want to start there (under 2 minutes). Happy to hear what works and what doesn't!

  35. 1

    This feels real because stack rewrites are often part of learning, especially for solo founders building while figuring things out. Reducing costs, shipping, and getting the first payment matters more than matching someone else’s timeline.
    Foundersbar helps startups focus on validation and sustainable product building so founders do not confuse speed with progress.

    1. 1

      Thank you. The "don't confuse speed with progress" framing is a good one, that's actually been the main shift in my thinking this week.

  36. 1

    The B2C-to-B2B logic is clean, but there's one number missing from your post that's going to shape the pivot more than reply rate or demo close rate: your effective price per user is ~$14 ($650 / 45 paying). That's the anchor your B2B per-seat pricing will get back-solved from, whether you want it to or not — the first agency that asks "what do your individual users pay?" will benchmark you against that.
    Two things worth pressure-testing before outreach hardens:

    Per-seat vs. per-cohort pricing. Agencies running peak season (March–Aug) don't want seat math — they want capacity. A "100 mocks/month, pooled across students" SKU usually closes faster than $X/seat because it matches how counselors actually think about their bottleneck.
    The waiver elimination is a pricing event, not just a demand event. Every B2C visa-prep tool in the Indian market is about to reprice or launch institutional tiers in the next 2 quarters. If you anchor low on the first 3 B2B deals, that becomes your ceiling for 12 months. Worth checking where the closest substitutes in Indian study-abroad counseling sit before you quote your first agency.

    One concrete thing to watch: the gap between what a counselor's hour costs the agency and what your tool replaces per hour. That delta is your real pricing room, not your B2C price.
    Also — 5% free-to-paid on a one-time product with no retention loop is genuinely strong. Don't let the pivot narrative bury that signal.

  37. 1

    Nine months is not slow, it's just honest. I went through a similar arc building a browser-based tool, where the first version worked but the architecture was wrong, and I had to tear it down and rebuild before anything felt shippable. The $200/mo to $40/mo cost reduction by ditching no-code for a custom backend is a move more solo founders should hear about. Curious how you're balancing dev time vs marketing now that you're post-launch.

    1. 1

      Your experience really resonates. Honestly, I didn't expect to find so many founders going through the same arc, so many comments here are about rewrites and rebuilds. It helps to know I'm not alone in this.

      On dev versus marketing: at first I was alternating a few days for one, a few for the other. But after reading what other solo founders said in this thread, I realised that without traffic, it doesn't make sense to spend much time on fixing or rewriting. There are no critical mistakes left, and at this stage it's more guessing what to change than rebuilding for real user needs. Distribution first, then iterate when there's actual feedback to iterate on.

  38. 1

    Eight months in, two rewrites done, and one I'm still kicking myself over — your timeline isn't an outlier. I'm a non-traditional solo dev too (a small iOS memo app, a Captio replacement). My biggest detour was a server-side sync layer I deleted before users ever saw it: three weeks of confidence drained right before launch. The pay-as-you-go from $5 is a smart call — subscriptions add a second friction layer most early SEO tools haven't earned yet. The first Stripe payment is a quiet shift; mine made me stop negotiating with the roadmap and start honoring usage data instead.

    1. 1

      Three weeks deleted right before launch is the kind of pain that doesn't show up in any retrospective post but stays with you. Respect for shipping anyway.

      The line about honoring usage data instead of negotiating with the roadmap is the cleanest version of that shift I've heard. I'm in the very early window of having any usage data, but I can already feel it, every assumption I made about what users would care about is quietly being tested by what they actually click.

  39. 1

    Love how this actually makes docs ‘doable’ for Ai instead of just readable brings testing and feedback full circle

  40. 1

    The rewrite cycle is real. I think most solo founders go through at least 2-3 before finding the right abstraction. What finally made you stop rewriting and ship?

    1. 1

      Honestly, I just forced myself to stop. It's not perfect, and I keep slapping my own hands to not slip back into improving. I hit a kind of minimum viable working point and decided to only rewrite based on real feedback, not my own fantasies about what users might want. So now I'm collecting feedback instead of guessing.

  41. 1

    The $200→$40 cost reduction before revenue is the kind of discipline most founders skip and then wonder why their runway evaporated. The other thing that stood out: you treated three stack rewrites as learning, not failure. That's the right read — each rewrite compressed your understanding of the problem until the third one only took a weekend. One framing I'd offer for after the Product Hunt launch: instead of adding more modules to this product, consider what adjacent tiny products share the same backend. A portfolio of small tools on the same infra distributes risk across buyers without multiplying your engineering burden.

    1. 1

      This comment really made me think. I was moving in the direction of more value in one place. But in my SEO practice, low-volume long-tail keywords with low competition bring less traffic at first but close real user pain points clearly and convert well. What you're describing is the same logic applied to product structure breaking one big tool with three modules into several small ones that each close a specific need precisely. Sharp parallel.

      Not saying I'll do this now. But once there's real traffic on the platform and I can read what's working and what isn't, I'll keep this strategy in mind.

  42. 1

    The $200/mo to $40/mo cost reduction by killing Typebot + Memberstack is a smart move that many solo founders delay too long. I went through a similar realization — no-code tools are great for prototyping but the monthly costs stack up fast before you have revenue. Curious about your pay-as-you-go pricing at $5 — how did you decide on that vs a subscription model? For a solo SEO tool, PAYG feels like the right call since usage can be irregular.

    1. 1

      "Monthly costs stack up fast before you have revenue" - that line is so true! I can't imagine how many interesting projects burned out for exactly that reason.

      On pricing, I went through three iterations. First I built bundled subscription packs, but looking from the user side I realised most people would only need one or two tools from a pack, and paying for the rest would feel like wasted money. So I rewrote it as per-tool monthly subscriptions. After shipping that I noticed another mismatch, some tools get used twice a month, others daily. That's when I rewrote pricing one more time into what finally felt right: buy exactly the tool you need, in the amount you'll use.

      1. 1

        Three pricing rewrites is painful but the end result makes sense. The "buy exactly the tool you need, in the amount you'll use" model removes the biggest objection for solo founders — paying monthly for something you use twice. How are you handling the UX for that? Is it credit-based, or do users pick a tool and pay per run?

        1. 1

          Credit-based per tool. Users pick which tool they need and buy a pack: Mini 5 for $5, Starter 15 for $12, Medium 30 for $21, Large 60 for $34. Credits don't expire and don't transfer between tools, so usage stays clean. Free tier gives 1 run of each.

          The reasoning: subscriptions felt punishing for irregular usage, but pay-per-single-run felt like friction every time. Packs split the difference, one purchase decision, then frictionless use until credits run out.

          1. 1

            The credit pack approach is clever — especially credits not expiring. That removes the "use it or lose it" pressure that makes people hesitate on the first purchase. One thing to watch: do users understand upfront how many credits a typical task costs? If a content audit burns 3 credits but they expected 1, that's a trust issue. A "this will cost X credits" confirmation before each run could prevent that.

            1. 1

              The expiration point was exactly the call I made for that reason, first purchase friction was the biggest blocker.

              On confirmation, you're right. The math in my case is simple (1 run = 1 credit, flat across tools), but a new user doesn't know that until they've done it once. A pre-run confirmation would prevent the small misunderstanding that costs a future purchase. Adding it to the next iteration. Good catch.

              1. 2

                That simplifies things a lot — 1 run = 1 credit removes the mental math entirely. And the confirmation screen is a small addition that pays off in retention. Sounds like you've got a solid foundation for the PH launch on the 27th. Will be watching for it!

  43. 1

    "This really resonates with me. I'm also a solo founder building TraderTracking — a trading journal for forex, crypto and stock traders. I went through a similar journey: months of development, multiple rewrites, and learning to make better architectural decisions along the way. I also moved my dev workflow to Claude and it was a game changer for productivity. The part about balancing development time with marketing is something I'm struggling with right now — just launched and trying to figure out the right split. Thanks for sharing so honestly, it helps knowing others go through the same grind."

    1. 1

      TraderTracking sounds like a good fit for the journaling niche. Best of luck with the launch.

      The dev versus marketing split is what I've been wrestling with this whole thread. Two reframes that helped: stop adding features until customer 50, and writing publicly about technical decisions counts as marketing if the engineering is honest enough.

  44. 1

    For the non-tech person it's really impressive result!

    First of all, you DID finish the product — it's already pretty nice :)

    You are free to ignore it, but: as a tech person, I would like to recommend you some product design actions to take before the implementation. From my point of view, the toughest part is not to build (it's already pretty hard) but to maintain what you have created. So you will definitely benefit from the planning stage.

    Besides that — wish you luck and a ton of subscribers!

    1. 2

      Thank you!

      and you're right about maintenance, I'm already feeling it (multiple file versions in the repo, naming inconsistencies, places where features were added without thinking about scale). Would be open to hearing what design actions you'd recommend, even retrospective ones for what's already built.

      Pay-as-you-go in my case, not subscribers, but I'll take the energy either way.

      1. 2

        I would say for the start it would be pretty enought to start from the simple diagram like excalidraw (its free to use) or even piece of paper.

        Try to describe or draw the plan or what you want to see into the "paper" and see it from the third person. In most cases you will find some gaps already. With the time it will be neccessary to do so as its impossible to keep everything in mind

        1. 2

          Thank you. I checked with Claude right after your comment, and it recommended Excalidraw as a good fit for my ecosystem too, as a free tool for diagramming and planning.

          Honestly, I've been putting off structuring and cleaning up the files because I keep rushing to do "something more useful." But the clutter is growing, and sooner or later I'll lose track of what's where.

          I'm going to take your advice, because I think the time I'm saving by ignoring order is going to play a bad trick on me later :)

  45. 1

    9 months is not slow, it's honest. Most people claiming 2-3 months either had prior experience, a cofounder, or didn't really ship. You came in with zero dev background and got a paying customer. That's the actual benchmark.\n\nThe stack cost drop from $200 to $40 before a single sale is also a real lesson a lot of people need to read. Congratulations on shipping it.

    1. 1

      Thank you for this comment, honestly. It was bothering me that I was moving too slowly, it felt like everyone around had this "successful success" story. But comments like yours bring my anxiety down. Everything is going at its own pace, and that pace is mine.

  46. 1

    The best advice I got was to launch as early as possible and actually talk to users. It's so tempting to keep polishing before showing anyone, but every time I've done that I ended up building things nobody wanted. Getting that first batch of feedback is brutal but so worth it. How did you find your first users?

    1. 1

      You're right, and from the start I knew I wanted to build for people who would actually use the tools. Finding the first users was harder than I expected. Most people in my circle don't speak English, and even those who do struggled to give feedback on SEO since it's not their world. It's hard to evaluate something you don't know.

      My first users were friends, friends of friends, a few former colleagues. A very small number came through organic traffic.
      I only discovered Indie Hackers, Reddit, and Product Hunt after I launched, so it's only now that I'm getting any meaningful feedback. And I'm honestly happy I found this world, experienced people, or others walking the same path I am.

      So thanks again for your comment. Would be glad to hear any feedback or advice on finding users if you have any.

  47. 1

    Nine months and three stack rewrites with a first Stripe payment is not a failure timeline, it is a real product timeline. The SEO + AI citation readiness angle is sharp and timely. One observation from someone who does this daily: the pay-as-you-go model at $5 is a strong entry point for solo founders but the challenge will be LTV. Make sure the first audit delivers enough actionable insight that users immediately see the ROI that is what drives the second purchase. On distribution: Reddit and Indie Hackers are great for early feedback, but for SEO tools the real distribution channel is SEO itself. The fact that you're already seeing impressions in Search Console is the early signal that matters most.

    1. 1

      Your comment carries real practitioner experience, thank you. Just shipped a bigger AI Readiness module this morning to push more actionable detail into that first run. The free-to-paid path still needs work though.

      When you say first audit ROI is what drives the second purchase, do you mean making the "next step" CTA more explicit (something like "Run another for $5 to track progress"), or building something into the audit itself that creates urgency? Or is it more about the framing - "You scored 65. Pages cited by AI engines typically score 80+", making the gap visible so the user wants to close it?

      It was interesting to hear your perspective because I still have few users and it's hard to draw conversion conclusions yet. But your comment made something click for me: giving a lot in the audit does not equal conversion, and I am almost certainly missing on the funnel side. That's a real shift in how I'm thinking about the next round of work.

      1. 1

        All three, but in this order: framing first, then CTA, then urgency. The score-gap framing you suggested is exactly what I mean. "You scored 65. Pages cited by AI engines typically score 80+." That makes the gap visible immediately. Once they see a specific number they're below, the ROI question answers itself. The CTA then becomes trivial: "Run another audit in 2 weeks with these fixes and see your score change." Urgency comes from the score itself, not from copy tricks. Don't overcomplicate it. Your framing instinct is right - build that gap visualization into the audit report.

        1. 1

          This is the kind of clarity I needed. Framing → CTA → urgency in that order, with urgency coming from the score itself instead of copy tricks. That settles a question I have been circling around for weeks.

          The gap visualization ("typically 80+, yours is 65") is going into the audit report as the next change. CTA writes itself once that's in place. Thank you for not letting me overcomplicate it.

          1. 2

            Glad it clicked. The gap-visualisation as the next build step is exactly right, once that's in the report, the rest flows naturally

        2. 1

          This comment was deleted 4 days ago.

  48. 1

    Nine months and three rewrites with a first Stripe payment is not a failure timeline, it is a real product timeline. The mistake most non-technical founders make is treating shipping as the finish line. You just hit the start line. From here the next 9 months should be about distribution, not more rewrites. Pick two channels you can run yourself given your SEO background (you have an unfair advantage on organic), and stop adding modules until customer 50. The product is built. Now sell it.

    1. 1

      This lands. I caught myself doing exactly that, wanting to add and improve before the traffic justifies it. There was a Reddit thread recently about how to stop adding features after launch and switch to marketing, and I recognised myself in every comment :)

      What I have started doing is alternating days: code, then SEO article on the site, then outreach. Organic traffic has already started to come in, so the SEO advantage you mentioned is real and beginning to compound. The build window is closing this week regardless, Product Hunt launch is in 7 days, and after that there are no new features until customer 50.

      Curious which two channels you would pick for a profile like mine - SEO specialist, no audience, small business niche.

  49. 1

    Last winter I hit the same wall on my own solo build — a lightweight memo app for iPhone, a Captio replacement that emails notes in one tap. I tried to box it: Tuesdays and Thursdays no code, only outreach. It collapsed by week three because I'd open Xcode "for ten minutes" and lose the morning.

    What ended up working was tying marketing to a shipping rhythm — every TestFlight build forced one IH or Reddit post about the smallest visible change. Felt cheesy at first; it's the only reason I have 20-something testers now instead of zero. The "ship in 2-3 months" myth on this forum quietly stings — most honest solo builds I see inhabit your 6-9 range. How are you planning to protect marketing hours during Product Hunt week itself, when the temptation to fix one more bug is highest?

    1. 1

      The "TestFlight build = one IH/Reddit post" rhythm is a smart constraint. I've been doing something similar this week, every new directory submission or feature change becomes a short post. It's not glamorous but it's the only way I keep both threads moving.

      For PH week itself, honest answer: I'm not treating it as a viral event. No followers, no preheated waitlist, so it's mostly for the permanent entity signal (PH page + DA-91 backlink) rather than day-one traffic. That actually makes "protecting marketing hours" easier, because there's no big push to defend. The temptation to fix bugs is real, but the launch will not be saved or ruined by a bug fix on launch day. The launch happens regardless.

      20+ TestFlight testers solo is genuinely good. Most builds at that stage have three friends and silence.

  50. 1

    I think a lot of people underestimate how messy the journey can get before something actually ships.
    Curious — looking back, is there anything you would simplify or do differently from the start?

    1. 1

      One thing: I would have paid for proper AI tools from day one instead of trying to do everything by hand. I burned months on free tiers and tools that almost worked. The cost of good tools is small compared to the cost of your own time when you're learning the stack while building it.

      1. 1

        This hit hard — especially the part about “free tools” costing months.

        I’ve seen the same pattern while working with early-stage founders: the biggest bottleneck isn’t usually skill, it’s friction from patchwork tools and constant rewrites.

        What you’ve done here is honestly impressive — shipping despite all that noise is the real win.

        If you ever feel like improving the UX or simplifying the flow (especially for non-technical users), that’s something I spend a lot of time on. Happy to share a few ideas if helpful.

        Either way, respect for sticking through 9 months — most people quit way earlier.

        1. 1

          Thank you. UX is on my radar for the next quarter, once I have enough user feedback to know what actually needs simplifying versus what just feels rough to me. Appreciate the offer.

  51. 1

    This is extremely relatable as a solo builder. The “I rewrote everything 3 times before first Stripe payment” part hits hard.

    Also interesting to see how AI changed your development speed — feels like that’s becoming a real shift in how solo devs build now.

    1. 1

      Glad it lands. The rewrites are what learning the stack in real time actually looks like, most posts hide that part.
      On the AI shift, two years ago, building something like this would have meant hiring a developer, a designer to port everything into the CMS, a copywriter, someone to set up the infrastructure, maybe a QA tester. Probably no PM, but easily €8-10k just to get to launch. And then you still need to put real money into marketing, and keep paying to maintain it. That math does not work for most solo people with ideas. You burn through savings before you even know if anyone wants what you built.
      AI changed that for people like me, folks with domain knowledge and ideas but no realistic way to ship them. The barrier moved from money and skill to patience.

  52. 1

    9 months is not slow — it's honest. Most "shipped in 6 weeks" posts skip the 3 versions they threw away first.

    The no-code -> proper backend path makes sense. You outgrow the tools when you finally understand the problem well enough to build it right.

    1. 1

      The throw-away versions are the invisible work. I guess, you only understand what to build after the third rewrite.

      1. 2

        Exactly this. You don't understand the problem until you've built the wrong solution twice.

  53. 1

    I started piecing together ideas around last October, then went heads-down on solo development from January, and finished a few days ago. Reading your post, I felt a lot of overlap with my own experience.

    I also started knowing almost nothing about coding. Used Cursor at first, then switched to Claude midway through the build. I sank around $200/month on Cursor for a while and still kick myself for not switching to Claude from the start.
    I spent months heads-down on just the build, and I'm now in the stage where I've completed it and switched fully to marketing. Doing all of it alone really makes simultaneous multitasking impossible.

    Wanting feedback or validation from other founders is completely natural, and IH or Reddit definitely help. But for the dozens of decisions a founder makes every day, researching threads one by one and reading comments isn't realistic or efficient. Honestly, that's the gap I built around. Feels like a fit for what you described. Let me know if you want a look.

    1. 1

      The ChatGPT-to-Claude switch resonates, I kicked myself over the same realization. Glad you got through the build phase.
      Drop a link to your tool here if you want, others reading might find it useful. Curious what angle you took on the founder-decision problem.

      1. 1

        Appreciate that. New account here so IH won't let me post links yet, but the product is called TRIM and the product page is on my profile.

        In short, we gather aggregated input from other founders who've already made the same kind of call, structured so you can read the consensus in minutes instead of researching threads one by one. There's also a private layer for organizing and tracking your own pending decisions in a structured way, so you can actually close them on time instead of letting them pile up.

        Running a waitlist now (launching June 2) with founding member perks (Pro free at varying tiers). If you drop your email in before launch, you're in that bracket automatically.

        1. 1

          Got it. Interesting angle, most tools try to replace the research, you're compressing it. Good luck with the June 2 launch!

  54. 1

    This is way more honest than most “I built a SaaS in 2 months” stories.

    The part people always skip: the rebuilding phase.

    3 stack rewrites in 9 months isn’t a failure — it’s literally what happens when you’re:

    learning backend + auth + infra from scratch
    validating product direction at the same time
    and trying to keep costs alive long enough to survive

    What actually matters here is this:
    👉 you didn’t stop
    👉 you simplified the stack
    👉 you reduced costs from $200 → $40/month
    👉 and you got your first Stripe payment

    That’s the real milestone, not the timeline.

    Also, the shift from no-code tools → Claude-assisted custom backend is a big inflection point. That’s usually where a project stops being “a prototype” and becomes “a real system.”

    Most people never get past that middle stage where everything is messy and expensive.

    Respect for shipping this solo — especially in a space that’s evolving as fast as SEO → AI search.

    Curious: what ended up being the biggest time sink for you — auth, backend logic, or integrations like Stripe/webhooks?

    1. 1

      Thanks, this means a lot. I've found a warm community here and people who actually get it.

      The "rebuilding phase" framing especially, that part is invisible from the outside and it's the part that nearly broke me a few times.

      Honestly, the hardest parts were: figuring out how to connect webhooks to Typebot, then later the backend to the database and Google Docs (I originally planned to export results as Google Docs, but ended up moving to PDF). And setting up payments with the Make + Stripe + database chain.
      I also changed the pricing model partway through. Started with monthly subscriptions, then realized that wasn't right for the small businesses without budget I was building for, so I rebuilt everything around pay-as-you-go.

  55. 1

    This felt very real to read.

    The part about rebuilding the stack multiple times and learning backend/webhooks/database concepts while actively building resonated a lot with me. I’m also building solo right now, and I think people massively underestimate how mentally difficult the “unfinished middle” phase is — where you’ve spent months building but still don’t have clear validation yet.

    Getting the first Stripe payment after all that probably felt incredible.

    Also agree on the AI point. Tools like Claude and ChatGPT have genuinely lowered the barrier for technical execution, but they still don’t replace persistence, product judgment, or actually sticking with the problem long enough to ship.

    Really respect the transparency in this post.

    1. 1

      Thanks for this. I feel your pain too, when you're the coder, the designer, the tester, the marketer, the writer, and the support person all at once. There's no one to hand anything off to, and every bug, illustration, or typo is yours to fix at midnight.

      The "unfinished middle" is exactly the part nobody warns you about. You can ship the start and celebrate the end, but the months in between are mostly invisible.
      Good luck with yours, drop a link when you ship.

  56. 1

    Congrats on shipping, Galyna! 9 months as a solo founder is incredibly honest work, especially doing stack rewrites along the way. Shifting from Memberstack to Supabase Auth to save on monthly runway is a massive win that most founders overlook early on.

    I’m currently building Velaris, which is a curated marketplace specifically for Micro Tools, Dev Tools, and Datasets. We launched it because we noticed so many independent builders waste months trying to figure out distribution and marketing after spending a year building their tools.

    On balancing dev vs marketing: Time-boxing works wonders. We spend one sprint purely focused on code/design, and the next sprint strictly doing SEO optimization and community outreach.

    Your AI citation readiness module sounds highly differentiated—would love to see how you structure your data filters!

    1. 1

      Thanks, Velaris sounds like exactly the gap most solo builders hit, distribution is where projects quietly die after launch.
      The sprint approach you described is what I'm moving toward too. Splitting daily was costing me more than I realized.

      On the data filters, the structure is still evolving. Right now it's per-page scoring against benchmarks (schema, original data, passage extractability, freshness, author signals), with engine-specific weighting since each AI engine rewards different things. The weighting will sharpen as more sites use it.

      Going to follow Velaris and check it out, would love to see how you've structured the marketplace.

  57. 1

    This is a strong founder story, but the real product angle is sharper than “SEO tool.” IvaBot is really sitting in the new AI visibility layer: helping small businesses understand whether ChatGPT, Perplexity, Claude, and Google AI can actually cite them.

    That matters because traditional SEO tools still talk in rankings, keywords, and audits, while the buyer pain is shifting toward “will AI engines understand and reference my site?” That is a cleaner category than broad technical audit plus content generation.

    The naming layer is where I’d be careful. IvaBot.xyz makes the product feel like a small chatbot experiment, even though the actual product is more serious: AI citation readiness, content coverage, and technical visibility. If this grows into a broader AI search intelligence platform, Beryxa .com would carry more trust and SaaS weight than a bot-style .xyz name.

    1. 1

      Thanks for the feedback. To answer the naming question, the original idea was actually a chatbot, so the name came from there. And as I mentioned, budget was a constraint, good .com domains are not cheap. The .xyz was a practical choice at the time.
      I get what you're saying about brand perception, and a future move to a different domain is not off the table. But for now I think if the tool is genuinely good, the audience will find it regardless of the TLD. We'll see how it plays out.

      1. 1

        That makes sense. If the original wedge was a chatbot, IvaBot was a logical starting point.

        The part I’d be careful with is assuming the audience will find it regardless of the TLD. That can be true once trust is already established, but early on the name and domain are part of the trust signal.

        Especially in your category, small businesses are already skeptical of SEO tools, AI tools, audits, and “visibility” promises. Before they test the product, they’re judging whether it feels credible enough to try.

        So the risk is not just .xyz versus .com. It’s that IvaBot still frames the product as a bot, while the stronger direction is AI citation readiness and search intelligence.

        I also agree that many good .coms are expensive, but not every strong brandable .com has to be impossible for an early founder. Sometimes if the fit is right, there are founder-friendly ways to make a cleaner name work before the product gets too attached to the current one.

        If this stays a lightweight chatbot-style tool, IvaBot.xyz is fine. But if the goal is a serious AI visibility platform, I’d pressure-test the broader brand before too much content, user memory, and search presence builds around the old chatbot frame.

        Beryxa .com fits that broader SaaS direction better because it does not lock you into “bot” or “SEO tool.” It gives the product more room to become a real AI visibility layer.

        1. 1

          Appreciate the deeper take. I hear the brand-trust argument and it's valid in principle.
          For now, IvaBot stays. Three reasons: the product is live and indexed, the rebrand cost is real (months of entity work to redo), and "small businesses are skeptical" cuts both ways, a flashier name does not solve trust, the product does. Trust gets built by what the tool delivers, not what TLD it sits on.
          If the product outgrows the name in two years, that is a problem I will gladly have.

  58. 1

    This comment was deleted 6 days ago.

Trending on Indie Hackers
30 days ago I posted here with $0 revenue. Here's what actually happened next. User Avatar 138 comments I used $30,983 of AI tokens last month in Claude code on $200/mo plan User Avatar 90 comments my reddit post got 600K+ views. here's exactly what i did User Avatar 54 comments How to spot high-intent customers in 5 minutes, for free. User Avatar 43 comments I Built a Habit Tracker SaaS Alone in 6 Weeks (No CS Degree, No Team). Here's Exactly How User Avatar 37 comments I turned someone’s tweet into an app idea and it has made ~$3000 so far in 4 months. User Avatar 37 comments