Skip to content

Commit 01790ad

Browse files
jesseouecursoragent
andcommitted
feat: refocus SaaS growth blog
Co-authored-by: Cursor <cursoragent@cursor.com>
1 parent c0b9002 commit 01790ad

11 files changed

Lines changed: 229 additions & 269 deletions

File tree

apps/web/app/ai-seo.ts

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -29,12 +29,11 @@ export const aiSeoPages: AiSeoPage[] = [
2929
audience: "teams choosing API SaaS capabilities, provider adapters, and install paths",
3030
},
3131
{
32-
title: "Free SaaS Starter Alternative",
33-
path: "/blog/free-saas-starter-alternative",
32+
title: "Build and Grow a SaaS With Source-Owned Modules",
33+
path: "/blog/building-saas-with-source-modules",
3434
description:
35-
"SEO-focused guide for teams comparing Makerkit, Supastarter, ShipFast, Gravity, Open SaaS, Nextacular, free SaaS boilerplates, and source-owned SaaS modules.",
36-
audience:
37-
"builders comparing SaaS starter kits, boilerplates, licensing, cost, and vendor lock-in",
35+
"Practical guide to building SaaS in layers: API keys, usage, billing, webhooks, auth, analytics, support, SEO, and vendor adapters as editable source.",
36+
audience: "builders planning SaaS architecture, growth loops, and production readiness",
3837
},
3938
{
4039
title: "SaaS Starter Alternatives",

apps/web/app/alternatives/page.tsx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@ export default function AlternativesPage() {
2626
<div className="nav-links">
2727
<a href="/registry">Registry</a>
2828
<a href="/docs">Docs</a>
29-
<a href="/blog/free-saas-starter-alternative">Blog</a>
29+
<a href="/blog/building-saas-with-source-modules">Blog</a>
3030
</div>
3131
<a className="button" href="https://github.com/jesseoue/stackfoundry">
3232
GitHub
Lines changed: 205 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,205 @@
1+
import type { Metadata } from "next";
2+
3+
const articleUrl = "/blog/building-saas-with-source-modules";
4+
5+
export const metadata: Metadata = {
6+
title: "Build and Grow a SaaS With Source-Owned Modules",
7+
description:
8+
"A practical guide to building SaaS in layers: API keys, usage, billing, webhooks, auth, analytics, support, SEO, and vendor adapters as editable source.",
9+
alternates: {
10+
canonical: articleUrl,
11+
},
12+
keywords: [
13+
"build SaaS",
14+
"grow SaaS",
15+
"API SaaS",
16+
"SaaS modules",
17+
"source-owned SaaS",
18+
"SaaS infrastructure",
19+
"SaaS billing",
20+
"SaaS analytics",
21+
"SaaS starter",
22+
],
23+
openGraph: {
24+
title: "Build and Grow a SaaS With Source-Owned Modules",
25+
description:
26+
"Start with one painful workflow, install production SaaS systems as source, and keep vendors as replaceable adapters.",
27+
url: articleUrl,
28+
type: "article",
29+
},
30+
twitter: {
31+
card: "summary_large_image",
32+
title: "Build and Grow a SaaS With Source-Owned Modules",
33+
description:
34+
"A clean path for API keys, usage, billing, webhooks, auth, analytics, support, and growth loops.",
35+
},
36+
};
37+
38+
const buildStages = [
39+
[
40+
"1. Pick the narrow wedge",
41+
"Start with the workflow that proves value fastest. For StackFoundry, that is API SaaS: keys, usage, quotas, credits, billing, docs, and webhooks.",
42+
],
43+
[
44+
"2. Install source, not mystery glue",
45+
"Dry-run the recipe, review every file, then install source that your team can edit, test, and remove like normal application code.",
46+
],
47+
[
48+
"3. Keep vendors as adapters",
49+
"Use Stripe, Clerk, Resend, PostHog, Tinybird, Vercel, Cloudflare, and other great vendors without making them hidden base dependencies.",
50+
],
51+
[
52+
"4. Add operating loops",
53+
"SaaS grows when support, incidents, onboarding, analytics, billing, and customer feedback are connected to product decisions.",
54+
],
55+
];
56+
57+
const systemRows = [
58+
["Access", "Auth boundary, teams, tenant context, roles, invites, SSO, SCIM"],
59+
["Monetization", "Stripe billing, credits, plans, entitlements, invoices, dunning, tax"],
60+
["API Product", "API keys, rate limits, usage metering, docs, webhooks, request visibility"],
61+
["Growth", "Product analytics, Tinybird events, feature flags, lifecycle email, announcements"],
62+
["Operations", "Admin console, support, health, incidents, status, postmortems, audit"],
63+
["Discovery", "SEO, AI SEO, llms.txt, docs, changelog, public roadmap, alternatives pages"],
64+
];
65+
66+
const verificationRows = [
67+
"Run Biome lint/format before shipping UI changes.",
68+
"Run TypeScript typecheck and production build before deploying.",
69+
"Review env notes and never commit provider credentials.",
70+
"Run migration review when schema files land.",
71+
"Smoke check responsive layouts for marketing, docs, registry, and admin surfaces.",
72+
"Keep route groups, API handlers, and provider adapters explicit.",
73+
];
74+
75+
export default function BuildingSaasWithSourceModulesPage() {
76+
return (
77+
<main className="page blog-page">
78+
<nav className="nav" aria-label="Main navigation">
79+
<div className="container nav-inner">
80+
<a className="brand" href="/" aria-label="stackfoundry home">
81+
<span className="mark" aria-hidden="true">
82+
<span />
83+
<span />
84+
<span />
85+
</span>
86+
<span className="wordmark">stackfoundry</span>
87+
</a>
88+
<div className="nav-links">
89+
<a href="/registry">Registry</a>
90+
<a href="/docs">Docs</a>
91+
<a href="/blog/building-saas-with-source-modules">Blog</a>
92+
<a href="/alternatives">Alternatives</a>
93+
</div>
94+
<a className="button" href="https://github.com/jesseoue/stackfoundry">
95+
GitHub
96+
</a>
97+
</div>
98+
</nav>
99+
100+
<article className="blog-article">
101+
<header className="blog-hero">
102+
<p className="section-eyebrow">Build SaaS</p>
103+
<h1>Build and grow SaaS by installing the systems, not adopting a black box.</h1>
104+
<p>
105+
SaaS is not one template. It is a set of systems that need to work together: access,
106+
billing, usage, webhooks, docs, analytics, support, operations, deployment, and growth.
107+
StackFoundry gives those systems to you as editable source modules.
108+
</p>
109+
<div className="blog-meta">
110+
<span>Source-owned modules</span>
111+
<span>API SaaS first</span>
112+
<span>Vendor adapters optional</span>
113+
<span>Free to use</span>
114+
</div>
115+
</header>
116+
117+
<section className="blog-callout">
118+
<strong>The practical path</strong>
119+
<p>
120+
Start narrow, ship a working SaaS workflow, then expand. Install the source, review the
121+
diff, run the checks, and keep the architecture understandable enough to change later.
122+
</p>
123+
</section>
124+
125+
<section className="blog-section">
126+
<h2>Build from a wedge, not a catalog</h2>
127+
<p>
128+
The fastest way to make a SaaS product real is not to install every module. It is to
129+
pick a workflow customers immediately understand. API SaaS is a good first wedge because
130+
the value is concrete: developers need keys, usage, quotas, credits, docs, webhooks, and
131+
billing.
132+
</p>
133+
<div className="blog-comparison">
134+
{buildStages.map(([title, body]) => (
135+
<article className="blog-comparison-card" key={title}>
136+
<div>
137+
<span>Build Stage</span>
138+
<h3>{title}</h3>
139+
</div>
140+
<p>{body}</p>
141+
</article>
142+
))}
143+
</div>
144+
</section>
145+
146+
<section className="blog-section">
147+
<h2>Use vendors, but keep the product model yours</h2>
148+
<p>
149+
Great SaaS products use great vendors. The difference is where the boundary sits. A
150+
provider should adapt into your product concepts, not become the only place your product
151+
logic exists.
152+
</p>
153+
<div className="blog-grid">
154+
{systemRows.map(([title, body]) => (
155+
<div className="blog-card" key={title}>
156+
<h3>{title}</h3>
157+
<p>{body}</p>
158+
</div>
159+
))}
160+
</div>
161+
</section>
162+
163+
<section className="blog-section">
164+
<h2>Grow with operating feedback loops</h2>
165+
<p>
166+
Growth is easier when product signals are connected. Usage data should inform billing.
167+
Support tickets should connect to roadmap items. Incidents should feed postmortems. Docs
168+
and SEO should explain the product path. Announcements should close the loop when the
169+
work ships.
170+
</p>
171+
<p>
172+
That is why StackFoundry includes more than launch modules. It includes customer
173+
intelligence, support ops, public roadmap, product announcements, analytics adapters, AI
174+
SEO, and operational checklists.
175+
</p>
176+
</section>
177+
178+
<section className="blog-section">
179+
<h2>Ship only after the checks are boring</h2>
180+
<div className="blog-module-list">
181+
{verificationRows.map((row) => (
182+
<div className="blog-card" key={row}>
183+
<h3>{row}</h3>
184+
</div>
185+
))}
186+
</div>
187+
</section>
188+
189+
<section className="blog-cta">
190+
<div>
191+
<p className="section-eyebrow">Start Narrow</p>
192+
<h2>Dry-run the API SaaS recipe before writing source.</h2>
193+
<p>
194+
Preview the modules, dependencies, env notes, maintenance skills, and checklists
195+
before the code lands in your app.
196+
</p>
197+
</div>
198+
<div className="blog-command">
199+
<code>pnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run</code>
200+
</div>
201+
</section>
202+
</article>
203+
</main>
204+
);
205+
}

0 commit comments

Comments
 (0)