Swaraj Nandedkar

Building FlitKey, an open-source local-first text expander. Sharing vibe coding, product GTM, and what gets a small tool used.

[Swaraj Nandedkar @RealSwaraj]

@Jyotisharnava Hyavarshi pan yetil kadachit

[Swaraj Nandedkar @RealSwaraj]

JEV killer by OpenAI arrived? Decisions API is in preview.

#devday #openai

[Swaraj Nandedkar @RealSwaraj]

@mehulmpt True. Looks similar and faster in first looks.

[Swaraj Nandedkar @RealSwaraj]

@mehulmpt Business is Business tbh.

[Swaraj Nandedkar @RealSwaraj]

@pranvtwt Have you used Brag tool for this video?

[Swaraj Nandedkar @RealSwaraj]

Indie building is a game of compounding small iterations.

• Audit your real work vs. vanity metrics
• Fix your own daily papercuts
• Listen to how your users speak

Reset on Sunday. Ship on Monday.

Follow @RealSwaraj to watch the journey of building FlitKey from scratch.

[Swaraj Nandedkar @RealSwaraj]

Building in public gets exhausting if you measure progress only by follower count or impressions.

Here is the 20-minute Sunday review routine that keeps solo builders grounded and productive:

[Swaraj Nandedkar @RealSwaraj]

3. Mine the conversation replies

Re-read the replies to your 3:30 PM prompts.

What words did other builders use? What specific complaints kept popping up?

Their exact phrasing is the raw material for your next week's hooks, product copy, and opinion posts.

[Swaraj Nandedkar @RealSwaraj]

What is your biggest personal productivity trap when working solo: endless research, obsessive refactoring, or hopping to new projects too early?

[Swaraj Nandedkar @RealSwaraj]

Consistency on X isn't about having a groundbreaking revelation every morning.

It’s about documenting the boring bug you fixed on Tuesday and the mistaken assumption you caught on Friday.

Proof of work compounds.

[Swaraj Nandedkar @RealSwaraj]

Your job as an indie builder isn't to be an order-taker for every passing comment.

Protect your product's simplicity. Listen intently to user confusion, but design the simplest possible remedy.

Follow @RealSwaraj for more insights on product GTM and building in public.

[Swaraj Nandedkar @RealSwaraj]

Early user feedback is noisy.

If you build every suggestion people tweet at you, you will build a disjointed Frankenstein app.

Here is how to translate what early testers say into what your software actually needs:

[Swaraj Nandedkar @RealSwaraj]

3. The 3-user threshold

Don't refactor for a single tweet request. Log it and wait.

If three separate users encounter the exact same roadblock, it's a systemic friction point that warrants code changes.

Otherwise, protect your roadmap from edge-case noise.

[Swaraj Nandedkar @RealSwaraj]

How do you remember keyboard shortcuts for new tools: cheat sheets, pure muscle memory, or do you eventually give up and reach for the mouse?

[Swaraj Nandedkar @RealSwaraj]

Useful user feedback rarely sounds like "Here is a great feature idea."

It sounds like "I got confused right after opening it" or "I stopped using it because I couldn't remember the shortcut."

Fix friction before adding features.

[Swaraj Nandedkar @RealSwaraj]

You don't earn user trust with twelve mediocre, half-tested features.

You earn trust with one narrow tool that works every single time without stuttering.

Ruthlessly cut the fluff. Ship the core.

Follow @RealSwaraj for daily build-in-public breakdowns.

[Swaraj Nandedkar @RealSwaraj]

The difference between builders who ship and builders with 30 abandoned repo folders is knowing what NOT to build.

AI makes code generation so fast that saying "no" to features is your highest-leverage skill.

How to run a weekly 'Kill-List':

[Swaraj Nandedkar @RealSwaraj]

3. Keep a ROADMAP_LATER.md file

When an exciting idea strikes while you're fixing a bug, don't context switch.

Write it in your parking lot document immediately.

It frees your mind from the fear of forgetting the idea, while keeping your current branch focused on shipping.