r/TheFounders

Building in public means sharing the real stuff so here it is.

For the first several months of my SaaS organic SEO felt like a tax I was paying on my time without getting much back. Content was going out, traffic was trickling in, revenue from organic was negligible. I kept hearing that SEO was a long game and I kept telling myself that patience was the issue.

Patience wasn't the issue. The system was broken in three specific places and I just hadn't found them yet.

The first broken place was content format. I was writing for Google in the way guides from five years ago told you to. Long posts, keyword frequency, structure designed for crawlers. That content ranked for things occasionally and converted rarely because it wasn't actually a great reading experience. Nobody stays on a page that feels like it was written by someone following a checklist. The format I switched to through this SEO tool was simpler and better. One question per article, direct answer first, plain clear language throughout. Readers stay because they get value immediately. And this format is exactly what AI tools like ChatGPT and Perplexity look for when generating answers. My content started getting cited in AI responses for relevant queries and that traffic converts better than almost anything else because the person already has context before they land on the page.

The second broken place was indexing. I was naive about this for longer than I want to admit. Publishing content does not mean Google has seen it. For a site without massive authority Google crawls when it wants to and that can mean weeks between visits. This indexing tool automated the process of telling Google and Bing about every new page the moment it went live. Submissions go directly to Google's Indexing API and Bing's IndexNow automatically. The backlog of unindexed content cleared, new content started ranking fast, and the compound effect of that over a few months of consistent publishing was significant.

The third broken place was measurement. I was tracking traffic and making content decisions based on what got visits. That is a reasonable starting point but it is not the right metric to optimize for long term. This analytics tool connected my content performance directly to my Stripe data so I could see which pages were driving paid conversions not just sessions. That visibility changed everything. The content that looked good in analytics and the content that actually made money were different sets of pages and I had been investing effort in the wrong one.

Three broken places, all fixed. Organic is now the channel I'm most confident in.

I developed Weather World because I wanted a simpler, more helpful way to stay ahead of the forecast. I truly believe that a weather app should be a tool that makes your life easier, not a source of distraction with ads and confusing menus.

How it helps you: The core of the app is all about visual clarity. I’ve focused on creating intuitive graphs that let you see temperature shifts and precipitation trends at a single glance. Instead of reading through long lists of numbers, you can visualize exactly how your day will unfold. It’s minimalist, lightweight, and built for speed—perfect for anyone who values a clean Android experience.

I’d love your support! Please give it a try and see if it helps your daily routine. If you find it useful, please recommend it to your friends! As a solo developer, your support and word-of-mouth are what help me improve and grow.

In compliance with the community rules, I’ve shared the link via IndieAppCircle. Check it out there and let me know what you think!

Find it here: https://play.google.com/store/apps/details?id=com.danie.pocasisveta

PreSeedVCList covers 390 venture capital firms actively writing pre-seed checks, with data on firm websites, investment stages, sectors, office locations, and portfolio links, structured from recent funding activity and updated monthly at https://preseedvclist.com.

Most people don't fail because they lack effort — they fail because they can't see the full journey before committing. They Google, get 47 conflicting answers, and either give up or start the wrong thing.

Built PathFinder to fix this. Type your goal, it generates 3 structured routes with real costs, timelines, risks and every step — before you take one.

26 pre-orders in 2 weeks, zero marketing. Only 4 founding member spots left — first month free.

https://pathfinderofficial.vercel.app/

Hey everyone, my quiz app about DRC just reached 100 download and I wanna you to try it and give me your honest feedback

Here's the link

https://play.google.com/store/apps/details?id=com.mindsetdev.congoquiz

I’ve seen a lot of discussion about local TTS—primarily for privacy and cost savings. With the advancements in open-source models, offline TTS with excellent sound quality is a reality.

I decided to build a native Apple Silicon audiobook generator that can turn text into a 10-hour audio file in a single run. Turning an open-source script into a production-ready Swift app took a lot of effort, and I’d love to share my experience, the technical hurdles I hit, and also get some feedback from this community.

Here are my main takeaways from building it:

1. Choosing the Model (Kokoro TTS)

I chose Kokoro TTS (82M parameters) because of its sound quality in resource-constrained environments. While there are highly expressive models out there, they generally require GPUs. They can run on a CPU, but they are painfully slow. Apple Silicon GPUs are not as powerful as NVIDIA GPUs. I feel their capability is somewhere between a standard CPU and an NVIDIA GPU.

2. Resource Management: Why I used ONNX instead of MLX

