undo
Go Beyond the Code
arrow_forward_ios

Nota de prueba

Ensolvers
Blog Edition
April 6, 2026
To learn more about this topic, click here.
Engineering & Partnerships 6 min read

The question every CTO asks when hiring a software partner. And the one they should.

Every CTO we talk to asks us the same questions upfront. AWS or GCP? React or Vue? Do you know Kubernetes?

Every time we start a conversation with a new client, the first questions are almost always the same.
Do you work with AWS? Do you use React? Do you know Kubernetes?

Fair questions. Not the most important ones.

The most important questions — the ones that actually determine whether an engagement succeeds or quietly falls apart six months in — almost never get asked in the evaluation phase. They show up later, when it's expensive to find out the answers.

Technology is slow to change. Practices aren't.

There's a well-known principle in software engineering: choose boring technology. The argument is simple — established technology has known failure modes. New technology comes with unknown unknowns nobody has hit yet.

But there's a less discussed corollary that matters more for how you evaluate a software partner.

If a team builds your core system on the wrong database, migrating out is a multi-month project. If they use the wrong deployment process — you change it next sprint.

This asymmetry changes what you should be evaluating. Technology choices are expensive to reverse. Practice choices are not. Which means the practices of the team you hire matter more than the stack they bring.

What "practices" actually means in a software engagement

Technology is anything that needs to keep running to support your business — your codebase, your infrastructure, your data. Practices are how the team operates around that technology. They're invisible in a demo. They show up in production.

Three areas where practices determine the outcome of an engagement more than the stack does:

1
How they handle things going wrong
Any team can build something that works in a demo. The question is what happens at 2am when it doesn't. Is there a runbook? Who gets paged? How long does it take to diagnose? How does the incident get documented so it doesn't happen again? These aren't exciting questions to ask in a vendor evaluation. They're the ones that matter most.
2
How they document decisions
Every architecture decision has a reason. If that reason lives only in the head of the engineer who made it, it leaves when they do. Good engineering teams document decisions as they make them, in a way that future engineers can understand and challenge. That practice is worth more than any specific technology choice.
3
How they transfer knowledge
An engagement ends. The external team moves on. And suddenly nobody on the internal team knows why the system works the way it does, or how to extend it safely, or where the sharp edges are. Knowledge transfer isn't a final deliverable — it's a practice that has to run throughout the engagement, not just in the last two weeks.

The question that actually tells you what you need to know

Most vendor evaluations spend 80% of the time on technology — stack, certifications, tooling. That's not wrong. But it's incomplete.

The question worth asking

"How do you operate around the technology you build?"

Ask how they've handled a production incident on a previous engagement. Ask how they document architecture decisions and who has access to that documentation. Ask what a knowledge transfer looks like in practice, not on a slide.

The answers to those questions tell you whether you're talking to a vendor or a partner. Technology is table stakes. Practices are the differentiator.


Sources
1. McKinley, Dan. Choose Boring Technology. mcfunley.com. mcfunley.com/choose-boring-technology
2. Wayne, Hillel. Choose Boring Technology and Innovative Practices. buttondown.com, March 2026. buttondown.com/hillelwayne
Work with us
We build software that survives the engagement ending.
Documentation, knowledge transfer, and operational practices are part of every engagement we run — not a final deliverable. If that's the kind of partner you're looking for, let's talk.
See how we work expand_circle_right
Ensolvers
Blog Edition

Start Your Digital Journey Now!

Which capabilities are you interested in?
You may select more than one.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.