CTO as a Service

The cost of a technical leadership gap is not bad code. Bad code is expensive but reversible; the real cost sits in decisions nobody recognised as decisions at the time and cannot be undone later. Which country the data sits in. Whose name the cloud account was opened under. None reach an agenda under the heading "decision", most pass quietly inside a sprint, and two years later they determine what the company can do. The work here is not writing code but getting in front of those decisions: separating the irreversible ones, writing them down with the reasoning, and leaving the record with you.

Role definition and fit criteria

It means making, justifying and recording technical decisions without employing a full-time technical executive. The boundary is drawn at the start: we do not become an officer with signing authority, nor the legal manager of your engineers. There is a threshold beyond which a full-time CTO is right: once a new question touching architecture arrives every week, an outside role cannot keep up. This service is built for companies where decisions arrive in bursts, with implementation and measurement between them. One observation from the work itself: in the Tegoly, Finteo and Terazzi engagements the advisory side never ran on its own. Each of them also delivered changes to the running product, from new screens and modules to backend and performance work. Advisory here is not detached from execution.

What the work covers

The six headings below cover everything inside an engagement. The first two are the ground: where the system stands today, and decisions recorded with their reasoning. The next two are choices: which technology and vendor, and who joins the team. The fifth inventories accumulated debt; the sixth translates it into language an investor or board can read.

Technical due diligence and current-state assessment

The assessment starts from the running system, not a document: first it checks whether the project comes up from scratch on a clean machine, since a setup that only runs on a handful of laptops is effectively unproven. From there it looks at whose name the repository, cloud, domain, DNS, app store and payment provider accounts are opened under, along with how code reaches production, who can push it, and whether the rollback step is written down. Asking whether backups are taken is not enough; has a restore ever been attempted, because an untested backup is unproven. It also checks whether secrets sit in the repository, which runtime has lost support, and which part can only be touched by one person. The output is a written list ordered by cost and impact.

Architecture decision records and justification

Every decision fits on one page: the question answered, the options considered, the path chosen, the reasoning, and the condition that would justify reopening it. That last item is most often skipped, and without it a decision hardens into a habit nobody argues with. The real test of a record comes a year later, when somebody asks whether a behaviour was deliberate. That is the intent debt we covered in our article on knowledge debt: the reason behind a decision never being written down. The code may be clean and the tests may pass, and the team still cannot tell which behaviours were chosen and which were accidental. AI-generated code accelerates this, because the tool that produced the suggestion does not record its reasoning for you.

Technology selection and vendor evaluation

The question in a selection is not "which technology is best" but "what does being wrong cost". Three criteria settle it: who maintains it after handover, whether you can hire for it in your market, and whether hosting can stay in your own accounts. On a system that already works, the default answer is not to change it, because the case for risking something that already runs, just for an alternative that looks better on paper, is usually weak. None of the Tegoly, Finteo and Terazzi engagements replaced a working technology: on Tegoly the work stayed on the MSSQL and Azure setup already in place, and the Finteo and Terazzi work ran on the platforms those companies already had. On the vendor side the measure is not a reference list but the shape of the handover and who owns the accounts.

Team building and engineer evaluation

The first engineers do not only write code; they set the company's technology choices and the bar for every later interview. That is why early hires are made against the decisions of the next twelve months, not an org chart imagined three years out. The conclusion of our article on being a junior developer in the AI era is this: to get value out of AI you have to know what to ask, and have enough technical grounding to judge whether the answer is correct. So the interview question is no longer "write this function" but "here is a generated change, what is wrong with it and why". We sit in the technical part of the interview and write the evaluation criteria; the hiring decision is yours.

Technical debt inventory and prioritisation

The inventory separates three kinds of debt, because each closes by different work. Technical debt lives in the codebase and closes by changing code. Knowledge debt is the gap in understanding between the codebase and the people responsible for it, and closes only through knowledge transfer; rewriting the code often makes it larger. Intent debt is the reasoning behind a decision going unrecorded, and closes by writing. Each item then goes into one of three boxes: what must change before growth, what can live as it is, and what will never be touched because the assumption behind it is gone. Each item carries the cost of leaving it and of fixing it, so the ordering is set commercially rather than technically.

