Three Principles That Simplified My Tech Decisions

You know that feeling when you’re starting a new project and spend 3 hours debating Next.js vs Remix vs SvelteKit vs Astro… only to end up more confused than when you started?

Yeah, I’ve been there. Way too many times.

Early in my career, I’d lose entire days comparing framework benchmarks, reading Reddit arguments, and second-guessing every tech choice. It was exhausting and honestly, kind of stupid.

After building enough projects (and making enough mistakes), I finally figured out what actually matters. Here are the three principles that keep me sane:

1. Boring Beats Clever, Every Time

Last year on a client project, I had to choose between:

  • The shiny new meta-framework everyone’s hyping on Twitter
  • The “boring” stack the team already knew

I picked boring. And when we had to onboard two devs mid-project and push urgent fixes? That boring choice saved our asses.

Nobody gives you points for clever code. They give you points for code that works and doesn’t confuse people.

Use the cool new tech if it actually solves a problem. But if you’re just using it to flex? You’re setting yourself up for pain later.

2. Match Your Tech to Your Timeline

Not every project needs to be bulletproof. Some things are meant to die in 3 months.

I used to build every project like it was going to be maintained for 10 years. Full TypeScript, comprehensive test suites, the works. Even for throwaway marketing sites.

Now I actually think about how long something needs to last:

  • Quick demo? Plain HTML/CSS is fine
  • Campaign landing page? Keep it simple, ship it fast
  • Core product? Yeah, now we can talk about proper architecture

Stop over-engineering things that don’t need it. Your 2-week marketing site doesn’t need the same infrastructure as your SaaS app.

3. Start Simple, Add Complexity When It Hurts

Here’s my rule: start with the simplest thing that could possibly work, then only add stuff when you actually need it.

This site? Started as basic HTML and CSS. Then I added Astro when managing blog posts got annoying. Image optimization came later when load times sucked.

You know what I didn’t add?

  • A full CMS (don’t need it)
  • Complex state management (it’s a static site)
  • A heavy JS framework (why?)

Solve real problems, not imaginary future ones. You’ll know when you need something because it’ll start hurting. Until then, keep it simple.

Final Thoughts

Following these principles has made my life so much easier. Less decision fatigue, faster shipping, and way less regret six months down the line.

The best tech stack isn’t the newest or the coolest. It’s the one that gets you shipping without wanting to throw your laptop out the window.

Now go build something.