Engineering at the point of impact.

Less than you would expect, because the handover document exists from day one rather than day last, and because it is updated weekly against real work rather than written in a rush at the end. Architecture decision records live in your repository. Runbooks are written from actual incidents during hypercare, not imagined ones. The last two weeks of any engagement are your engineers shipping changes while ours watch.

The blunter answer: if an FDE leaving breaks the system, we built it wrong. That is a defect in our delivery, not a reason to keep paying us, and we would rather find it in week 13 than in year two.

Your team, or us under a Run agreement, and you should decide which before the build starts rather than after. This is the question we disqualify people on more than any other — if there is no team, no budget line and no on-call rotation eighteen months out, owned software is the wrong answer and a licence is the right one.

The concrete version: an application from Techtons typically needs a fraction of one engineer to keep current — dependency upgrades, framework major versions, cloud deprecations. Not zero. If your organisation cannot find that, keep renting, and we will tell you so in the assessment.

It is the same question, with two of its inputs changed. Build used to mean starting from an empty repository with an unknown estimate. Techtons entries are working reference implementations with the architecture, the infrastructure code and a published build estimate attached, so the starting point is week four of a traditional project rather than week zero. And AI-assisted engineering has genuinely moved the cost of the middle 60 percent of an application.

What has not changed is the arithmetic on the other side. Below roughly 150 seats, per-seat pricing still wins. Where the vendor attestation is the product, buying still wins. We publish those cases on every page because the honest version of this argument is a narrower one than the marketing version.

Four things, none of them magic. We start from a reference implementation that already exists and already deploys, rather than from nothing. We define parity in week 2 and refuse to widen it, which removes the single largest source of schedule loss. Our engineers work with AI across the whole cycle — specification, code, tests, migration tooling, documentation — and we have rebuilt the delivery process around that rather than bolting an assistant onto the old one.

And we build a narrower thing. A commercial product must serve every customer; yours has to serve you. Most of what you are paying for in a licensed product is configurability you will never use, and not building it is a large part of the speed.

Phases are fixed price, agreed before the phase starts. If a phase overruns because we estimated it badly, that is ours and we absorb it. If it overruns because the scope changed, we stop, price the change, and you decide — we do not quietly consume the contingency and tell you in week seven.

The structural protection matters more than the commercial one. The migration dry run sits in week 6, before you have committed to a cutover date, precisely because data is where estimates fail. If the dry run says the migration is a month rather than a week, you learn that with the incumbent still running and a decision still open.

You own the delivered code outright — everything written for your engagement, in your repository, from the first commit. Not a licence to use it, not a joint ownership arrangement, not an escrow. There is no clause that lets us take it back and nothing you need to keep paying to retain the right to run.

The Techtons reference implementations we start from are published under Apache-2.0 on GitHub and stay that way. That means the base is permissively licensed for you and for everyone else, including your competitors. If work we do for you improves a reference implementation in a way that is generic — a better migration pattern, not your business logic — we will ask before contributing it upstream, and no client-specific code goes into Techtons.

Our engineers work under your access model, on your accounts, with your logging watching them. We do not take copies of production data to our own infrastructure; migration tooling runs in your cloud account and the extracts stay there. Named individuals, background checked, with access provisioned through your identity provider and removed by your leaver process, not ours.

On the systems themselves: threat model, secure pipeline controls, dependency and secrets scanning, independent penetration testing before go-live where the system warrants it. And the honest part — moving a system in-house transfers the control obligation from a vendor attestation to you. We cost that explicitly in the assessment rather than leaving it as a surprise for your auditor.

Yes. There is a conversion fee, it is written into the contract before you start, and it scales down the longer the engagement has run — after twelve months it is nominal. We would far rather you hire the engineer than lose you as a client, and an engineer who wants to take the role is an engineer we were going to lose anyway.

We also do not block it, discourage it in the room, or treat it as a breach. An engagement model that depends on preventing your best relationships from becoming permanent ones is a model we do not want to defend.