Running a SaaS Portal on Free Tiers — Cloudflare Pages, Supabase, and Upstash

A solo founder can waste months optimizing cloud bills before proving demand. GRAXEL starts with free or low-cost managed services and upgrades only when a specific bottleneck appears.

Why this matters for GRAXEL

Free tiers are not magic. They have limits, sleep policies, quotas, and operational assumptions. The site has to be designed so public pages remain fast and reliable even when background systems are constrained.

Cloudflare Pages handles the public edge surface, Supabase handles relational app data and auth-adjacent workflows, and Upstash-style Redis patterns cover lightweight rate limiting or cache needs. The important rule is to keep the user-facing path simple.

Operational notes

• Keep the user-facing promise narrow enough that the service can be verified in a browser.
• Document the boundary between automated AI output and source-backed data so reviewers can understand the workflow.
• Link the implementation back to the public trust pages: About GRAXEL, Contact, and the platform overview.

For a small SaaS portfolio, trust comes from showing the real operating system behind the product: what runs, why it exists, and how it is maintained.

What changed in practice

This strategy keeps the portal shippable while leaving room for paid infrastructure when traffic or revenue justifies it. The same pattern now influences how the portal presents public services: planned ideas stay out of the main catalog, while usable beta services and documented operating notes receive stronger internal links.

When this article is read together with the monorepo operations note and the zero-cost infrastructure note, it gives a more complete view of how GRAXEL turns small service ideas into maintained products.

Official references

• Cloudflare Pages documentation
• Supabase documentation
• Upstash Redis documentation

Free tier guardrails that matter in production

A zero-cost SaaS stack is attractive, but I treat free tiers as constraints rather than guarantees. Cloudflare Pages can host the frontend, Supabase can provide database and authentication primitives, and Upstash can cover lightweight Redis or queue-style use cases. The risk is that each provider has different limits, billing triggers, and failure behavior. A system can be free during development and unexpectedly fragile during a traffic spike.

My guardrail is to define an upgrade trigger before launch. For example, if background jobs start competing with user requests, I split them out. If database rows grow faster than expected, I archive old data or add retention rules. If Redis keys are used for rate limiting, I set expirations everywhere. I also keep provider-specific logic behind small wrappers so that migration is possible later. The goal is not to avoid paying forever; the goal is to prove demand before committing to a larger bill. A sustainable free-tier architecture should include monitoring, usage budgets, graceful degradation, and a clear point where paying becomes cheaper than spending developer time on workarounds.

Extra review step

I also review which data belongs in each provider. Static marketing pages, authenticated user data, rate-limit counters, and analytics events have different retention and privacy expectations. Keeping those boundaries clear makes it easier to explain the system in a privacy policy and easier to move one component later without rewriting the whole product.