DEV Community: Ju

Running Text-to-Speech Fully in the Browser with PocketTTS

Ju — Wed, 28 Jan 2026 09:21:08 +0000

Most text-to-speech (TTS) tools still work the same way they did years ago:
send text to a server → wait → receive an audio file.

At QuickEditVideo, we took a very different approach.

Our TTS tool runs entirely in the browser — no servers, no uploads, no API keys — using a compact neural model powered by PocketTTS and jax-js.

In this post, I’ll break down:

What PocketTTS is and why it’s a great fit for browsers
How in-browser inference actually works
Why client-side AI is a big deal for privacy, cost, and UX
How modern JS + WASM tooling makes this possible today

👉 Live demo: https://quickeditvideo.com/tts/

What Is PocketTTS?

PocketTTS is a lightweight neural text-to-speech system designed for edge devices and CPU-only inference.

Its design goals are very different from large cloud TTS models:

Small model size (around 300MB)
Fast CPU inference
Deterministic output
Low memory pressure
Easy embedding

That makes it ideal for environments like:

Browsers
Desktop apps
Offline tools
Mobile devices

Instead of relying on massive autoregressive architectures, PocketTTS uses a streamlined acoustic model + vocoder pipeline that trades a bit of expressiveness for speed, portability, and predictability — a trade-off that makes sense for real-time tools.

PocketTTS Inference Pipeline (High Level)

Here’s what happens when you click “Generate” in the browser:

Text input
  ↓
Text normalization
  ↓
Phoneme / token encoding
  ↓
Acoustic model (phonemes → features)
  ↓
Vocoder (features → waveform)
  ↓
WAV / audio buffer

Every one of these steps runs locally — nothing leaves your device.

No servers.
No background jobs.
No queueing.

Why Run TTS in the Browser?

Most “privacy-friendly” AI tools still send your data somewhere.

With in-browser TTS:

Text never leaves your machine
Audio is generated locally
Nothing is logged, stored, or transmitted

This isn’t a policy — it’s a technical guarantee.

ALso, Zero Latency, Zero Rate Limits! The speed you get depends only on the user’s device — not your backend capacity.

Last but not least, From a builder’s perspective, this is huge.

Running TTS in the browser means:

no GPU servers
no inference queues
no autoscaling
no “free tier abuse” issues

Your infrastructure cost is zero. Yay!

How PocketTTS Runs in the Browser

Browsers today are much more capable than most people realize. Yes, I'm talking about WebGPU! :)

Here’s the stack that makes this work.

🧠 WebAssembly (WASM)

PocketTTS is compiled to WebAssembly, allowing near-native performance inside the browser.

Why WASM matters:

Fast numeric computation
Predictable memory layout
SIMD support (where available)
No JS GC interference during inference

This makes CPU-based neural inference viable — even on mid-range laptops.

      // Prepare text for TTS
      const [preparedText, framesAfterEos] = prepareTextPrompt(textToGenerate);
      const tokens = tokenizerRef.current.encode(preparedText);

      // Load voice embedding
      const voiceUrl = POCKET_TTS_VOICES[voiceToUse].url;
      const audioPromptData = safetensors.parse(await cachedFetch(voiceUrl));
      const audioPrompt = audioPromptData.tensors.audio_prompt;

      const voiceEmbed = np
        .array(audioPrompt.data as Float32Array<ArrayBuffer>, {
          shape: audioPrompt.shape,
          dtype: np.float32,
        })
        .slice(0)
        .astype(np.float16);

      // Create text embeddings
      const tokensAr = np.array(tokens, { dtype: np.uint32 });
      let embeds = modelRef.current.flowLM.conditionerEmbed.ref.slice(tokensAr);
      embeds = np.concatenate([voiceEmbed, embeds]);

      // Create streaming player and generate audio
      const player = createStreamingPlayer();

      try {
        await playTTS(player, tree.ref(modelRef.current), embeds, {
          framesAfterEos,
          seed: null,
          temperature: 0.7,
          lsdDecodeSteps: 1,
        });

        // Get the generated audio as WAV blob
        const audioBlob = player.toWav();
        const audioUrl = URL.createObjectURL(audioBlob);

        // Update the audio item with the generated URL
        setGeneratedAudios(prev =>
          prev.map(audio =>
            audio.id === audioId
              ? { ...audio, audioUrl, isGenerating: false }
              : audio
          )
        );
        if (autoPlayGeneratedAudio) {
          setLastAutoPlayedAudioId(audioId);
        }

      } finally {
        await player.close();
      }

