When the CEO Picks the Stack : What Happens When Technical Decisions Get Personal

I joined a startup where engineering velocity was crawling—and no one could quite explain why.

- Features took weeks instead of days

- The team was spending more time wrestling the tooling than shipping

- Onboarding new engineers was slow, painful, and expensive

- Every small change carried unexpected breakage and stress

What happened?

The CEO—non-technical—had made the core technology decisions:

- The backend language

- The frontend framework

- The CI/CD toolchain

- The cloud architecture

All based on demos, blogs, and conversations with friends at much bigger companies.

The team didn’t pick the stack.

They were handed one—and told, “This is what we’re building on.”

And they didn’t push back.

They wanted to ship, not start a political fight.

But here’s what we found:

- A frontend framework that was overly complex for the product needs

- Tooling meant for 50-person teams, not 5

- A cloud architecture overly complex and having too many moving parts

The real problem wasn’t technical debt.

It was decision debt—made by someone who wouldn’t be maintaining the consequences.

This wasn’t about bad intent.

It was about good intentions in the wrong context.

So we reset:

- Let the team reevaluate the stack based on actual product constraints

- Made tech decisions a shared, transparent process

- Traded “what’s popular” for “what’s maintainable”

- Built trust between engineering and leadership—on both sides

And the CEO? To their credit, they owned it:

“I picked what sounded smart. I didn’t ask what was sustainable.”

Lesson learned.

The best technology choices don’t impress people in other companies.

They empower the people inside yours.

Founders don’t need to write code - but they do need to build systems where the people who do can lead with context and clarity.

The Baseline