Investor and board communication

The question a board asks is never which framework was used. It is what the risk is, what it costs, and when it comes due. We write a summary converting the technical state into three columns. In a funding round the other side's technical review asks for the same list: account and domain ownership, whether the open-source licences in use fit your product, which country the data sits in and where that leaves you under KVKK and GDPR, past security incidents, and areas of knowledge resting with a single person. These items are not assembled when the round opens; they are ready beforehand. We do not write a figure we cannot verify on your behalf, and we do not sign the review as an officer.

Which decisions cannot be reversed

Sorting decisions by reversibility is the most practical tool in this work. Long meetings usually go to the reversible ones: the UI library, the CI tool, the code style, most library choices, the hosting provider, and while these can be painful they can still be undone. The ones that cannot be undone tend to pass in silence instead, and five of them stand out. First, whether user identity and customer data separation sit in the data model or in application code. Second, where the data sits, because moving it is not only a technical job, it reopens customer contracts. Third, account ownership: if the cloud, domain and repository accounts were opened in the vendor's name, getting them back is a legal process, not a technical one. Fourth, how the payment provider and the refund, subscription and invoicing logic are embedded into the data. Fifth, the first API contract you publish outside, because every customer that integrates locks it in place. These five require written justification before the decision; the rest do not, otherwise the process becomes a burden of its own.

Agency or vendor evaluation criteria

We write this as an agency ourselves, so the list has to apply to us, and six questions are enough to test it. Does the repository sit in your account with its full history, or does the handover arrive as a compressed folder, leaving who changed what and when unreadable? Whose name are the cloud, domain, DNS and app store accounts opened under, and if you parted ways today, which password would you lack? Does the project come up from scratch outside the vendor's machine? Is the reasoning behind decisions written down, or does it live in a few people's memory? Has the vendor built a closed layer that cannot be carried elsewhere? What unit is a change request priced in, and how does the invoice move when scope grows? An engagement that cannot answer all six ties you to that vendor regardless of the quality of the work.

The exit: you becoming independent

The measure of success here is not the engagement being renewed but it becoming unnecessary. The exit happens one of three ways: you hire your own technical executive, a senior engineer on the team takes the role, or the flow of decisions slows and no continuing role is needed. All three receive the same handover package: the full decision record, the current-state assessment, the three-box technical debt inventory, the account and access list with owners named, and the vendor evaluation notes. What we avoid is becoming the single point of knowledge: decisions live where your team can read them, not in our heads or a message history. We do not hold your accounts in our name and we do not leave a closed layer behind. Without those two rules an exit stops being a handover and becomes a migration project.

How decision authority is divided

The work starts with the current-state assessment, which is priced separately and can be handed to your own team. After that it runs off an open decision list: every item has an owner, a date opened and a status; closed items move into the decision record. What belongs to us is the technical recommendation, always written with a named alternative and the cost of both. What belongs to you is the budget, hiring, vendor selection, the timing of a release, and legal responsibility. We also say when the service is not needed: with a single product, a single team and a settled system whose decisions are made, the work required is maintenance rather than advisory. When the problem is load rather than decisions the work moves to Backend Scaling, and when it is an unvalidated product idea it moves to MVP Development.

How this worked across three cases

The three engagements below are where this work was done; each has its own page in the Success Stories section, checkable from outside.

• Tegoly: A digital signature and business process platform for the global market. On a system already functioning, the work covered new user screens and modules, digital signature and document management integrations, caching mechanisms, server configuration on Azure, MSSQL and Azure security layers, and technical SEO.
• Finteo: A fintech and digital payment platform. The headline change happened on the frontend: the entire interface was redesigned, customer panel improvements, forms and new screens were added, and content strategy plus technical SEO applied.
• Terazzi: The web platform of a construction and decoration brand. Design problems were resolved, customer panel improvements and new screens delivered, backend and performance optimisation done, and content strategies applied for search visibility.