Choose technology your team is allowed to leave

Every technology choice is a promise to stay for a while. A framework, a database, a push-notification vendor, an authentication service: each one saves time now and charges rent later. The rent is fine when you chose it with your eyes open. It is expensive when the choice was a default nobody is allowed to question.

The useful question is not “what is the best tool?” The useful question is “if we need to leave in three years, what breaks?” Teams that can answer that question pick better tools, and they pick them more calmly.

Keep the product’s rules in your own code

Vendors are good at a job: sending email, storing files, checking a password, hosting a function. They are bad places to store the meaning of your product. “A project is overdue when the last invoice is unpaid and the contract is active” should live in your code, where you can test it. It should not live in a workflow builder that only one person can edit, or in a query spread across three dashboards.

When the rule is yours, the vendor is a replaceable edge. You can swap the email provider without redefining an invoice. You can move hosts. You can rewrite a screen. The center stays. This is also how a web application and a mobile application stay in agreement, which is the subject of the application you can still change in year three.

Prefer boring where you are not different

Most of an application is not the reason a customer stays. Login, lists, forms, permissions, background jobs, file uploads: these should be dull. Dull means a widely used tool, a common shape, and a hire who has seen it before. Novelty there is a tax on every future teammate.

Spend the unusual technology on the part that is actually the product. If you are not sure which part that is, you are not ready to adopt something exotic. Wait. A boring stack that ships is more scalable than a clever stack that only the original pair of developers can operate.

Demand an exit before you enter

Before you adopt a platform, answer four practical questions.

• Can you export the data, in a format another system can read, without a support ticket and a week of waiting?
• Can you run the important path somewhere else, even if the replacement is clumsier?
• Are the integration points standard, or are they a private dialect?
• What happens to the product if the vendor doubles the price or shuts the feature down?

If the answers are embarrassing, the tool can still be right, but the decision should name the risk. “We accept that leaving will be a rewrite” is a legitimate sentence. “We did not think about leaving” is how teams get stuck.

Leaving should be a project, not a fantasy. If you cannot sketch the project, you do not have an exit.

Authentication is a common trap. It is reasonable to buy it. It is not reasonable to let that vendor’s user identifier become the only key in every table, with no stable id of your own. Give your records an identity you control. Store the vendor’s id beside it. The day you move, you map one column instead of the whole database.

Write the reason where the next person will find it

A choice without a reason will be relitigated every time someone new joins, or it will be treated as sacred. Both are a waste. A short note is enough: what you picked, what you rejected, and what would make you revisit it. Put it next to the code or in the repository’s decision log. Chat history is not a log.

Revisit the note when the trigger you named actually happens. A new version, a price change, a second team, a compliance requirement. Do not reopen every choice in every planning meeting. Do not ignore the trigger either. Technology you are allowed to leave is technology you are also allowed to keep, on purpose.

Add new tools slowly

A team can absorb a new platform occasionally. It cannot absorb one per quarter and still remember how the system works. When a tool arrives, name an owner, a rollback, and the old path you will delete. Two ways to do the same job is how year three becomes archaeology.

This applies to AI vendors as much as to databases. A model behind a small interface is a tool. A model called from every screen, with the provider’s types leaking into the domain, is a commitment. The fence in designing AI features people can still answer for is also an exit ramp.

The stack is a means

Clients rarely hire an applications company because of a logo on a diagram. They hire one because the software has to be clean, maintainable, compliant, and scalable after the kickoff slides are gone. The technology serves that. When a tool helps, use it. When it asks you to hand over the rules of the product, decline.

If you are choosing a stack for something you intend to keep, start from the exit and the center you refuse to outsource. The rest is a shorter list than the internet suggests. Send Insight Apps the constraints and we will help you make the list smaller, not longer.