A technology is infrastructure for a decision or an operation, never the protagonist of the story — it's worth adopting when it changes what an organisation can decide or do, not because it's new. Therefore, the first question isn't "what's the best tool for this," it's "what's actually true about the constraint this needs to solve."

We're comfortable being unimpressed by a technology until it's proven itself in production, under real constraints, with real consequences for being wrong. Therefore, a technology earns adoption by surviving contact with an actual engagement, not by a strong demo or a compelling launch post.

Code and infrastructure are written for the engineer who inherits them, not for the engineer who wrote them — so a technology choice is judged partly by what it costs the client's own team to keep running after we've left, not only by what it costs us to build with today.

Therefore, the well-understood option a client's team can actually own beats the newer one only we know how to run, even when the newer option is measurably faster to build with in the moment. If a client's own team can't extend what we built without calling us, we haven't finished the job — we've created a dependency and called it a delivery.

Technology decisions aren't a separate category of judgement — they're Engineering Principles applied to tooling. Simplicity over complexity means fewer moving parts and fewer dependencies to reason about, not a smaller feature list. Evidence over assumptions means a technology is judged on what it's actually done in production, not on what it promises to do.

Documentation as part of delivery means the stack itself gets a decision record like anything else — why a given technology was chosen, what alternative was ruled out, and what would have to be true for that decision to be revisited. A stack with no rationale behind it is no more finished than a system with no decision record behind it.

In practice, that discipline has settled on a small, consistent set: TypeScript and Node.js for the languages and runtime most engagements build on, React and Next.js for the interfaces client teams actually use, and Python where an engagement's work is closer to automation or data than to a product surface.

For infrastructure, AWS and Cloudflare are the cloud providers we default to, provisioned through Terraform and deployed through GitHub Actions rather than manual changes made directly against a console. Some engagements extend into a client's own existing environment rather than replacing it — one prior engagement involved integrating with an already-established Azure footprint rather than migrating away from it.

A technology decision isn't permanent because it was right once — it's revisited the same way any other consequential decision is: against the condition that was named at the time it was made, not against whatever happened to launch since. Therefore, a choice gets reopened only when a documented constraint that justified it has actually changed, not because something newer became available.

When that happens, the reconsideration gets the same decision record as the original choice: the reason the original decision was made, the reason it no longer holds, and who's accountable for the new one. Nothing about a technology decision entitles it to less scrutiny than any other decision made on an engagement — it's held to exactly the same standard.