Dropping everything to seize a 7-figure-ARR opportunity

Rachit Khator saw an opportunity and left it all behind, quitting his corporate job and moving back to India to start Stackby. Eight years later, it's bringing in a 7-figure ARR.

Here's Rachit on how he did it. 👇

Quitting the 9-to-5

I'm Rachit, founder of Stackby, an AI-first no-code platform that helps non-technical users build business apps. I've been running it for eight years now.

In 2017, I was in a corporate role at a Fortune 500 company in the US. We managed all our data on spreadsheets and sought a custom tool to manage our workflows. That's where the idea for Stackby came from. I decided to build a platform that was as simple as a spreadsheet, but sophisticated enough to allow non-technical users to build custom databases and apps.

I quit my job in 2018 and moved back to India to start Stackby. Today, we have a 7-figure ARR with a15-20% growth MoM.

Positioning and distribution challenges

Building Stackby in the shadow of a category-defining product like Airtable has been both the biggest opportunity and the hardest challenge.

The first obstacle was positioning. When you’re not first, you don’t get to define the narrative — you have to wedge yourself into it. Early on, we struggled with being seen as “just another Airtable alternative,” instead of a platform with its own philosophy around APIs, automation, and structured workflows.

Second was focus vs. flexibility. Stackby sits at the intersection of spreadsheets, databases, and no-code automation. That’s powerful — but it also creates constant tension: Should we go horizontal like Airtable? Or verticalize into specific use cases? We spent time oscillating instead of committing.

Third, speed vs. quality in product execution. As a smaller team competing with well-funded players, we felt pressure to ship fast. But in tools like ours, reliability and UX depth matter more than just shipping features. We had to learn where speed hurts you.

Building and growing

As far as our stack, we use the latest in JavaScript + TypeScript, as well as AI coding tools and AWS.

Distribution was a challenge. In SaaS, product is only half the game. You can build a great product and still lose. Indie hackers underestimate SEO, templates, content, and communities. And we underestimated how hard it would be to build a consistent growth engine.

Products don’t grow — distribution systems do. If you’re not thinking about how users will find you before you build, you’re already behind.

Overall, we've grown through quite a few channels:

• Product-led growth

• SEO, and now AEO

• Referrals

• Influencer marketing

• Community

• Email

• User-generated content

We use subscription, per-seat pricing across different tiers, so revenue also grows by increasing team sizes across organizations and enterprises.

Double down on what works

We knew templates could drive SEO and activation — but instead of building a polished marketplace:

• We manually created ~20–30 templates.

• We published basic landing pages (no fancy UX).

• We tracked organic traffic + duplication rate.

Result:

• A few templates drove disproportionate traffic.

• Most got ignored.

So, we doubled down only on high-intent categories (marketing, project tracking, CRM) instead of wasting time building a “beautiful but empty” marketplace.

Ride existing demand

Here's my advice:

1. Ride existing demand instead of creating new categories. Don’t try to invent behavior. Instead, build on top of tools like Shopify, Slack, or Google Sheets. Or create alternatives in proven categories. It’s much easier to win a slice of an existing market than to educate a new one.

2. Build embarrassingly small first versions. Your V1 should feel almost too simple. One use case. One persona. One clear outcome. Don’t build a platform. Build a tool that solves one job extremely well. Stackby itself would have been very different if we had started narrower and expanded later.

3. Don’t overbuild “tech” — optimize for speed. You don’t need perfect architecture. Use no-code where possible. Use APIs aggressively. Cut corners (intelligently). Your goal isn’t clean code — it’s fast learning.

4. Talk to users, but filter brutally. Users will ask for features they won’t use and describe solutions instead of problems. Your job is to understand the underlying pain, ignore 70% of what you hear, and build for patterns, not individuals.

5. Stay capital-efficient longer than you think. Raising money early feels like progress. It’s often a trap. Constraints force better prioritization, faster iteration, and real business thinking. A lot of great indie products die after raising because they lose discipline.

6. Be okay with slow, invisible progress. The early phase is quiet: low traffic, few users, lots of doubt. This is normal. Most people quit not because it’s impossible, but because it’s not immediately rewarding. Indie hacking isn’t about building fast. It’s about learning fast with minimal cost.

If you get that right, everything else — product, growth, revenue — starts compounding.

What's next?

From here, we'll build a powerful AI-native platform for creating production-ready and enterprise-grade business apps.

You can follow along on YouTube and Instagram. Or check out Stackby:

• Stackby blog

• Stackby Guides

• Stackby community

• Stackby templates