Building a personal app with AI: my stack and what I'd keep

I build data platforms by day, but the apps that teach me the most are the ones I build for myself in the evenings. The latest is Mails Manager — a small web app that unifies a pile of email inboxes into one view. I built it with an AI coding assistant sitting beside me the whole way. Here's the stack we landed on, what the AI was genuinely good for, and what I'd absolutely keep next time.

Let me be honest about the starting point: I'm comfortable with Python and data, but I'm not a career web engineer. Deployment, environment variables, secret management, the IMAP plumbing for talking to mailboxes — a fair bit of that was unfamiliar territory. Which is exactly the situation where an AI pair-programmer earns its keep, and also exactly the situation where it can quietly lead you off a cliff. Both happened. Here's the balanced version.

Picking a stack you can actually finish

The most useful thing the AI did early wasn't writing code — it was helping me argue out the stack and then commit to it. For a solo builder, the right stack is the boring one you can ship and maintain alone, not the trendiest one. We settled on a deliberately small set of pieces:

Django for the backend — batteries-included, an admin panel for free, an ORM, sane auth, and a huge body of documentation the AI could lean on accurately.
PostgreSQL for storage — a real relational database from day one, so I'd never have to migrate off a toy.
Railway for hosting — deploy straight from a git push, with managed Postgres and environment variables built in. (Railway is a platform-as-a-service that builds and runs your app from your repo; see their docs.)
A plain server-rendered front end — Django templates with a little CSS, no SPA build step to babysit.

None of this is exotic, and that's the point. Every piece had two things going for it: a low operational burden for one person, and enough public documentation that the AI's suggestions were usually grounded rather than hallucinated. When I asked it to scaffold a model or wire up a view, it was working in well-trodden territory, so its output needed editing rather than rescuing.

The whole app: browser → Django → Postgres, deployed on Railway. The AI sat alongside the build — it never sat in the request path.

Where the AI genuinely accelerated me

Scaffolding was the obvious win. Models, migrations, a first set of views and templates — the kind of typing that's necessary but not interesting — came together in an afternoon instead of a weekend. But the bigger value was getting unstuck on the unfamiliar. Configuring environment variables on Railway, understanding why a secret belongs in the platform and never in the repo, working out how to connect to a mailbox with an application password rather than a real account password — these were the moments where I'd normally lose hours to scattered forum threads. Asking targeted questions and getting an explanation I could verify was a real speed-up.

The AI was at its best as a tutor I could interrogate, not as an oracle I could obey. The moment I treated its output as finished rather than as a first draft, I got bitten.

It was also a good rubber duck. Talking through a design decision — "should encrypted credentials live in the same table or a separate one?" — and getting a reasoned answer back kept my momentum up on evenings when I'd otherwise have stalled. Momentum, for a side project, is most of the battle.

What I still had to own

Here's the part the hype skips. The AI accelerated the typing; it did not take over the thinking. Several decisions were mine to make and mine to be accountable for:

Architecture. What the data model should be, where boundaries sat, what stayed simple on purpose — that's judgement, and judgement doesn't outsource cleanly.
Security decisions. Encrypting stored mailbox credentials at rest, never touching a user's primary password, keeping secrets out of the codebase — I had to decide these were non-negotiable and then check they were actually true in the code, not just asserted in a chat reply.
Reviewing everything. I read every generated line before it shipped. Not because the AI was usually wrong, but because "usually right" is exactly the failure mode that lulls you.

The pitfalls — said plainly

Two traps caught me, and I suspect they catch most solo builders working this way.

Over-trusting generated configuration. Application code gets reviewed because it's obviously yours. Config — Dockerfiles, deploy settings, the small YAML and env scaffolding — slips through because it "looks like boilerplate." That's precisely where a confidently generated but slightly wrong setting can sit unnoticed until it bites in production. I started reviewing config with the same suspicion I give code.

Secrets hygiene. The most dangerous suggestion an assistant can make is the convenient one: drop the key inline, hardcode it just to test. It's tempting because it works immediately. The discipline is to push every secret into Railway's environment variables from the very first commit, so a credential never lands in git history — because once it's in history, it's effectively public. (Application passwords help here too: they're scoped and revocable, so a leak is contained rather than catastrophic.)

If you take one thing from this Treat generated config and anything touching secrets with more suspicion than generated application code — not less. It's the stuff that looks boring, gets skimmed, and fails in production. Review it line by line, and keep every secret in your host's environment variables, never in the repo.

The build workflow that worked

Stripped down, the loop I kept returning to looked like this:

Decide the slice. Pick one small, shippable capability — "connect one mailbox and list its mail" — before touching the keyboard.
Let the AI scaffold it. Have it draft the model, view and template for that slice, with me steering the shape.
Review every line. Read it as if a junior engineer wrote it — especially the config and anything near a secret.
Run it locally, then push. Verify on my machine, commit, and let Railway build and deploy from the git push.
Check it live and repeat. Confirm the slice works on the deployed app, then start the next one.

A deploy, in practice, was about as ceremonious as this:

# a connected mailbox is just a Django model —
# the credential is encrypted before it's ever stored
class Mailbox(models.Model):
    address  = models.EmailField()
    app_pass = EncryptedField()   # never plaintext, never in git

# secrets come from the environment, not the code:
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]
DATABASES  = {"default": dj_database_url.config()}

# then shipping is one push — Railway builds & deploys:
$ git push        # → build → release → live

The shape that mattered most: a tiny unit of work, scaffolded fast, reviewed slowly, shipped immediately. Fast where speed is cheap, slow where mistakes are expensive.

What I'd keep next time

Plenty. The Django + Postgres + Railway combination is genuinely good for a solo builder — cheap, quick to deploy from a git push, managed database, and few moving parts to maintain alone. I'd reach for it again without hesitating. I'd keep the AI as a momentum engine too: for scaffolding, for explaining unfamiliar ground, and as a tireless rubber duck on quiet evenings.

What I'd keep most deliberately, though, is the rigour. Review every line. Be most suspicious of the config and the secrets, not the application logic. Own the architecture and the security calls yourself, because those are the parts that fail loudly and the parts an assistant can't be accountable for. Mails Manager is live, open source, and running on Railway today — not because the AI built it, but because I let it move me fast on the cheap parts while I stayed slow and careful on the expensive ones. That's the balance I'd recommend to any solo builder.