Edge-first architecture for lean SaaS products

A new SaaS product rarely fails because its infrastructure could not scale. It is far more likely to stall because the team spent its time operating infrastructure instead of improving the product. For most early products, the right architecture is the one that removes the most operational work while keeping the product fast.

Edge-first architecture is a good default for that goal.

Static first

Most pages of most products do not change per request: marketing pages, documentation, pricing, guides, blog posts and even many app shells. Render them at build time and serve them from a CDN edge close to the user.

Static pages are fast without tuning, hard to break, cheap to serve and easy for search engines to index. They also shrink the attack surface: no server code runs for a request that only needs HTML.

Run code only where it is needed

Dynamic behaviour — a contact form, an API endpoint, a search query — runs in small edge functions. Route only those paths to code and let everything else be served directly as static assets. Compute costs then track real work rather than page views.

Edge functions also make a useful security boundary: secrets live in the function’s environment, are never shipped to the browser and are never committed to the repository.

Choose managed data deliberately

Pick the smallest data store that fits:

• a serverless SQL database for structured records with modest write volume,
• a key-value store for configuration and caches,
• object storage for files.

Avoid running a database server until the product genuinely needs one. When it does, a static-first front end does not need to change.

Make every change previewable

Each pull request should produce a preview deployment with its own URL, built and tested exactly like production. Reviewers then evaluate the real thing rather than a description of it. Keep previews out of search engines, and keep production credentials out of previews.

Ship with a pipeline you trust

A lean team needs automation more than a large one does. A good pipeline for a small product:

1. type-checks and runs unit tests on every change,
2. builds the site exactly as production will,
3. runs browser tests against the build — navigation, forms and accessibility checks,
4. deploys a preview for pull requests and production for the main branch,
5. makes rollback a single, well-documented action.

Versioned deployments at the edge make rollback fast: redeploy the previous version rather than rebuilding it under pressure.

Measure what users feel

Track real-user performance — loading speed, layout stability and responsiveness — with privacy-friendly analytics that do not need cookies. Lab scores are useful during development; field data tells you what users actually experience.

Know when to move on

Edge-first is a starting point, not a dogma. Long-running jobs, heavy computation, large relational workloads or strict data-residency requirements may justify dedicated services. The advantage of starting at the edge is that you add those pieces when you have a reason — and the parts of the product that were already fast stay fast.