In 1984, your stack was a Commodore 64, a rusty soldering iron, and the sheer force of teenage optimism. Today, the stack is… a labyrinth of frameworks, APIs, SDKs, LLMs, CLIs, CICD pipelines, and at least one tab you forgot to close that’s now playing lo-fi beats at 400% volume.
So, what does our modern-day throwback build look like?
Let me introduce you to the stack that’s going to power our nostalgia-fueled, AI-accelerated, keyboard-smashing journey—minus the floppy disks.
🎨 Choosing a Frontend Framework Without Losing Our Minds (Mostly)
Four frameworks, one track, infinite stack overflow detours.
Choosing a frontend in 2025 is like trying to pick a cereal at the grocery store when you’re already hangry. There’s React Native, Flutter, Ionic, Xamarin, and at least four other frameworks that didn’t exist when I started this sentence. Every option has 10,000 blog posts explaining the pros and cons—half of which contradict each other, and the other half were written by someone who’s never actually shipped an app.
In the end, we went with Flutter—an open-source UI software development kit created by Google that lets us build for mobile, web, and desktop from a single codebase. Why?
Have we used it before? Yes? Cool. That’ll do.
The decision-making process of champions.
☁️ Choosing a Backend Without Actually Building One
Three platforms enter, one handles your auth without making you cry.
Let’s be honest—no one really wants to write backend code anymore. Databases? Auth? Rate limiting? Pass.
That’s the kind of work that made us question our life choices back in the PHP/MySQL-on-a-shared-hosting-plan days.
So instead of spinning up a server and whispering sweet nothings to Postgres, we went shopping for a Backend-as-a-Service (BaaS). Something magical that handles all the messy stuff—auth, database, functions, storage, spam protection, dark magic—so we can focus on shipping features (and drinking coffee).
The contenders? Appwrite, Supabase, and yes, even the mighty Firebase.
While both Appwrite and Firebase are great BaaS platforms that support a truckload of SDKs and integrations, they each come with their own flavor of backend sorcery.
- Appwrite brings that open-source energy, self-hosting freedom, wallet-friendly pricing, and a surprisingly helpful community that doesn’t make you feel bad for asking dumb questions.
- Firebase, on the other hand, flexes with Google-grade infrastructure, slick integrations, and the kind of maturity you get when you’ve been the go-to backend since the dinosaurs ran jQuery. But—no self-hosting. At all. You’re in Google’s house, and you better wipe your feet.
And then there’s Supabase— another open source BaaS system which also supports self-hosting but requires more DIY spirit. Both Appwrite and Supabase use Docker and provide Compose files for deployment.
The difference?
- Appwrite: One command, one config, one cozy setup. One-click deploys on DigitalOcean, Gitpod, and Akamai.
- Supabase: Multiple moving parts, community Helm charts, and an implicit “good luck, friend.”
Plus, Appwrite’s Sites feature gives us built-in frontend hosting, so we’re not duct-taping Netlify and Vercel into our stack like it’s a middle school science project.
In the end, we went with Appwrite. Why?
- It supports more SDKs and Languages
- It doesn’t pause your free project just because you went camping
- The functions marketplace is stocked with goodies (Stripe, ChatGPT, Discord bots, probably a toaster)
- The permissions system is human-readable
- And—this part mattered more than we expected—we can self-host it if we ever want to go full tinfoil-hat mode
Plus, we already knew the platform inside and out. Sometimes the best technical decision is the one that doesn’t make you learn a new deployment system at 2 AM.
👉 Honorable mention: Supabase is a solid, well-documented platform with plenty of power under the hood. If you don’t mind a bit more hands-on setup, it’s absolutely worth checking out for your own project. One big difference from my POV is that Supabase’s PostgreSQL database provides more flexibility vs Appwrites abstracted MariaDB implementation. Not an issue for me, but might be for you…
🛠️ Finding the Right IDE: Code in Comfort, Think in AI
Four editors, one café, infinite autocomplete battles.
For developers, an IDE isn’t just a tool—it’s your favorite pair of jeans. The ones that fit just right, have that perfectly worn-in Ctrl+S shortcut, and make you feel like you can debug anything (except maybe your personal life). Choosing the right one isn’t just preference—it’s personal.
And just like the denim industry, the IDE world is changing fast, especially with AI now riding shotgun in every serious contender.
Let’s give credit where it’s due: Cursor and Windsurf were the first real AI-powered IDEs that made us go, “Whoa, this isn’t just autocomplete anymore.” They were bold, ambitious, and—honestly—kind of magical the first time you watched one write a function faster than you could think it through.
- Cursor stood out early as a polished powerhouse, merging lightning-fast editing with deeply integrated AI. It’s slick, serious, and ideal for complex projects—if the price tag doesn’t scare you off.
- We didn’t spend a lot of time exploring Windsurf, but it’s worth mentioning that it also has impressive features, an evolving interface, and a Pro plan priced at $15/month—which lands it right between Trae and Cursor. If you’re IDE-hopping, Windsurf’s definitely worth a test drive.
And then came Trae.ai—a little later to the party, but showing up with energy, features, and a killer free tier.
Trae surprised us: it offers a clean builder interface, responsive AI, and just enough smart features to actually improve productivity (without needing to read a white paper first).
We chose Trae.ai in the end. Why?
- The free version is shockingly capable
- The Pro tier is significantly cheaper than Cursor
- And honestly, it just fits. Good UX, great AI, low price—perfect jeans.
🧠 Final Thought: The AI Editor Era Is Here
AI isn’t just an assistant anymore—it’s becoming part of the development experience. Not in a “take your job” kind of way, but in a “hey, I already wrote that test function” kind of way. The rise of AI-first IDEs like Cursor, Windsurf, and Trae marks a bigger shift in how we write, debug, and ship code.
At the end of the day, pick the IDE that feels right. The one that gets out of your way when you’re in flow, and politely nags when you’re about to ship something dumb. And maybe, just maybe, one that can write that “Forgot Password” email for you.
Because if your IDE can do all that and still feel like your favorite jeans?
You’ve already won.
🧰 DevOps Platform: GitLab
We chose GitLab because… we already paid for it. Sunk cost DevOps at its finest.
Current Setup
We’re currently on GitLab Premium, thanks to a limited-time deal that got us a full year at $19/month. A steal, honestly. But we know that price tag’s creeping up to $29 soon—and let’s just say, when that day comes and we still haven’t made a dime off this app experiment, you might hear faint cries of “Abandon ship!” from our command line.
For now though, everything’s smooth. Our CI/CD pipeline, container registry, issue tracking, and project planning all live there. We can write .gitlab-ci.yml files on instinct at this point—like muscle memory… or survival instinct.
Why We Originally Chose GitLab
When we first shopped around, we didn’t want to cobble together a DevOps Frankenstack. We wanted something cohesive—one platform that did it all. GitLab gave us CI/CD, project management, security tools, registries, the whole burrito. No plugins, no duct tape, no YAML summoning circles.
The self-hosting option was a nice “break glass in case of cloud apocalypse” bonus. GitLab CE meant we could always bail out and roll our own server, no corporate lifeboat required.
And yes, we already knew GitLab. That CI/CD syntax is practically encoded in our DNA by now. Leaning into it just made sense—like sticking with your favorite coffee shop because they already know your order.
🔧 Our Stack:
- Frontend: Flutter
- Backend: Appwrite
- IDE: Trae.ai
- DevOps: GitLab Premium
Next up: We thought our stack was complete. Frontend? Check. Backend? Covered. DevOps and IDEs? Locked in.
But then something new appeared on the horizon—AI agents. And with them, a mysterious acronym: MCP.
💬 “When I first heard about MCP, I immediately thought of Tron’s Master Control Program—the digital dictator that wanted to absorb all programs into itself. Thankfully, Model Context Protocol is less ‘digital dystopia’ and more ‘really good at making AI tools talk to each other.’ Though I’m still keeping an eye on my toaster, just in case it starts quoting Kevin Flynn.”