Choosing a Technology Partner You Will Not Regret in Two Years

Business owners rarely regret a technology decision on the day they make it. The regret arrives eighteen months later, when the person who built the system has moved on, nobody can explain how it works, and the quote to change one field is more than the original project.

Most of that is avoidable at the selection stage.

Ask who owns what

Before anything else, get clear answers in writing:

• Who owns the domain name, and in whose account is it registered?
• Who owns the source code, the design files and the content?
• Where is the data hosted, and can you export all of it in a usable format?
• What happens to all of the above if the relationship ends?

A good partner answers these immediately and without discomfort. Hesitation here tells you more than any portfolio.

Look at the handover, not the launch

Anybody can launch a site. Ask to see documentation from a completed project. Ask how a client's own team would make a routine change. Ask what training is included. Systems that only one agency can maintain are not assets; they are subscriptions with extra steps.

Prefer boring, well-supported foundations

There is a real cost to being the only company in your city running an unusual stack. Mainstream frameworks, mainstream cloud providers and mainstream databases mean you can hire, you can get help, and you can replace your vendor without replacing your system.

This is not an argument against new technology. It is an argument for spending your novelty budget on the part of the business that differentiates you, and being conservative everywhere else.

Check that they will say no

The most useful thing a partner does is tell you when a request is a bad idea. A vendor who agrees to everything is either not listening or planning to bill you for the consequences. In a first meeting, describe something you want that is slightly unwise and see what happens.

Questions worth asking directly

• What did you build that did not work out, and what did you learn?
• Who specifically will do the work, and are they employees?
• What does support look like in month six?
• How do you handle a security incident?
• What would make you turn down this project?

Price last

Compare price only after two or three candidates have passed everything above. A proposal that is dramatically cheaper is usually cheaper for a reason: less discovery, less testing, less documentation, or a plan to make it back on change requests.

The goal is not to spend more. It is to know exactly what you are buying, and to still be glad about it in two years.