stopped rewriting auth for the 4th time and extracted it.
Second product in. Same grind. Supabase auth, Stripe checkout, webhook handler, RLS policies, admin routes. I'd written all of it before. I'd debugged all of it before. And I was about to do it all again.So I stopped. Opened a new repo. Started pulling out the parts that had been copy-pasted between every previous build. That repo is Forge Stack. What it is. A Next.js + Supabase + Stripe starter. The boring kind. No marketing-page generator, no AI boilerplate. Just the auth + billing admin + webhook stack that's already running my own SaaS in production.
What's actually in it:
• Supabase SSR auth (email + OAuth)
• Lemon Squeezy checkout, 4 tiers wired • Webhook with HMAC verification
• Email-gated admin routes + stats endpoints
• Postgres migrations + CLI scripts
• Resend email helper
• Sentry pre-wired (client + server + edge) • OG image, PWA manifest, sitemap, JSON-LD
What's NOT in it (so you don't waste time looking):
• AI boilerplate
• A polished marketing-site template • Tailwind component gallery
• Anything Kubernetes
• "Growth hacking" scripts
Who it's for: solo founders shipping a SaaS, engineers who want boring infra done. Not for: agencies, enterprise teams, anyone needing complianc certifications. Pricing: 99-499 once. 14-day refund. The honest bit. I update Forge Stack only when my own SaaS breaks something in production. That's the trade-off. You get a starter I trust enough to deploy my own money on, not a Discord full of weekly release notes.
The “I update it when my own SaaS breaks something in production” bit is probably the strongest trust signal here. You’re not selling a theoretical starter. You’re extracting the boring pieces you’ve already had to maintain. Forge Stack feels like it could be pulling in a lot more organic traffic than it probably is right now, especially for solo founders who just want this stuff out of the way. Have you noticed which piece makes people decide they need it?
Honestly — no, I haven't noticed yet. There haven't been enough buyers to extract a real signal from. Too early to call. The honest gut feel: the webhook signature verification + the email-gated admin pattern get the longest "oh, I needed this" reactions when I show people the demo. The OG image thing and the Resend email helper are nice but feel like "free with the rest." That's a hypothesis though, not data. On organic traffic — launched a week ago. The pieces I put in place for it are the FitForge backlink, the 7 /vs/* comparison pages, and the canonical/JSON-LD setup. Whether any of that actually moves the needle is something I'll see in 30-60 days. Right now I'm guessing same as anyone reading this.
The 7 comparison pages and technical SEO setup are a good start, but I’d be careful about judging the SEO side purely on a 30–60 day window. With a relatively new domain and very little authority, going straight after the obvious high-volume keywords will usually put you against sites that already have years of links, content and topical authority behind them.
I’d approach it from the other side: find the gaps around the keywords you actually want to own, start with smaller/less competitive opportunities, build relevant pages around those, and gradually strengthen the domain authority alongside them. The goal isn’t just to get indexed it’s to build enough relevance and authority that the harder terms become realistic later.
That’s also where I’d consider a small, consistent layer of relevant media placements. Not as a shortcut to rankings, but as part of the authority foundation while the organic side compounds itself. I’d rather start small, track indexing/rank movement/referral traffic weekly, and build from the data than throw a big budget at links and wait 60 days hoping something happens.
If you want to go deeper on the keyword-gap + authority side, feel free to email me at mumar@growwithmumar.online. I can show you how I’d structure the first phase for Forge Stack.
Fair take on the timing window — 30-60 days is barely index-arbitration territory for a new domain. The small-keyword-first ladder is the right move in principle. Out of curiosity, what are you shipping these days?
These days I’m mostly working on the research/strategy side of organic growth — figuring out which queries are actually worth building around before getting into content, authority or distribution.
One thing I’ve become pretty convinced about is that the biggest mistake is treating keyword selection as a step before the “real” SEO work. If the query is wrong, even a technically perfect page + backlinks won’t do much. You can rank and still attract the wrong people.
For Forge Stack, I’d probably start by mapping the problems solo SaaS founders are already searching for around auth, billing, webhooks, admin infrastructure, etc., then look at the gaps in those SERPs rather than just chasing the biggest-volume terms.
That also gives you a better foundation for GEO/AI search later, because the pages that get referenced tend to be the ones that clearly answer a specific problem and are actually relevant to the query.
So I’d validate the “what should we own?” layer first, then build the content/authority strategy around what survives that validation.
"Validate the query before the page" is right in the abstract. Where I'd push back: for Forge Stack specifically, the bottleneck isn't which keywords to chase. It's getting in front of solo founders in the first place — IH, niche subs, founder DMs, a few /vs/* pages. Volume on a query that no solo SaaS founder actually searches doesn't move the number. Specific thing I will act on: the "pages that answer a specific problem get cited in AI" part. I built /vs/create-t3-app and /vs/shipfast as buyer-intent pages and they got cited faster than the home page ever did. Going to look at the next 2-3 /vs/* candidates through that lens instead of pure search volume.
Thanks for the specificity — easy to take seriously.
That’s actually a much stronger signal than raw search volume. If those comparison pages are already getting cited faster, I’d use that as the starting point and map the next few candidates from the problems they’re solving, not just keyword volume.
That’s pretty close to the research work I do finding the buyer-intent gaps first, then figuring out which pages and distribution can give them the best chance of showing up in both search and AI answers. Happy to take a quick look at the next few candidates if useful.
Yeah comparison pages were a "follow the trail" move, not the original plan. Volume was the easy signal to grab but it's noisy. Curious what you build is the gap-mapping a product, agency thing, or research you do on your own stuff?
Mostly hands-on research and strategy for early-stage SaaS/products. I help founders find the buyer-intent gaps worth going after, then turn those into content and distribution opportunities. I usually work directly with the founder rather than through a separate SEO tool.
For Forge Stack, I think the comparison-page signal you found could be a really interesting starting point.
That's a useful way to put it "buyer-intent gap" is closer to what I was reaching for when I described the /vs/* pages. I started with the obvious comparison queries (nextjs supabase starter, supabase auth boilerplate) without testing whether those were the actual gap or just the obvious ones. The fact that you work the problem from the gap side instead of the supply side is a meaningful flip in approach. If you want to keep this going, the most useful thing I can give you is async my DMs are open, or you can reach me at the address in the IH thread profile. The comparison-page data I have is small (launched a week ago, ~8 weeks of indexed time before I can read signal from it) so it's a "too early to share" thing on the analysis side, but I'm collecting the raw data and would value an outside read once there's enough of it.
Thanks for the thoughtful pointer.
The “I’d written all of it before” part is painfully relatable.
Also curious how much of Forge Stack came directly from the things that kept breaking across your own SaaS builds. That seems like the most useful part of extracting it into a reusable starter.
Honestly, more rebuilding than debugging. The thing that got old wasn't "this bug is hard to fix" — it was "I'm spending a Saturday writing the same auth + Stripe webhook handler for the 4th time." A lot of Forge Stack is just the parts I kept copy-pasting between repos: the auth setup, the webhook receiver, the admin gate, the boring Postgres migrations folder. The few places I actually chased a real bug were the webhook signature verification (got burned once when I forgot to verify), and the email-gated admin middleware. Everything else is "I wrote this 4 times, now I'll stop."