Cloud and DevOps for SMBs: Scalable Infrastructure Without Over-Engineering

The cloud infrastructure conversation often starts off on the wrong foot. Someone says "Kubernetes," someone else chimes in with "microservices," and before you know it, you’ve got a diagram with 17 boxes no one knows how to maintain. Meanwhile, your business is still juggling 50 customers and a server that crashes every Monday.

Let’s talk about real infrastructure for real businesses.

The pre-optimization trap

Donald Knuth said it in the 1970s, and it still holds true: premature optimization is the root of all evil in software. In infrastructure, it’s worse because you’re paying for it every month. Every bit of capacity you provision before you need it is money you’ve already spent—and won’t get back.

The right question when starting out isn’t "How do I scale to a million users?" It’s "How do I avoid crashing with the first 100 users, and how do I set things up so scaling to a million is possible without rewriting everything when the time comes?"

What a real SMB actually needs

After working on dozens of projects, the stack we rely on 90% of the time is refreshingly boring (in the best way possible):

• Frontend and server-side rendering: Vercel for deployments, with Next.js. Simple to set up, auto-scales, edge network in LATAM, and starts at $0 until you hit real volume.
• Database and backend: Supabase. A solid Postgres instance with a user-friendly interface, built-in auth, storage, and row-level security for multi-tenant setups. It’s the closest thing to "Firebase but with SQL."
• Heavy file storage: Cloudinary or direct S3, depending on the use case.
• Minimal observability: Vercel Analytics + Sentry for errors. Datadog and the rest can wait.
• CI/CD: GitHub Actions. Free up to volumes that 95% of SMBs will never reach.

That’s it. No Kubernetes clusters, no service mesh, no ingress controllers. And it handles hundreds of thousands of requests without breaking a sweat.

The Tontin case: when complexity is justified

There are moments when simple infrastructure isn’t enough. Tontin, our AI-powered coaching platform, is one of them. Here’s where a Vercel + Supabase setup falls short:

• Multi-provider AI calls with automatic fallback (Groq, Gemini, OpenAI, Anthropic). That requires a custom orchestration layer.
• Semantic search with embeddings. Solved using pgvector inside Supabase’s Postgres, avoiding the need for Pinecone or Weaviate and keeping infrastructure lean.
• Context compression between sessions to maintain persistent memory without blowing token costs. A TypeScript middle layer reduces context by 50% before each call.
• Over 500 completed conversations served from this architecture without a single downtime incident.

The takeaway? Complexity is added only when the business demands it, not when the diagram looks prettier.

When to actually move to Kubernetes (spoiler: almost never yet)

Operational rule of thumb: if you can’t articulate exactly why you need Kubernetes, you don’t need it. Legitimate use cases are rare:

• You have more than 10 independent services updating at different cadences.
• Your traffic volume justifies multiple nodes and orchestration (think thousands of sustained requests per second).
• Your DevOps team has proven experience operating clusters. This is critical: a poorly managed Kubernetes cluster is worse than a well-maintained monolith.

For a typical SMB with 1-3 products and traffic measured in hundreds of requests per minute, Vercel + Supabase + a couple of serverless functions covers everything, costs a fraction, and can be managed by a single developer.

Observability: the bare minimum you can’t skip

There are three things you must have from day one, even if the rest of your stack is minimalist:

1. Accessible logs. If you can’t see what happened when something fails, you’re flying blind. Vercel and Supabase include these by default.
2. Critical error alerts. Sentry’s free tier covers most cases. Rule of thumb: if an error impacts a production user, someone needs to know within 5 minutes.
3. Usage metrics. Active users, page views, conversions. GA4 + Vercel Analytics. Without this, any optimization decision is a shot in the dark.

The golden rule

Start simple. Measure everything. When something doesn’t scale, optimize it. When something keeps crashing, refactor it. But don’t add complexity preemptively. Every extra box in the diagram is another potential failure point—and another line item on your AWS bill.

If you’re building new infrastructure or already have something that keeps crashing when it shouldn’t, reach out. We’ll audit your setup and tell you exactly where you’re overspending or sitting on a hidden risk.

---

By Esteban Aleart, Founder & Lead Engineer at Pair Programming.