Everyone publishes "my dev setup" lists. This isn't that. It's the exact workflow I use when I have a weekend and an idea I want to ship by Sunday night.
The Stack (Stable for 12+ Months)
| Layer | Tool | Why I Stick With It |
|---|---|---|
| Editor | Cursor | AI-assisted coding without leaving the editor |
| Framework | Next.js or plain HTML | Next for apps, static HTML for content sites |
| Styling | Bootstrap 5 or Tailwind | Bootstrap for speed, Tailwind for custom design |
| Hosting | Vercel / Cloudflare Pages | Free tier, git push to deploy |
| Database | Supabase or SQLite | Supabase when I need auth; SQLite for local-first |
| Version Control | Git + GitHub | Non-negotiable |
My Weekly Workflow
Monday-Friday (1 hour/day max)
- Review one open issue or feature
- Ship a small increment - even a CSS fix counts
- Write a one-line commit message that explains why
Weekend (4-6 hours)
- Pick one feature from the backlog
- Build, test on phone, deploy to preview URL
- Write a short changelog note for myself
What I Deliberately Avoid
- Custom auth - use Clerk, Supabase Auth, or Auth.js
- Microservices - one repo, one deploy, always
- Premature optimization - ship first, profile later
- New frameworks mid-project - boredom is not a reason to migrate
Project Kickoff Template
Every new project starts with this 30-minute ritual:
- Create GitHub repo with README (one paragraph: what + why)
- Scaffold with my default stack
- Deploy "Hello World" to production URL
- Create 3 GitHub issues: MVP feature, nice-to-have, later
If it's not deployed by end of day one, I haven't really started.
When I Break My Own Rules
I switched stacks twice in the past year - both times because the project outgrew the original choice. A static blog became a SaaS. A SQLite prototype needed multi-user access. That's fine. The rule is: don't switch without a concrete trigger, not a vague feeling that something else might be better.