How to choose a tech stack for a side project

The best side-project stack is not the one with the cleanest benchmark or the busiest Discord. It is the one you can still explain six months after the exciting part is over.

Most side projects do not fail because the database stopped scaling. They fail because every small change requires reopening five tabs of documentation and remembering why a preview environment has its own queue.

I choose the boring parts first.

Start with the project’s awkward constraint

Do not begin with a framework. Begin with the thing the project cannot fake.

Examples:

• A collaborative editor needs real-time coordination.
• A desktop scanner needs filesystem access and offline storage.
• A content site needs excellent static output and an easy publishing path.
• A webhook service needs reliable background work and idempotency.
• A video product needs storage, processing, and delivery economics that dominate everything else.

Write the constraint in one sentence. If the stack decision does not improve that sentence, it is probably preference dressed as architecture.

For SiteCMD, local filesystem access, local data, and a desktop experience are not optional details. That naturally points toward a desktop shell and an embedded database. The marketing site has a different job, so it uses a static-first web stack. One product can have two correct answers because the constraints are different.

Familiarity buys more than speed

Using a language you know does not only make the first feature faster. It makes debugging, upgrades, testing, deployment, and the dull Tuesday maintenance cheaper.

Count the whole toolchain:

• Language and type system
• Package manager
• Test runner
• Database and migration tooling
• Hosting and logs
• Authentication model
• Background jobs
• Local development setup

Learning one new piece can be the point of a side project. Learning seven pieces usually turns the product into a course syllabus.

My rule: take one deliberate learning bet. Keep the rest familiar enough to tell whether the new thing is helping.

Pick the deployment shape early

“Where will this run?” removes more options than a feature comparison.

A useful first pass:

Free tiers change. Product names change. A design based on “this host is free forever” is not architecture.

Estimate the quiet-month cost and the successful-month cost. Include databases, logs, email, object storage, bandwidth, preview environments, and the human time needed to understand a failed deploy. The cheapest line item can produce the most expensive afternoon.

Use the database that matches the ownership model

“Always use Postgres” is attractive advice because it ends the debate. It is also wrong often enough to be expensive.

Use an embedded database such as SQLite when one process or one device owns the data, offline behavior matters, and deployment simplicity is a feature. Use a managed relational database when multiple application instances need concurrent shared state, server-side backups, and remote access.

Ask:

• Is the data local to one user or shared by many users?
• Do writes come from one process or several regions?
• What consistency does the product actually require?
• Who owns backups and restoration?
• Can the application move data later without breaking trust?

The schema matters more than the logo. Foreign keys, migrations, backups, and a tested restore path will outlive this month’s database discourse.

Keep authentication boring and authorization explicit

Do not copy a passwordless tutorial and assume authentication is solved. Use a maintained framework or provider that fits the deployment model, then read how it handles sessions, cookies, recovery, revocation, and account linking.

The OWASP Authentication Cheat Sheet is a better evaluation list than a provider comparison page.

Authentication still does not answer authorization. Every protected resource needs a rule for why this user may read, edit, delete, export, or share this specific record. The AI-generated code audit covers the mistake because generated routes get this boundary wrong in very ordinary ways.

If the project does not need accounts yet, do not add them for architectural completeness. A private beta protected at the edge may be enough while the product question is still unresolved.

Prefer one operational story

A side project rarely needs separate systems for web requests, scheduled jobs, queues, analytics events, and email on day one.

Every new runtime adds:

• Another deployment path
• Another credential boundary
• Another log search
• Another local-development approximation
• Another failure mode at 2 a.m.

Use one application and one primary data store until a real workload forces separation. A background job can start as a table with explicit states. A scheduled task can call the same application boundary. Split it when independent scaling or failure isolation is worth the coordination cost.

Microservices are not proof that a project is serious. Clear boundaries inside one deployable application are usually more useful.

Check the exit before entering

Every managed service is a trade: it removes work now and creates a dependency later. That can be an excellent trade.

Before choosing one, answer:

• Can I export the data in a documented format?
• Are the important APIs standard or proprietary?
• What happens when I exceed the free allowance?
• Can I run a representative local environment?
• What would a migration interrupt?

You do not need a vendor-neutral abstraction around everything. You need to know which decisions are cheap to reverse and which deserve a second read before launch.

Framework code can usually move. Identity, data, queues, and storage tend to be stickier.

A ten-minute decision sheet

Before installing anything, fill this out:

The one awkward constraint:
Expected first 100 users:
Data ownership: local / shared / both
Runtime shape:
One thing I am intentionally learning:
Parts I already know:
Monthly cost if nobody uses it:
Monthly cost if it works:
Hardest service to replace:
How I build, test, deploy, observe, and restore:

If two stacks still look equal, pick the one you can deploy and debug today. A side project needs a feedback loop more than it needs a theoretically perfect ceiling.

Then treat the first real release like a release. The pre-launch website checklist catches the operational gaps that a green framework build does not.