export async function playTTS(
  player: AudioPlayer,
  model: PocketTTS,
  embeds: np.Array,
  {
    framesAfterEos = 0,
    seed = null,
    lsdDecodeSteps = 1,
    temperature = 0.7,
    noiseClamp = null,
    playChunk = false,
  }: Partial<PlayTTSOptions> = {},
): Promise<void> {
  let sequence = model.flowLM.bosEmb.ref.reshape([1, -1]); // [1, 32]
  let audioPromise: Promise<void> = Promise.resolve();

  if (seed === null) seed = Math.floor(Math.random() * 2 ** 32);
  let key = random.key(seed);

  try {
    let flowLMState = createFlowLMState(model.flowLM);
    let mimiState = createMimiDecodeState(model.mimi);
    let eosStep: number | null = null;

    console.log("Starting TTS generation...");
    let lastTimestamp = performance.now();

    for (let step = 0; step < 1000; step++) {
      let stepKey: np.Array;
      [key, stepKey] = random.split(key);
      const {
        latent,
        isEos,
        state: newFlowLMState,
      } = runFlowLMStep(
        tree.ref(model.flowLM),
        flowLMState,
        stepKey,
        step === 0 ? sequence.ref : sequence.ref.slice([-1]),
        step === 0 ? embeds.ref : null,
        flowLMState.kvCacheLen, // same as offset
        lsdDecodeSteps,
        temperature,
        noiseClamp,
      );
      flowLMState = newFlowLMState;

      const isEosData = await isEos.data();
      if (isEosData[0] && eosStep === null) {
        console.log(`🛑 EOS at step ${step}!`);
        eosStep = step;
      }
      if (eosStep !== null && step >= eosStep + framesAfterEos) {
        console.log(
          `Generation ended at step ${step}, ${framesAfterEos} frames after EOS.`,
        );
        latent.dispose();
        break;
      }

      sequence = np.concatenate([sequence, latent]);

      const timestamp = performance.now();
      console.log(
        `Generated step ${step} in ${(timestamp - lastTimestamp).toFixed(1)} ms`,
      );
      lastTimestamp = timestamp;

      let mimiInput = sequence.ref.slice([-1]);
      mimiInput = mimiInput
        .mul(model.flowLM.embStd.ref)
        .add(model.flowLM.embMean.ref);

      const [audio, newMimiState] = runMimiDecode(
        tree.ref(model.mimi),
        mimiState,
        mimiInput,
        step,
      );
      mimiState = newMimiState;

      const audioPcm = (await np
        .clip(audio.slice(0), -1, 1)
        .astype(np.float32)
        .data()) as Float32Array;
      if (audioPcm.length !== 1920) {
        throw new Error(
          `expected 1920 audio samples, got ${audioPcm.length}`,
        );
      }

      player.recordChunk(audioPcm);
      if (playChunk) {
        const lastAudioPromise = audioPromise;
        audioPromise = (async () => {
          await lastAudioPromise;
          await player.playChunk(audioPcm);
        })();
      }
    }
  } finally {
    sequence.dispose();
    tree.dispose([model, embeds]);
    await audioPromise;
  }

🧮 Typed Arrays + Audio Buffers

Instead of shuffling data through JSON or base64 blobs, the pipeline uses:

Float32Array / Int16Array for tensors
Direct audio buffer synthesis
Minimal copying between stages

That keeps memory overhead low and performance stable.

📦 Model Caching (IndexedDB)

The model is downloaded once and cached locally using IndexedDB.

On repeat visits:

No re-download
Near-instant startup
Offline-friendly behavior

This is critical for UX when models are 300 MB in size.

// Initialize WebGPU and load model
  useEffect(() => {
    let isMounted = true;

    async function initializeModel() {
      let weightsAreCached = false;

      try {
        setLoadingProgress('Initializing WebGPU...');
        const devices = await init();

        if (!devices.includes('webgpu')) {
          throw new Error('WebGPU is not supported on this device. Please use a browser with WebGPU support (Chrome 113+, Edge 113+).');
        }

        defaultDevice('webgpu');

        if (!isMounted) return;

        try {
          const info = await opfs.info(MODEL_WEIGHTS_URL);
          weightsAreCached = info !== null;
        } catch (cacheInfoError) {
          console.warn('Failed to read cached model metadata:', cacheInfoError);
        }

        if (!isMounted) return;

        if (weightsAreCached) {
          setLoadingProgress('Loading cached model weights...');
          setIsWeightsDownloadInProgress(false);
          setWeightsDownloadPercent(null);
        } else {
          setLoadingProgress('Downloading model weights (300MB)...');
          setIsWeightsDownloadInProgress(true);
          setWeightsDownloadPercent(0);
        }

        const weightsData = await cachedFetch(
          MODEL_WEIGHTS_URL,
          undefined,
          (progress) => {
            if (weightsAreCached || !isMounted) return;
            const total = progress.totalBytes ?? ESTIMATED_MODEL_WEIGHTS_SIZE;
            const percent = total > 0 ? Math.min(100, Math.round((progress.loadedBytes / total) * 100)) : 0;
            setWeightsDownloadPercent(percent);
          }
        );
        weightsRef.current = safetensors.parse(weightsData);

        if (!isMounted) return;

        if (!weightsAreCached) {
          setWeightsDownloadPercent(100);
          setIsWeightsDownloadInProgress(false);
        }

        setLoadingProgress('Loading model...');
        modelRef.current = fromSafetensors(weightsRef.current);

        if (!isMounted) return;

        // Load tokenizer
        setLoadingProgress('Loading tokenizer...');
        tokenizerRef.current = await tokenizers.loadSentencePiece(TOKENIZER_URL);

        if (!isMounted) return;

        setIsModelLoaded(true);
        setIsModelLoading(false);
        setLoadingProgress('');
        console.log('Pocket TTS model loaded successfully');

      } catch (err) {
        console.error('Failed to initialize Pocket TTS:', err);
        if (isMounted) {
          if (!weightsAreCached) {
            setIsWeightsDownloadInProgress(false);
            setWeightsDownloadPercent(null);
          }
          setError(err instanceof Error ? err.message : 'Failed to load TTS model');
          setIsModelLoading(false);
        }
      }
    }

    initializeModel();

    return () => {
      isMounted = false;
    };
  }, []);

🧪 Why This Approach Actually Works Now

A few years ago, this would’ve been unrealistic.

Today, we benefit from:

Faster JS engines
Mature WASM runtimes
Better browser audio APIs
Smarter lightweight models like PocketTTS

We’re not brute-forcing AI into the browser — we’re choosing models that fit the medium.

That mindset shift is the key.

🚀 Try It Yourself

If you’re curious what modern browser-based TTS feels like:

👉 https://quickeditvideo.com/tts/

No login
No limits
Fully client-side
Instant playback

🧠 Final Thought

AI doesn’t have to live on massive servers.

With the right models — like PocketTTS — and modern web runtimes, the browser becomes a serious inference platform.

This isn’t just about TTS.

It’s a glimpse of where web-native AI is heading.

If you’re building tools for creators, educators, or everyday users — it’s worth paying attention.

I Wanted a Video Editor With No Paywalls, No Accounts, and No Cloud — So I Built One

Ju — Tue, 06 Jan 2026 07:52:25 +0000

I don’t like paywalls.

I don’t like subscriptions.

I don’t like signups.

I really don’t like uploading my assets to someone else’s cloud just to trim a video.

I just want to edit a video.

The same way I type text into a textarea.

Open → do the thing → export → done.

No account.

No “start free trial”.

No “your file is being uploaded…”.

So I built QuickEditVideo.

The original sin of modern video editors

Somewhere along the way, video editing became… heavy.

Canva: polished, powerful — but everything uploads. Your files live there, not with you.
CapCut: does everything, installs everything, ships everything. Bloated.
DaVinci Resolve: incredible tool — but slowly moving basic features behind gates.

All great products.

All solving problems I don’t have.

My problem is simple:

“I want to open a web page, edit a video, and export it.”

That’s it.

My rules (non-negotiable)

Before writing a single line of code, I wrote rules instead:

❌ No paywall blocking editing
❌ No subscriptions
❌ No forced signups
❌ No cloud uploads
❌ No local app installs

✅ Everything runs inside the browser

✅ Your files stay on your machine

✅ Editing is always free

✅ Export in any resolution for free

✅ Anything can be done in browser for free*

Editing should be as free as typing text.

You don’t pay to open a textarea.

You don’t “subscribe” to write a paragraph.

Why should trimming, or overlaying a video feel harder than writing a tweet?

So I made the tool I wanted

Not the “best video editor”.

Not the “most features”.

Not an AI everything machine.

Just:

Load local media
Drag things around
Resize, trim, move on a timeline
Export

That’s it.

No magic.

No dark patterns.

No lock-in.

Is this a good business?

Honestly? I don’t know yet.

But I do know this:

People are tired of gates
People miss simple tools
People want ownership again

If this resonates with even a small group of creators, indie hackers, teachers, devs, or parents making quick videos — that’s enough.

I didn’t build this to win a category.

I built it because I was annoyed.

And sometimes, that’s the best reason to build anything.

If you’re curious, it’s live.

If you hate it, that’s fair.

If you wish more tools worked like this — then we think the same way.

Check it out: QuickEditVideo.

Why Consistent Practice Beats Perfect Strategy

Ju — Fri, 24 Oct 2025 09:06:52 +0000

We all love strategy.

Funnel diagrams. PLG loops. Growth hacks.

But after building Indie10k — my “growth gym” for indie devs — I realized something uncomfortable:

strategy doesn’t matter if you don’t show up every day.

The Myth of the Perfect Plan

When I started Indie10k, I thought success meant finding the right playbook.

I studied frameworks, copied funnels, and tweaked pricing models for weeks.

None of it moved the needle.

Why? Because growth doesn’t come from knowing the path — it comes from walking it.

The Power of Consistency

What actually worked was simple:

One rep. Every day.

A small action: write a post, fix an onboarding bug, or talk to one user.

Each rep gave me data.

The data gave me clarity.

And clarity made strategy obvious.

That’s when I learned:

Strategy is a compass.

Practice is the engine.

You can’t steer a car that isn’t moving.

For Indie Hackers, Momentum > Motivation

If you’re building your first (or fifth) SaaS, don’t chase perfect strategy.

Chase momentum.

Because momentum compounds.

One rep turns into a streak.

A streak turns into insight.

Insight turns into growth.

That’s how every “overnight success” actually happens — one boring, consistent day at a time.

💪 Rep Today

Do one rep — something small but repeatable.

Ship. Share. Learn. Repeat.

Your strategy will get sharper the longer you stay in motion.

Why I Test Demand Before I Build (and You Probably Should Too)

Ju — Fri, 24 Oct 2025 09:02:23 +0000

I’ve lost count of how many side projects I’ve built that never found users.

Beautiful landing pages. Clever names. Clean code.

But no demand.

Every indie hacker goes through that phase — building in excitement, then watching the numbers stay at zero.

These days, I do the opposite.

Before I build anything, I test if people actually want it.

That mindset led me to create JoinWaitlist.dev — a tiny tool that helps founders launch a waitlist page in minutes to validate their idea before writing a single line of code.

It’s basically a “fake door test” made simple:

Create a one-page landing.
Add a clear headline and

I’ve lost count of how many side projects I’ve built that never found users.

Beautiful landing pages. Clever names. Clean code.

But no demand.

Every indie hacker goes through that phase — building in excitement, then watching the numbers stay at zero.

These days, I do the opposite.

Before I build anything, I test if people actually want it.

That mindset led me to create JoinWaitlist.dev — a tiny tool that helps founders launch a waitlist page in minutes to validate their idea before writing a single line of code.

It’s basically a “fake door test” made simple:

Create a one-page landing.
Add a clear headline and signup form.
Share it in your communities.
See if anyone cares enough to join the waitlist.

If people sign up → you’ve got a real signal.

If not → you’ve saved yourself weeks or months of wasted effort.

What I Learned

Validation ≠ Perfection.

You don’t need fancy branding or pixel-perfect UI. A headline and a promise are enough to test interest.
Silence is data.

Zero sign-ups tells you something too — the idea, the audience, or the message isn’t resonating.
Momentum beats motivation.

Real feedback from even 3 sign-ups keeps you moving more than 30 days of overthinking.

Try It for Your Next Idea

Next time you get that “what if…” idea, don’t open VS Code.

Open JoinWaitlist.dev.

Make a page.

Share it.

Learn fast.

Because building what people want starts with knowing who wants it.

🧠 Discussion

Do you test ideas before building?

What’s your go-to validation method — waitlists, mock sales, or something else?

Momentum Beats Motivation

Ju — Thu, 23 Oct 2025 08:57:46 +0000

I used to wait for motivation. That spark, that burst of energy that made me want to ship something.

But here’s what I’ve learned building Indie10k: motivation is fickle. Momentum is the real compound interest.

When I ship one small rep — fix a bug, improve a headline, reply to one user — I feel a small win. That win stacks. Tomorrow’s rep gets easier. Soon, I’m not chasing motivation; I’m riding momentum.

The days I feel unmotivated? Those are actually the most important ones. Because when I ship anyway, I keep the streak alive. Momentum doesn’t care how I feel — it just wants motion.

Indie10k is built around that idea. You don’t need a big plan, a fancy dashboard, or a productivity ritual. You just need one rep a day. The rest compounds.

Rep

Ship one thing today — no matter how small. Momentum will take care of tomorrow.

Keep Going!

🧱 Progress Shared Compounds Faster Than Progress Hidden

Ju — Wed, 22 Oct 2025 19:18:15 +0000

We indie hackers love polishing.

We tweak buttons, fix margins, rewrite the copy.

All waiting for the “perfect” launch day.

But here’s the truth: nobody connects with perfection.

People connect with momentum.

Every time you share a screenshot, chart, or scrappy prototype, you’re sending one message:

“I’m building for real.”

That builds trust.

And trust compounds faster than polish ever will.

One rough screenshot does more for your credibility than a hundred “launch soon” tweets.

Because progress — even messy progress — is proof.

When you show the climb, people root for you.

When you hide it, they forget you exist.

Momentum is magnetic. It pulls in early adopters. It reminds you that you’re moving.

Every “shipped this today” post is a rep — and every rep builds trust.

💪 Rep of the Day

Take one screenshot of what you built today — UI, code, or chart —

and post it with one simple line:

“Shipped this today to make X easier.”

Let your momentum speak for itself. Keep Going at indie10k

💬 Your turn:

Do you share your in-progress builds, or wait until everything’s polished? Drop your latest screenshot in the comments — let’s cheer each other on.

I Feel Many SaaS Have “Bad Taste”

Ju — Mon, 13 Oct 2025 07:57:57 +0000

Linus Torvalds often gets mad at “bad taste” code —
lazy, inconsistent, or too clever for no reason.

He values code that’s blunt, explicit, and honest.
Readable over “smart.” Maintainable over elegant.

I think we’ve lost that kind of taste in product building.

Most SaaS today ships fast — but without vibe.
No rhythm. No restraint. Just endless feature drops.

“Vibe coding” used to mean care.
You built something that felt right.
Now it just means “ship something before Friday.”

AI writes, frameworks deploy, and 90% of what ships feels… soulless.
Everything works, but nothing feels alive.

That’s why I built Indie10k

It’s my attempt to bring taste back into building.

Not through rules or frameworks —
but through small, daily reps that remind you what matters:
clarity, intention, rhythm, momentum.

Indie10k gives you one growth task a day.
Tiny, human-paced, and thoughtful —
because good products are built with repetition, not rush.

We don’t need faster builders.
We need builders with better taste.

What do you think? Can a SaaS still have taste — or has “move fast” killed that part of the craft?

The TenK Manifesto — Why Indie Founders Need a Movement

Ju — Tue, 07 Oct 2025 08:38:04 +0000

🧭 The TenK Manifesto — Why Indie Founders Need a Movement, Not Another App

Every week, I see indie devs ask the same questions:

“How do I find my first users?”

“When should I start charging?”

“What should I build next?”

And every week, I see the same outcome:

They overthink. Overbuild. Burn out.

Then another side project joins the graveyard.

I’ve been there more times than I want to admit.

That’s why I created Indie10k — a place where indie founders can practice reaching $10k MRR through daily, small, repeatable reps.

But recently, I realized something deeper:

An app isn’t enough.

We don’t just need another tool.

We need a shared set of principles — the indie equivalent of the Agile Manifesto.

🧩 What Is the TenK Manifesto?

It’s a declaration for indie founders who believe success isn’t a lucky launch or viral tweet — it’s the compounding result of consistent reps.

We are uncovering better ways of reaching $10k MRR as indie founders by showing up daily, compounding small wins, and helping others do the same.

Through this work, we have come to value:

Consistent practice over perfect strategy

Small, shippable reps over grand unstarted plans

Momentum through streaks over bursts of unsustainable effort

Direct customer conversations over secondhand advice

Evidence from action over assumptions from theory

Sharing progress openly over building alone in silence

While there’s value in the items on the right, we value the items on the left more.

💡 Why It Matters

The indie world has become noisy.

Everyone talks about frameworks, funnels, hacks, and AI shortcuts.

But nobody’s teaching the fundamentals —

how to build momentum, how to stay consistent, how to learn from action instead of theory.

Just like Agile reshaped software development,

we need a new movement to reshape how indie founders build.

The TenK Manifesto is that foundation — a call to stop overthinking, start practicing, and measure success not by followers or features, but by the streaks of daily progress we show up for.

🚀 Join the Movement

I drafted this manifesto in Tongariro, New Zealand — in the rain, looking at snow and volcano peaks — and signed it as the first believer.

Now, I’m sharing it with the community that understands it best: devs who build things that matter.

✍️ Sign the Manifesto: https://indie10k.com/manifesto

👋 Author: Ju Lin, Founder of Indie10k

© 2025 — This declaration may be freely copied in full with this notice.

✍️ Drafting the TenK Manifesto

Ju — Sat, 04 Oct 2025 11:14:24 +0000

Most of us have read the Agile Manifesto — short, sharp, and surprisingly timeless. It gave developers something to rally behind that wasn’t a tool, a process, or a trend, but a set of values.

I’ve been building Indie10k, which is kind of like a “growth gym” for indie founders. The core idea is simple: daily reps compound into momentum. Not theory, not playbooks, not frameworks we abandon after two weeks. Just consistent practice.

That led me to ask: what if indie SaaS builders had their own manifesto?

So I drafted one.

The TenK Manifesto

We are uncovering better ways of reaching $10k MRR as indie founders

by showing up daily, compounding small wins, and helping others do the same.

Through this work we have come to value:

Consistent practice over perfect strategy
Small, shippable reps over grand unstarted plans
Momentum through streaks over bursts of unsustainable effort
Direct customer conversations over secondhand advice
Evidence from action over assumptions from theory
Sharing progress openly over building alone in silence

That is, while there is value in the items on the right,

we value the items on the left more.

How You Can Join

If you’d like to co-author, just leave a suggestion in the Google Doc. If it’s adopted, your name will be added to the Authors section.
If you’d like to sign it, you can add your name, email, and (optional) product link to be listed as a Signatory.

I don’t think this will solve everything. But I do think indie founders deserve something to point to and say, this is how we build.

👉 Would you sign the TenK Manifesto? indie10k.com/manifesto

Indie10k: Why I Built the “Arc” to Turn Goals Into Growth

Ju — Fri, 26 Sep 2025 10:15:56 +0000

Most side projects die the same way:

You set a big goal, jot down some tasks, and then… momentum fades.

I’ve been there more times than I can count (65 dead projects, to be exact). This time, I wanted a system that didn’t just track tasks — but kept me locked onto progress.

That’s where the Arc comes in.

What’s an Arc?

In Indie10k, an Arc is the container for your growth journey.

It connects:

A North Star Goal (something measurable, like reach 1k newsletter subs).
A metric + target value (your scoreboard).
A sequence of steps (the TenK 6 Methodology: List → Pick → Ship → Ask → Measure → Share).

Think of it as a structured habit-builder for indie growth. Instead of vague “do marketing” tasks, you’re running small experiments tied to your goal — and stacking evidence every step of the way.

Why It’s Different From a To-Do List

A checklist can make you feel productive while moving you nowhere.

An Arc is different:

It ties every action back to one guiding metric.
It creates natural accountability (you can’t “check off” growth until you ship + measure).
It builds a story you can share — your evidence, your loops, your milestones.

My Own Arc Right Now

Today, my Arc looks like this:

Goal: 100 active users in Indie10k
Metric: number of completed loops by real users
Loops: posting on Indie Hackers, Product Hunt, Dev.to, and running distribution tests

As I write this, I’m sitting at 98 signups. Two more people and I cross the first big milestone. 🚀

It’s not life-changing revenue yet, but it’s proof of momentum. That’s what the Arc keeps me focused on — the compounding effect of small loops.

Why I’m Sharing This

If you’re a developer building a project, I’d love your feedback:

Does the idea of an “Arc” make sense for guiding growth?
Would you actually track your side project this way?

I’m building Indie10k in public, so early thoughts from fellow devs are incredibly valuable.

👉 Check out Indie10k if you want to try running your own Arc.

Think of it as a daily growth gym — but instead of push-ups, you’re shipping loops.

Stop Polishing Pixels. Start Bumping Versions.

Ju — Thu, 25 Sep 2025 23:14:57 +0000

Indie devs, I see you.

Pixel-pushing that landing page. Debating if that button should be 1px taller. Sitting on 0.100.0 releases because “it’s not 1.0 ready.”

Guess what? Nobody cares. Users don’t read semver like you do. They care if you ship, if it works, and if you improve fast.

The Fear of 1.0

I’ve been there:

“1.0 feels permanent.”
“What if it’s buggy?”
“I’ll look unprofessional.”

That fear freezes momentum. You end up stuck polishing details that don’t move your MRR.

Flip the Mindset

What if you treated version bumps as momentum markers instead of perfection badges?

1.0.0 — The first time someone pays.

2.0.0 — You fix a core workflow.

3.0.0 — You overhaul onboarding.

Every bump is a story to tell your users, your community, your future self. Each one says: this thing is alive.

Shipping > Perfecting

So stop hiding behind .0.100.0.

Bump majors often.

Celebrate progress.

Keep momentum rolling.

Because SaaS isn’t about perfect pixels. It’s about compounding small wins until one day you look back and realize: wow, this thing grew up.

🚀 At Indie10k, we help indie devs build momentum by turning growth into repeatable loops—not perfection traps. If you’re ready to stop stalling at 0.100.0 and start stacking wins toward $10k MRR, join us and start your first loop today.

Don’t Mercilessly Add AI Just to Look Cool

Ju — Thu, 25 Sep 2025 21:07:34 +0000

I almost fell into the trap.

A user told me: “Writing a North Star goal feels hard.”

And my first reaction? “No problem, I’ll slap in an AI button and it’ll magically write one for them.” ✨

Spoiler: it didn’t work. The AI goals were fluffy, generic, and sometimes completely wrong. It looked shiny on the surface, but it didn’t actually solve the user’s problem. In fact, it made things worse.

The temptation is real

AI is like glitter right now. Sprinkle a bit, and suddenly your product feels trendy. “Ooooh, it has AI!”

But here’s the catch: if it doesn’t reduce friction, save real time, or give users genuine clarity—it’s just noise.

When I forced AI into my product, it created a false sense of “magic” instead of addressing the real struggle: blank-page paralysis.

The boring solution that worked

Instead of giving users an AI-generated goal, I stripped it down:

One metric.
One target.

That’s it.

“User signups → 100.”

“MRR → $50 this loop.”

Not fancy. Not “intelligent.” Just usable.

The lesson

Every time I get the itch to bolt on AI just to impress people, I remind myself:

AI should be the assistant, never the boss.
Features exist to help users move forward, not to pad a product demo.
Simple > Cool. Always.

Curious about your take

Have you ever been tempted (or pressured) to throw AI into your product when a simpler solution was sitting right there?

👉 I’m building Indie10k to help indie devs reach $10k MRR without drowning in overhead. If you’ve got thoughts on when AI is actually useful, I’d love to hear them.