|
| 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