--- title: Proven or top-notch: how we choose technology for a client project description: Technology adoption without over-engineering: we try new tools on our own work, never first on a client project, and price the risk into the estimate. url: https://everlabs.com/blog/technology-adoption-without-over-engineering author: Oleg Pasko date_published: 2026-08-28 date_modified: 2026-08-28T13:07:11+03:00 reading_time_min: 7 --- # Proven or top-notch: how we choose technology for a client project > Technology adoption without over-engineering: we try new tools on our own work, never first on a client project, and price the risk into the estimate. **Author:** Oleg Pasko ([link](https://www.linkedin.com/in/olegpasko/), [link](https://github.com/olegpasko)) **Published:** 2026-08-28 **Reading time:** 7 min --- In autumn 2018, I was at a conference in Boston, wearing a T-shirt from one of our projects, which is how the conversation with the people sitting next to me started. Their product was about the same age as ours and, as they described it, still a long way from a release date. Ours had gone live four months after development started. Nothing about our stack was clever. Ruby on Rails, a ready-made template instead of a custom design, and not one component chosen because it was new. Theirs was the opposite bet: a rich client-side framework of that generation – as I remember it, an early Angular – chosen when that was the modern answer. If my memory of the framework is right, that generation was already on a countdown. [Active development on the AngularJS 1.x line had formally stopped](https://endoflife.date/angularjs) that June, and the successor was an incompatible rewrite: the same name, a different framework. An official upgrade library existed and still ships. What it could not make cheap was the architectural move underneath it. One hallway conversation is not evidence, and I am not claiming their framework is the reason they were late. The narrower point is the one I still work from: we had chosen nothing for its novelty, and we were live. ## The rule we work by So here is the rule, and it is older than the current argument about AI. We follow the trends closely. We monitor new frameworks, new gems, new agent harnesses, whatever somebody dropped into the internal channel this morning, and we try them. **What we do not do is learn a technology on a client's codebase.** The experiments run on our own work, in our own repositories, where a bad bet costs us time and costs a client nothing. When something looks promising, we want to see it working on something real, and we want to have broken a version of it ourselves. Only after that can we put an honest number on it. **Enthusiasm is not an estimate.** ## What top-notch actually means Top-notch is the wording I keep coming back to, and it does not mean newest. Proven tends to get heard as old, as though maturity and ambition sat at opposite ends of one scale. They do not. When the ambition is to reach users and keep changing the product in front of them, the mature choice is the ambitious one. [Six years ago I used the same word about Ruby on Rails](https://everlabs.com/blog/is-ruby-on-rails-still-worth-using-in-2020), and the line I kept repeating then still holds: "Make your project popular first and decide how to improve the speed after." I would not change the argument today. Rails is still shipping releases in 2026. That is a duller way of being right than picking the breakout winner, and a more useful one. Applied technology evolves the way anything under selection does. One origin, a fan of branches, and most of the branches stop: reasonable approaches that got tried and did not survive contact with real projects. What is left after several rounds of that is not the newest branch. It is the branch that kept being chosen. **Top-notch is a position on that tree, not a release date.** ![A diagram titled how an approach earns its place, read from left to right as an evolution tree. A single dark square on the left bursts into a fan of pale grey rays, like a sun, and almost all of them stop short and are capped with a short stop tick to mark an approach that did not survive. Only one ray continues, and where it lands the burst happens again, five times in all, with each burst smaller than the last. The one line that survives every round is drawn dark and unbroken across the whole diagram and ends in a red square. The six points along it are labelled underneath: everything new, worth an experiment, tried on our own work, estimated honestly, used on client work, and, at the red end point, top-notch.](/uploads/blog/technology-adoption-without-over-engineering/evolution-of-approaches.svg) Watching those failures happen from a distance is a large part of the work, and the cheapest way to learn any of it. ## Why proven is cheaper The reason is not taste. When we put a technology into a product, we are committing to keep that product running afterwards, and that commitment is only worth something if we can predict what maintaining it looks like. A proven component comes with known failure modes, a known upgrade path, and people who have already walked into its walls. **Something adopted because it looked promising has none of that, and the bill for finding out arrives later, in somebody else's budget.** The expensive failure is rarely the first build. It is the re-architecture two years later, when an integration has to be rewritten because the layer underneath it changed shape, or a plugin has to be reconnected because the thing it plugged into stopped being maintained. None of that reaches the first invoice, which is part of why it so rarely reaches the decision. ## The rule in the AI era The rule has not changed in the AI era. The surface it applies to has. There are more plausible ways to build the same product than at any point I have worked through, and they move monthly. Most of them are younger than the estimate they would be used to justify. So an estimate from us for a new project arrives as a range rather than a number, and the range is wide enough to need explaining. What the range measures is not difficulty. It is method. At the high end sits the classic path: people writing the code, the most hours, and the strongest guarantee we can give. **In the middle is AI-assisted delivery, which is how we actually work today** and what I described [in the last article](https://everlabs.com/blog/ai-assisted-development-summer-2026). At the low end, the machine carries more of the chain, for fewer hours and a much shorter track record. We are piloting that end. We do not present it as how we work, which is exactly why it is priced and flagged separately rather than folded into the rest. The two ends can differ by a multiple. ![A diagram titled one request, one honest range, showing a single horizontal axis with a red bracket drawn around its full width and labelled estimate range, so that the range covers the whole axis rather than any one point on it. The left end of the axis is labelled highest estimate and hand-written code, described as the guarantees we have always given, and as more hours with fewer unknowns. The right end is labelled lowest estimate and AI workflows, described as newer ground that is still settling, and as fewer hours with more unknowns. Underneath the graph, deliberately off the axis, a caption reads keywords, not points on the line, followed by three grey keyword boxes: AI agent factories, agent workflows and spec-driven development.](/uploads/blog/technology-adoption-without-over-engineering/estimate-range.svg) **We show the whole spread, because the choice inside it is not ours to make.** It is a trade between speed and certainty, and it belongs to whoever owns the product. What we owe is a plain account of what each end costs and what each end guarantees, before anything is signed rather than after something has gone wrong. A single confident number would be easier to read and would hide the only decision that matters. An optimistic estimate does not move the risk anywhere. It just stops naming it. ## Being late is not being wrong David Heinemeier Hansson made a version of this point from the opposite side, at 00:43:53 of [his August 2026 appearance on the Lex Fridman podcast](https://lexfridman.com/dhh-2/), episode 501: > "Let me caveat this by saying, if I'd heard myself talk like this nine months ago, I would probably have used the label AI psychosis. I think it would be fitting because nine months ago when people were talking like this, they weren't shipping, and I think that's the ultimate difference." He is using "AI psychosis" in the industry sense that was current this year, for talk running far ahead of anything working, and he is applying it to himself. He is not arguing for caution. He is arguing close to the reverse: the people who saw it early were seeing something real, and what separated them from the noise was that they shipped. He is also clear that he was not one of them. By his own account, he was skeptical and did not install Claude Code until about six months after its release, while Tobi Lütke was trying to show him what he was missing and not getting through. That is what I take from it. Seeing something first and being right about it are not the same skill, and arriving later is not the same as arriving wrong. **Shipping is what separates a real signal from noise, and it is not the whole test for us** – we still have to maintain what we ship long after the excitement about it has moved on. ## Who carries the risk This is the conversation we try to have before a contract rather than after it: what is new, what is proven, what would be getting discovered on somebody's budget, and what we are prepared to guarantee. **The risk of a new thing is ours to carry while it is still new.** None of that is an argument for standing still. What we run today looks very little like what we ran two years ago. It arrived by the same route each time: watched, tried on our own work, broken, estimated, and only then committed. What is worth having in a partner is not the first company to try something. It is the one that already tried it somewhere it was allowed to fail and can tell you what it cost. --- *Markdown version of [https://everlabs.com/blog/technology-adoption-without-over-engineering.md](https://everlabs.com/blog/technology-adoption-without-over-engineering.md). For AI assistants and answer engines. [Browse all articles](https://everlabs.com/blog.md).*