Choosing the Right Web Stack: The ICTech Labs 4-Level Architecture Framework
Most failed software projects don’t fail because they picked the wrong framework. They fail because they picked a stack built for a company ten times their size.
At ICTech Labs, we’ve seen startups spend months wiring up Kubernetes for an app that had 50 users, and we’ve seen growing products held back by an MVP stack nobody planned to outgrow. So we use one rule for every project:
Choose the simplest architecture that satisfies today’s requirements, while keeping a clear upgrade path for tomorrow.
To make that rule practical, we organise our technology choices into four levels. Each level adds capability only when a real requirement demands it.
Levels are about complexity, not company size
It’s tempting to match architecture to headcount. But that’s the wrong axis. A two-person startup building an AI product with background queues and type-safe server functions has a more complex system than a 50-person company running a simple internal dashboard.
That’s why our levels describe what the system needs to do, not who is building it:
-
1ValidateSimple MVPShip fast and cheapReact + Vite → Cloudflare → Supabase
-
2Build the productAdvanced web appStructured full-stack app with SSRReact Router v8 → Cloudflare → Supabase
-
3ScaleGrowing SaaSReliable background and AI workloadsCloudflare + managed platforms, then AWS
-
4PlatformEnterpriseSecurity, compliance, many teamsCloudflare + AWS/Azure/GCP + Kubernetes
You start at the lowest level that fits and move up only when you hit a concrete trigger. And yes, moving down is allowed too: if requirements shrink, simplify.
The simple MVP
Goal: validate the idea in days or weeks, for close to zero cost.
This is the right level for admin dashboards, CRMs, internal tools, booking systems, customer portals, inventory apps and simple AI products that call a model API. You don’t need server-side rendering, containers or a cloud architecture diagram. You need something users can click on next week.
React + Vite gives a fast, familiar single-page app. Cloudflare hosts it globally with a generous free tier and no egress fees, and a small API Worker handles any custom logic. Supabase supplies Postgres, authentication and file storage in one place, so there’s no backend to build for most CRUD features.
| Hosting option | Rating | Why |
|---|---|---|
| Cloudflare Workers Default | ★★★★★ | Cheap, fast, global |
| Vercel | ★★★★★ | Best developer experience (Hobby tier is non-commercial) |
| Netlify | ★★★★★ | Very easy to use |
| Railway / Render | ★★★★★ | Best if your API is in Python |
The advanced web application
Goal: build a structured, full-stack product.
This is where modern full-stack frameworks earn their place: server-side rendering for SEO, server-side data loading, server functions, streaming and sophisticated forms. Our default:
React Router v8 is the current major release and works with Cloudflare through Cloudflare’s official Vite plugin, which keeps deployment simple. For products with complex, type-heavy logic, we reach for TanStack Start instead. Next.js remains a strong choice when its ecosystem is specifically needed; it runs best on Vercel and can also run on Cloudflare through the OpenNext adapter.
| Framework | Type safety | Best for |
|---|---|---|
| React Router v8 Default | ★★★★★ | Our default for full-stack React |
| TanStack Start | ★★★★★ | Complex, type-heavy SaaS |
| Next.js | ★★★★★ | The Next.js ecosystem, Vercel hosting |
| Astro | ★★★★★ | Content and SEO-heavy sites |
| SvelteKit / Nuxt | ★★★★★ | Svelte or Vue teams |
The growing SaaS
Goal: scale reliably as real usage arrives.
At this point the hard problems are no longer in the frontend. They’re in everything around it: background processing, queues, scheduled jobs, file and AI workloads, payments, third-party integrations, observability and security. From here on, we choose the application framework and the infrastructure platform separately.
We split this level into two steps, because the jump straight to AWS is where many teams over-invest.
Cloudflare Queues, Cron Triggers and Workflows; long-running or Python workers on Railway or Render; files on R2; Postgres on Supabase or Neon. No DevOps team required.
A compliance requirement, heavy long-running compute, or cost at large scale. Cloudflare stays at the edge; AWS runs the workloads.
If you’re on step 3a, picture the AWS box replaced by Cloudflare Queues and Railway or Render workers. The shape of the system stays the same, which is exactly what makes the later move painless.
The enterprise platform
Goal: a secure, compliant platform that many teams can build on.
At Level 4 you’re no longer choosing a framework; you’re designing a platform. The drivers are strict security and compliance, many teams owning separate services, and large-scale traffic. A typical shape:
Even here, we keep one eye on simplicity. Kubernetes is worth its operational cost only when the number of services and the team structure justify it; for many organisations, managed containers on AWS ECS do the job with far less overhead.
What about Python and AI backends?
Your API language matters as much as your level. TypeScript backends fit naturally on Cloudflare Workers. Python backends, such as FastAPI services for AI features, are better on container platforms like Railway, Render or Fly.io, and later AWS ECS. Long-running or heavy processing jobs belong on worker services, not edge functions. For most AI features in Levels 1 and 2, calling model APIs directly and storing embeddings with pgvector inside Supabase is all you need.
The essentials people forget
Whatever the level, every project needs answers to these before launch:
- Auth
- Supabase Auth by default; SSO for enterprise clients.
- Payments
- Stripe.
- A transactional provider such as Resend or Postmark.
- Environments
- At least dev and production, with preview deploys per branch.
- Backups
- Confirm they exist and test a restore at least once.
- Observability
- Sentry for errors and PostHog for product analytics from Level 2 onward.
Start simple, grow on purpose
The best architecture isn’t the most impressive one. It’s the one that ships your product now and doesn’t trap you later. That’s why every ICTech Labs project starts with the same question: what does this system actually need to do today? We pick the lowest level that answers it, keep data portable on Postgres, and plan the next step before we need it.
Platforms and frameworks move fast, so we review this framework every six months and update our defaults as the tools evolve.