How I Choose Technology for Client Projects (And When I Say No)

One of the biggest fears founders have isn’t development speed.
It’s making the wrong technical decision early and paying for it later.

This article explains how I choose technology for client projects — and just as importantly, when I deliberately say no.

Not because I can’t build something, but because I’m protecting the product.

---

Why “Latest Tech” Is Often a Mistake

New tools are exciting.
But excitement is not a business requirement.

In real projects, choosing the latest framework often leads to:

• Smaller talent pool
• Immature ecosystems
• Unexpected edge cases
• Higher maintenance cost
• Slower onboarding for future developers

That doesn’t mean new tech is bad — it means context matters.

Technology should reduce risk, not introduce it.

---

How Project Stage Affects Tech Choice

I don’t choose tech in isolation.
I choose it based on where the product is right now.

Early-stage / MVP

• Speed matters
• Clarity matters
• Simplicity wins
• Proven tools are safer

Growth-stage

• Performance starts to matter
• Structure and scalability matter
• Observability and maintainability matter

Scale-stage

• Cost efficiency matters
• Operational complexity matters
• Team velocity matters more than novelty

The same tech stack is rarely ideal for every stage.

---

When Next.js Is the Right Choice (And When It’s Not)

I use Next.js often — but not blindly.

Next.js works best when:

• SEO is important
• You need server + client flexibility
• You want a single unified web platform
• You’re building a long-term product

I avoid or reconsider Next.js when:

• The app is purely internal
• SEO has zero value
• The product is a short-lived experiment
• The complexity outweighs the benefits

No framework is “always correct.”

---

When I Reject Client Requests

This is where trust matters.

I push back when:

• A tool is chosen only because it’s trending
• A stack adds complexity without real benefit
• A request increases long-term cost for short-term gain
• A decision will make hiring or scaling harder later

Saying “yes” to everything is easy.
Saying “no” when it matters is what protects the product.

---

Long-Term Cost vs Short-Term Speed

Fast delivery is important.
But fast mistakes are expensive.

Every tech decision has hidden costs:

• Maintenance
• Hiring
• Infrastructure
• Refactoring
• Onboarding

My goal is to balance:

• Shipping quickly now
• Staying flexible later

That balance is where good products survive.

---

The Result of This Approach

This way of working leads to:

• Fewer rewrites
• Lower long-term cost
• Easier team scaling
• More predictable delivery
• Stronger trust with founders

It also filters out projects that aren’t ready to be built properly — which is intentional.

---

Final Thoughts

I don’t build projects to show off tools.
I build them to last.

Technology is a means, not an identity.

If you want a partner who:

• Questions assumptions
• Chooses tools responsibly
• Pushes back when needed
• Thinks beyond the first release

Then this is how I work.

---

---

Related Reading

• Why I Prefer Boring Architecture for SaaS — the philosophy behind keeping stacks predictable
• How I Take a SaaS Idea From Concept to Production — how these decisions unfold across a real build
• When a Founder Needs a Technical Partner — the fuller picture of what technical judgment looks like
• How Much Should a SaaS MVP Cost in 2026? — how technology choices directly affect budget

---

Call to Action

If you want someone who chooses technology with your business in mind, let’s talk.
Good decisions early save years later.