Even a lightweight model like Kokoro demands serious resources. After generating audio for 10-30 minutes, a MacBook’s fans will start to kick in.

I initially looked at MLX (Apple's latest ML framework), but I found it uses memory very aggressively. My goal was to make audiobook generation a background job—meaning you can do your regular work on your Mac while a 10-hour book generates in the background.

Instead of MLX, I opted for ONNX Runtime targeting Apple Silicon. I specifically limited the CPU and threading resources so the audio generates at a 7x to 12x real-time ratio while it only uses a small portion of the total CPU and memory. If you are busy using your Mac for heavy tasks, the background audio generation simply slows down to get out of your way.

3. Robustness for Long-Running Tasks

Generating 10 hours of audio still takes about 1 to 2 hours of compute time. I needed a robust system to generate audio for such a long time. I built a queuing and checkpoint system that allows for pausing and resuming. You can literally close your laptop halfway through generating a book, open it the next day, and it will resume flawlessly.

4. Quality Control & The "AAA" Problem

Open-source libraries are great help. But when you sit down and actually listen to the generated long-form audio, you notice very troublesome mistakes in pronunciation. I had to fix lots of bugs to make the code production-ready.

A major issue with TTS engines is acronyms. For example, the engine will read "AAA" as "Ay-Ay-Ay", which sounds ridiculous in an audiobook. To fix this, I built a custom pronunciation editor. You can tell the engine to read "AAA" as "Triple A". I also implemented multi-speaker support and filters for unwanted text.

5. The Swift Struggle

I chose to write all the code in native Swift for performance, but the Swift ecosystem lacks the ML libraries that Python has. Python’s massive library ecosystem gives cloud TTS an edge. To get it working locally and natively, I actually manually converted some Python libraries into Swift.

6. Why not an iOS App? (The Thermal Bottleneck)

My friends asked why I didn't build this for the iPhone. I actually started there, but I hit thermal and battery drain bottlenecks.

iPhones have three compute units: the CPU, GPU, and the Neural Engine (NPU). The Neural Engine runs "cold" and is incredibly battery efficient—I heard Apple's built-in iOS voices run exclusively on the NPU. But the NPU supports limited ML operations, and my guess is that this is why the built-in voice is a bit robotic.

Getting a model like Kokoro to run entirely on the NPU is probably not doable. Running Kokoro with MLX on iOS is possible. But I found MLX also uses the CPU. Running Kokoro in MLX turned out to be a mix of GPU and CPU. Mixing CPU/GPU computation seems to produce poorer performance.

Running it purely on the CPU generated heat and drained the battery. It is not a fit for a 10-hour generation task. This seems to match my previous experience on edge devices. The battery is the problem.

If we can push a lightweight model into the NPU, unlimited offline TTS might work on the iPhone.

If anyone wants to poke around and try it, the app is called Aura Reader. I put it on the Mac App Store and at www.gushilabs.com. There’s a free version available, so it’s easy to experiment with. This is my first time releasing an app, so I’m especially interested in whether this is actually useful in real workflows. I would love any honest feedback.

Hey! Just launched Tye on the App Store and looking for honest feedback from early users.

What it does: Tye helps you remember the small things about people in your life — a friend's favorite coffee, your partner's upcoming work milestone, your dad's food allergies. You log memories, save notes to each person's vault, and the app nudges you when someone might need attention based on how long it's been.

It's not a CRM. It's not a social network. It's just a quiet place to be a more thoughtful person.

Platform: iOS
Price: Free 30-day trial → $4 lifetime (launch week only, normally $8)
App Store: https://apps.apple.com/app/tye/id6762053406

Would love any feedback — UX, onboarding, anything feels off. Thanks!

It's a platform designed to help people find the perfect gifts using AI-powered recommendations. You describe who you're shopping for (like "tech-savvy dad" or "creative teenager"), and the AI suggests personalized gift ideas.

https://prezntai.lovable.app

what do you think?

I want to write this properly because I consumed a lot of founder content before building my SaaS and most of it either skipped the hard parts or made success sound simpler than it was. This is the version I wish I had read.

For the first year of building I was doing organic the way everyone told me to. Consistent publishing, keyword research every week, optimising titles and meta descriptions, building internal links. The checklist was complete. The results were underwhelming in a way I could not explain because I was doing everything right according to everything I had read.

The problem was not effort. The problem was that I was optimising for the wrong things in the wrong order and had no feedback loop that connected any of it to actual revenue.

The content format problem nobody talks about clearly enough

Most SEO content is written for search engine crawlers. Not for people. There is a real difference and you can feel it when you read it. Long introductions that delay the actual point. Keyword phrases inserted in ways that feel slightly unnatural. Answers buried in paragraph four of a post that could have delivered them in the first two sentences.

That content ranks occasionally and converts poorly because nobody enjoys reading it. People land on it, get what they need if they can find it, and leave. Session time stays low, bounce rate stays high, and the conversion rate reflects the reality that the content was not built to serve the reader.

The format shift that changed everything for me was simple in principle and harder in execution. Every article has one job. Answer one specific question that a real buyer is asking. Answer it in the first paragraph. Not after the introduction, not midway through, the first paragraph. Everything else in the article supports and expands that answer without padding or filler.

This SEO tool helped me build and publish this kind of content at volume while keeping that quality standard consistent. The research pipeline identifies the specific questions my target users are asking at the decision stage of their journey and the publishing workflow enforces the format so quality does not slip when I am producing quickly.

The change in how content performed was immediate in two ways. First, session time went up because readers got value instantly and stayed to read more. Second, and this one surprised me, content started showing up in ChatGPT and Perplexity responses for relevant queries. AI tools are doing exactly what a reader does when they scan an article. They look for the content that answers the question most directly and clearly. The format that serves human readers is the format that gets cited in AI-generated answers. One piece of content doing both jobs at the same time is a genuine efficiency advantage.

The visitors who arrive through AI citations are the most purchase-ready traffic I get. They have already had a conversation with an AI about their problem. They have context, they understand the category, and they are evaluating specific solutions. That intent profile converts at a rate that broad organic traffic cannot match.

The indexing problem that was quietly killing months of work

This is the one that embarrassed me most when I figured it out.

I had been publishing consistently for months and wondering why organic was so slow to build. Went into Google Search Console properly one afternoon to diagnose something unrelated and found a significant backlog of articles that were not in Google's index at all. Some had been published for six weeks.

Google crawls on its own schedule. For smaller sites without massive domain authority that schedule is slow and unpredictable. Content you publish today might not be seen by Google for three to four weeks. During that entire window it cannot rank, cannot be found, cannot be cited by AI tools, cannot convert anyone. It simply does not exist as far as search is concerned.

The fix is straightforward but it has to be a habit not an afterthought. Every time you publish something you need to actively request indexing through Google Search Console and submit to Bing via IndexNow. Two minutes per article that change the timeline from weeks to hours.

IndexerHub automated this entirely for me. Every new page gets submitted directly to Google's Indexing API and Bing's IndexNow the moment it goes live without any manual steps. The compounding effect of six months of content all indexing the same day it was published versus content trickling into the index weeks late is significant. Fast indexing means content starts working immediately. Delayed indexing means you are always running behind your own publishing schedule.

The measurement problem that made everything invisible

For most of the first year I was tracking traffic. Sessions, pageviews, bounce rate, time on site. These metrics feel meaningful because they are easy to understand and they trend upward over time if you are publishing consistently. The problem is they are completely disconnected from whether your business is actually growing.

I had months of traffic growth that I was mildly proud of that contributed almost nothing to revenue. Some of my highest traffic pages were bringing in visitors who would never buy. A small set of pages with modest traffic were quietly responsible for most of my conversions. I had no idea which was which because I was not measuring the right thing.

Faurya changed this by connecting my content directly to my Stripe data. It is completely free for startups, no card required. Revenue per visitor, conversion rate, and page level attribution all in one place. Once I could see which pages were actually driving paid users the content calendar completely changed. I stopped building around traffic potential and started building around what the revenue data told me was converting.

The difference between optimising for traffic and optimising for revenue is not subtle. They produce completely different content strategies and completely different results.

The sequencing lesson that took too long to learn

The reason the first year was so frustrating is that I was doing all of these things but not in the right order and not with feedback loops that connected them to each other.

Content without the right format pulls in the wrong audience. The wrong audience does not convert regardless of how much of it you get. Fast indexing of content with the wrong format just means bad content gets found faster. Revenue attribution without the right content format shows you a conversion rate that looks low and does not tell you why.

When all three work together the picture is completely different. Content built for decision-stage intent and AI citations pulls in qualified visitors. Fast indexing means those visitors find the content when the intent is active. Revenue attribution shows you which content is working and exactly where to invest the next month of effort.

That compounding is what organic growth actually looks like when it is built correctly. It does not feel dramatic month to month. It just keeps building in a direction that makes sense.