Bootstrapping a SaaS boilerplate to $25k MRR with Kyle Gawley from Gravity
Gravity can't offer refunds — it's downloadable source code, so once someone has it, there's no way to revoke access. Kyle Gawley's entire sales process is built around removing that risk before it ever becomes an objection: a live sales counter, third-party Trustpilot reviews, and a 20-minute video walking through the actual codebase.
Kyle Gawley is the founder of Gravity, a SaaS boilerplate that bundles payments, authentication, UI, and email so developers can skip the undifferentiated setup work and focus on what's unique to their product.
We get into how a side project meant to speed up his own builds accidentally became the product itself, why a no-refund policy on a high-priced product demands an unusually deliberate trust-building strategy, and why he thinks developers are actually easy to sell to — because almost everyone else selling to them does it so badly.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did Gravity actually start?
I built it purely to scratch my own itch — I wanted a boilerplate so I could launch my own ideas faster. Someone I met in a co-working space showed me competitors in other languages, like Bullet Train for Ruby on Rails, and pointed out that people were paying real money for something like this, suggesting I put it on Indie Hackers. I didn't even know what Indie Hackers was at the time. I threw together a crude prototype, a basic landing page, priced it at $99, and sold three copies in the first month after launching in September, then five more by the end of the year. My actual intention was to build a tool to help me ship more products — instead, the boilerplate itself became the product.
Buying a boilerplate means trusting code you haven't seen, that your whole startup will be built on top of. How central is trust to your sales process?
It's the single most important part of my sales process. The product is high-priced, and because it's downloadable source code, I genuinely can't offer refunds — once someone has the codebase, there's no way to revoke access, so I have a strict no-refund policy. That's a real barrier for some buyers, and the only way past it is building enough trust upfront that it stops feeling like a risk.
What specifically have you done to build that trust?
A live counter on the site showing how many other businesses and developers are using Gravity, ticking up with every sale — one customer told me that social proof mattered a lot to her decision. I also feature testimonials, including one from a designer at Apple who used Gravity to spin up a side project and directly compared the code quality to Apple's own engineers, which is a huge credibility signal. Trustpilot reviews matter too, precisely because they're independent — I don't control what gets posted there, unlike testimonials on my own site, which anyone could fabricate. And I'm on Twitter every single day, which functions as a kind of public accountability — if someone's skeptical about whether I'm even a real developer, they can click through and see me actively talking about building products in JavaScript.
Beyond trusting you as a legitimate business, developers presumably also need technical trust — that the code itself is actually good. How do you address that?
That's trickier, and even with everything else in place, customers have told me there's still some perceived risk — not that the code is garbage, but that it might not be structured the way they'd want. The codebase follows a standard MVC pattern with some deliberately opinionated technology choices. The single most effective thing I've done to reduce that perceived risk is a 20-minute YouTube video called 'The Architecture of a Modern JavaScript SaaS Application,' where I walk through the actual Gravity codebase — the API, the client structure, the models and controllers — narrating the reasoning behind decisions. When someone asks to see the code, I just send that video instead of a static screenshot, and actually hearing me explain the structure does far more to dispel the fear that it's an unstructured mess than any written description could.
How do you actually spend your time on marketing day to day?
I'm extremely disciplined about being on Twitter every single day, thinking through strategy and content. YouTube I'm honestly not as consistent with — I have a plan written out, but the logistics of gear, lighting, and travel make it harder to execute on. I tend to move through intense phases — a stretch heavily focused on building a course, then a stretch heavily focused on marketing, then experimenting with AI. The key is keeping building and marketing tightly coupled — even when I'm playing with an unrelated AI side project, it generates content I can tweet about, and since that side project is itself built with Gravity, promoting it indirectly promotes the boilerplate too. If I'm going to build something just for fun, I try to make sure it still feeds into marketing or building-in-public rather than staying a pure hobby.
Does showing a scrappier, less polished side project on Twitter risk undermining trust in Gravity's own polish?
It's something I've thought about more recently. Customers consistently tell me the polished, high-quality Gravity demo app — something they can actually click through, not just view code for — matters a lot to their decision. My newer AI side project, by contrast, is intentionally scrappy, shipping a rough feature every day. But I think the people actually considering buying the boilerplate understand the difference, because they're following me on Twitter and already know why I'm being scrappy with that specific project — they'll still go look at the polished Gravity demo separately and judge it on its own terms.
Do most buyers come in with a specific product already in mind, or are they browsing?
Somewhere between 80 and 90% already have a specific product in mind and are about to start building it — that's what triggers the purchase. Maybe 5-10% buy it purely for educational purposes, to learn how a well-structured product is actually put together, and then go build something themselves with that structure in mind. Given the price point, it's not really a casual, tinkering purchase — people buying it tend to already know what they're building and how they plan to monetize it.
You've mentioned doing well with SEO too. How did that come about?
That was another happy accident early on — there was no other Node.js boilerplate at the time, so I ranked for those keywords very quickly with almost no effort. Since then I've invested more deliberately in refining and optimizing the site's performance. For anyone trying to do their own SEO without expensive tools like SEMrush, I'd point to Catlinks — a much cheaper tool, starting around $9-15 a month, that's great for auditing pages, tracking backlinks, and even suggesting where to actually go get backlinks, which I found genuinely useful since I didn't know to look in those places myself.
If you had significant funding to deploy on marketing, would you actually spend it differently?
I'd invest more in content — more video, more blog posts — specifically to compound the SEO benefit, rather than paid advertising. Developers just don't respond well to ads; most run ad blockers, and I've tested Facebook ads, Reddit ads, and Carbon ads extensively with essentially no results. My conclusion is that developers either don't see the ads at all, or see them and simply aren't interested. But they clearly do respond to content and community — the build-in-public and Indie Hackers communities on Twitter are genuinely massive, with the same people actively engaging every single day, and being a real part of that community is essential.
Doing all your marketing under your personal Twitter profile rather than a branded company account — is that a deliberate choice?
Yes, and I recognize a VC might see it as just promoting myself rather than the business, since my personal brand is so tightly coupled with my products. But I think even VC-funded companies benefit enormously from having a real, public-facing human at the front of the brand rather than an anonymous account — people want to engage with humans on Twitter, not faceless logos. I did experiment with running separate branded accounts for other side projects a few years ago and found it was too much overhead managing multiple small audiences across different niches, so I consolidated everything under my own profile. It also de-risks things — if one product fails, I still retain the audience as an asset I can use to launch and market the next thing.
What do you think people commonly get wrong selling to developers?
My Twitter DMs are full of cold pitches every single day from people I've never interacted with, who don't follow me, pitching something often only loosely relevant to what I do. Developers get hit with this constantly, and it's genuinely so widespread and so badly done that doing it even slightly better makes you stand out immediately. If someone's already engaged with my content publicly and then launches something and asks me to check it out, I'm far more likely to actually look. A good example is Dagou Bear, well known for his Twitter memes — I'd interacted with him many times over the years, and when he launched his course, I bought it instantly with zero resistance, purely because I already had a real relationship with him built up over time. A cold DM from a stranger, no matter how good the landing page, is a much harder sell than that.
What's next for Gravity?
I recently pre-launched a course teaching people how to build a SaaS product from scratch, aimed at developers who want to learn to do it themselves rather than just buying the boilerplate outright — splitting the audience into people who'll happily pay to save time versus people who want to learn the skill and will pay for that instead. Going forward, I want to stay laser-focused on the indie hacker, technical founder niche and build additional tools that fit under the Gravity umbrella, though I'm cautious about spreading into too many things that fail to gain real traction rather than doubling down on what's already working.