Tech stacks don't matter. What matters is which trade-off your project rewards.

Tech stacks don't matter. What matters is which trade-off your project rewards.

I built 6 AI projects in 30 days. I thought I'd pick a hero stack and stick with it. I didn't. Here's what I actually used and why none of it is the "right" answer.

The TLDR: every project ended up with a different stack because each problem rewarded a different trade-off.

Project 1: AI Buddy (Chrome extension)

Stack: vanilla JS + Manifest V3 + Chrome storage API + OpenAI streaming + Anthropic API key fallback.

Why this stack: a Chrome extension lives inside the user's browser, not on a server. The fastest path to "ship the v0" was zero backend. The extension reads the user's text selection, posts it to the AI provider the user already paid for, renders the response in a sidebar.

The mistake: I tried to use a React + TypeScript scaffold on day one. It took me 4 hours to set up the bundler and I never wrote a feature. I tore it out and rewrote in 240 lines of vanilla JS. The Chrome sidebar doesn't need React. Don't reach for a framework until you need one.

The part I'd do differently: skip Anthropic API key fallback, ship OpenAI-only first. Adding the API key fallback was 5 hours of work for 2 users who exercised it.

Project 2: Email reply generator (web app)

Stack: Next.js 13 app router + Vercel KV (now Vercel Edge Config) for rate-limiting + Postgres (Neon free tier) for history.

Why this stack: every time I'd written a web app from scratch I'd under-spent the first 2 days on routing and auth. With Next.js app router I get those from the package.

The actual thing I built: 3 API routes. /api/rewrite takes a body, calls OpenAI, returns the rewrite. /api/save upserts to Postgres. /api/history fetches the last 10 rewrites. There's no auth at all, no concept of "user", just rate-limiting via Vercel KV keyed on IP. Sometimes that works for v0.

The part I'd do differently: ditch Postgres. I am not running analytics queries on my own email helpers. A SQLite file in a Vercel /tmp folder would have been fine. The Postgres integration took 90 minutes and I never touched the data again.

Project 3: Weekly report generator (CLI)

Stack: Python + click + openai + a single file.

Why this stack: it's a tool I run on Mondays. It's not a product. Putting it on the web would have been 1 day of UI work for me to use it once a week. CLI is the right format.

The pattern: I run python report.py and paste a list of PR titles. Output is one paragraph, English. The script has zero config. It uses a system prompt I iterate on twice a year.

The part I'd do differently: no regrets. This is the only project I haven't shipped anywhere. It's mine.

Project 4: Resume rewriter (web app)

Stack: SvelteKit + Vercel + Resend (transactional email).

Why this stack: I thought SvelteKit would feel lighter than Next.js. It does. The form is 70 lines. The submission handler is 1 API route. Email is sent on submit because "subscribe to results" was a tempting CTA. The 0 signups I got came from this email funnel.

The part I'd do differently: never build it. I never once opened the project to fix a bug. It exists, it's deployed, no one has visited it in 8 weeks.

The bigger lesson: the resume space is dominated by incumbents with SEO moats. You can't rank for "rewrite my resume". Don't bother.

Project 5: AI podcast summarizer (CLI + RSS parser)

Stack: Python + feedparser + openai + a cron job on my laptop.

Why this stack: it's a once-a-week usage. RSS feeds are well-defined schemas. feedparser eats the input, openai eats the feed content, output is a markdown file in /tmp.

The part I'd do differently: I would not have spent 2 hours writing a "summary quality" eval. It does nothing. I read the summaries, they are summaries. That's enough.

Project 6: AI 错题本 (Mandarin study aid)

Stack: Tauri + React + an offline LLM run via llama.cpp.

Why this stack: I wanted a desktop app that doesn't phone home. Tauri gives you a web view in a Rust shell. The LLM runs locally. Everything is offline. Theoretically beautiful.

The part I'd do differently: this was the wrong stack. My Chinese textbook problem set is on paper. Computer vision OCR is the right tool. I built the wrong thing. I used the app once, abandoned it on the second try.

What I'd take forward to a 7th project

1. Build the smallest thing that solves 1 specific problem. Don't build a "platform".
2. Don't reach for React. Vanilla + DOMContentLoaded beats most frameworks for solo projects.
3. Don't ship SQLite or Postgres until the analytics question is real.
4. CLI is underrated. Most of my "tools" don't need a web frontend.
5. A real user is not just a sign-up. A real user is one who came back twice.

If you want to copy any one of these stacks, copy #3 (weekly report CLI). It's the only one that taught me anything that I still think about.

Posted on Indie Hackers because this is what I think IH is for: a place where the people who've actually shipped something describe what they did, and let other people make their own judgement about whether to copy it.