My Tech Stack: How I Choose Tools for New Agentic Engineering Projects

This post covers how I currently choose a tech stack for a new AE (Agentic Engineering) project. This isn't the "textbook answer" — it's the setup I've converged on through trial and error, optimized for speed and maintainability.

Legend: ⭐ = my current primary / default choice

1) First Question: What Am I Actually Building?

A pure Web App?
Mobile + Web?
A command-line tool or something else entirely?

Define the product form before picking any tools.

2) Most Projects Need a Web Layer

Even if your core product is a mobile app, you almost always need a web presence:

Privacy Policy / Terms of Service — required before any app store submission
Link sharing — let users share via messaging apps before others download your app
Brand presence — a public entry point for search and discoverability

My default web combo:

⭐ Next.js (frontend framework)
⭐ Supabase (database + authentication)

This combination works because: fast onboarding, solid docs, mature community, and excellent MVP velocity. Vite + vanilla React also works well for simpler projects.

3) Mobile: Flutter vs. Native (SwiftUI / Kotlin)

This is one of the most common and difficult questions.

When to Choose Flutter

If your priorities are:

Getting to market fast
One codebase covering both platforms
Feature completeness and information delivery over pixel-perfect animations

Then ⭐ Flutter is usually the right call. It saves significant development time, especially for social, utility, and content apps.

When to Choose Native

If you have high requirements for:

Smooth, highly customized system-level animations
Deep native capability integration (e.g., specialized photo pickers)
Day-one access to Apple's latest UI features (liquid glass visuals, AI integrations)

Then consider SwiftUI / Kotlin native development.

One-line summary: Speed and dual-platform coverage → Flutter. Native experience matters most → go native.

4) Mobile + Web: Add a Unified Backend API Layer

When I have both mobile and web clients, I put a Python Server on ⭐ AWS Lightsail as a unified API layer:

Mobile / Web  ←→  Python Server  ←→  Supabase

I don't let mobile and web talk directly to the Supabase database. The benefits:

Centralized business logic — write it once
Consistent permissions and risk controls — enforce rules in one place
Thin clients — easier to maintain
Isolated database changes — restructure your schema without touching every client

5) File and Image Storage: Currently on Supabase

For now, I use ⭐ Supabase Storage for files and images.

The reasoning is simple:

Seamless integration with the Supabase ecosystem
Good developer experience for early-stage projects
Low maintenance overhead for small teams

I'm also exploring Cloudflare as an alternative for this layer.

6) Long-Term Direction: Gradual Migration to AWS

Long-term, I'll likely migrate from Supabase toward the AWS ecosystem (or Cloudflare alternatives).

A practical consideration is availability and regional risk: Recent events affecting Supabase in certain regions highlight this — the probability of AWS being blocked at the same scale is much lower, simply because the user base is so massive.

Also, tools converge toward the most cost-efficient option over time. Many people used to think AWS was too hard to use, but in the AI era, that disadvantage has been significantly reduced:

Configuration questions? AI can walk you through them step by step
Learn it once, reuse it for every project after

So on the dimensions of long-term stability + cost + scalability, AWS remains a very strong endgame candidate.

Last updated

2026-03-02