What a technical partner owns after launch

A technical partner is whoever keeps making decisions about your software once the first version is live. Most writing on the subject is about finding one. This article is about something narrower and more practical: who decides the architecture and the technology choices, who holds the code, the cloud accounts and the documentation, who answers the phone at 2am after launch, what a handover has to contain, and what tends to go wrong when a partner walks away. Four common arrangements are compared on those points: a technical co-founder, a fractional CTO, a vendor that ships and leaves, and a long-term partner. Each one settles ownership differently, and each carries risks that are easy to miss at the start.

The focus here is software products and internal systems that people depend on every day. A marketing site or a throwaway prototype carries a different risk profile, and most of what follows matters less there.

Who owns what once a technical partner is in place

Ownership after launch comes down to who can act. A founder may hold the intellectual property on paper and still be unable to deploy a fix, rotate a leaked key or add a new engineer to the repository. In practice, ownership breaks down into five questions, and each one has a concrete answer that can be checked on any given day.

• Who has the final say on architecture, and who changes it when the business changes?
• Whose organisation the source code lives in, and who can grant or remove access.
• Whose name is on the cloud accounts, the domain, and the services the product depends on.
• Where the documentation lives, and whether someone new could run the system from it.
• Who is expected to respond when production breaks outside office hours.

Those questions can seem administrative until something fails and the person with the answer is unreachable. The rest of this article takes them one at a time, then looks at the four arrangements together.

In production, it is typical for everything is fine for months, because the system is quiet and nobody needs anything. The ownership gap only shows when the first serious incident, the first new hire, or the first change of supplier arrives, and by then the easiest moment to fix it has passed.

Four arrangements, in brief

The labels are loose, and real arrangements often blend them. Still, each has a typical shape.

A technical co-founder is part of the founding team and makes engineering decisions as a member of the leadership. Their incentives are tied to the company and its success over years. Their time and attention are also finite, and much of what they know tends to live in their head.

A fractional CTO is a senior engineer or technology leader who works part-time across a small number of companies. They usually set direction, review decisions and help with hiring. Some write code; many do not, and their value lies more in expertise and judgement. Their involvement rises and falls with the hours agreed.

A vendor that ships and leaves builds to an agreed specification and hands over at acceptance. The relationship is defined by a scope and a date. After that, support is whatever the contract says, which is sometimes very little.

A long-term partner is an outside team that stays with the product across releases, carrying context from one change to the next. The same engineers, or at least the same small group, are involved in the build, the launch and what follows.

The four arrangements trade different things against each other: continuity against flexibility, depth of context against independence, commitment against the freedom to change course.

Who decides the architecture and technology choices

The first version of a product is rarely where architecture decisions hurt. They hurt on the second and third significant change, when the business asks for something the original design did not expect: a second market, a new pricing model, an integration with a partner system, a mobile app alongside the web one, or new platforms the original team never planned for.

With a technical co-founder, architecture is owned fully and adjusts week by week alongside the business. The trade-off is concentration. Decisions are fast, and they are also hard for anyone else to challenge or even see, unless the co-founder writes down why they were made.

A fractional CTO usually sets the initial patterns and guardrails. Because they are not present for every change, the day-to-day choices fall to whoever is writing the code. Over time the real implementation can drift away from the one that was agreed, and the drift is often invisible until someone tries to extend the system.

A vendor that ships and leaves optimises for the specification it signed. That is a reasonable thing to optimise for. It also means decisions that would only pay off later, such as how configuration is separated from code or how a module can be replaced, may not get the attention they need, because nobody on the vendor side will be around to benefit.

A long-term partner shares architectural ownership with the business. The risk here sits on the other side: a partner that has been involved for a long time can become the only party that understands the design, which quietly turns shared ownership into dependence.

Whatever the arrangement, the healthiest sign is the same. Someone close to the code can explain, in a single whiteboard session, why the key decisions were made and what it would take to reverse them. The costly case is architecture nobody can explain, which is the most expensive kind to change because every change then has to begin with archaeology.

Who holds the code

Asking who owns the code is partly a legal question. Contracts need a clear assignment of intellectual property, and that is a matter for a lawyer. The practical question is simpler: whose organisation the repositories sit in, and who has administrator rights.

A technical co-founder usually creates repositories under the company’s own organisation. The common gap is that they are the only administrator, so access depends on one person being available and on good terms.

A fractional CTO often sets up repositories and pipelines early and keeps administrator rights out of convenience. When their hours drop or the engagement ends, those rights need to move deliberately, and that step is easy to forget.

A vendor that ships and leaves sometimes works in its own repositories and delivers the code at the end, occasionally as an archive. What is lost in that transfer is the history: the commits, the reviews, the reasons a line was changed. That history is often the only record of why the code looks the way it does.

A long-term partner can work inside a client-owned organisation from the first day, which keeps history and access with the business. It still needs checking, because partners sometimes keep supporting pieces and tools, such as shared libraries, build scripts or deployment configuration, in places they control.

Code is also more than the application itself. Pipeline definitions, infrastructure scripts, deployment processes, database migration files and seed data are part of what makes a system reproducible. A repository that holds the application but not the scripts that deploy it is only half a handover. What often turns up instead is several folders named some variation of “final”, on one former contractor’s machine, and no reliable way to tell which one is running in production.

Who holds the cloud accounts and the credentials

Infrastructure is harder to move than code, because it is tied to accounts, billing and identity. Whoever holds the top-level account for the hosting provider holds the system in a very direct sense. They can switch it off, change it or lock others out.

A co-founder normally runs infrastructure in company accounts, with themselves as the main owner. The weakness is again concentration in one person.

A fractional CTO may set everything up and then step back. Unless ownership is transferred before their involvement reduces, the business can find that the person managing the highest level of access is no longer around much.

A vendor that ships and leaves sometimes runs a client’s system inside its own cloud account, because it is quicker to start that way. The plan to move it later often stays a plan. Moving a live system between accounts after launch is almost always more disruptive than starting in the right place, because it touches networking, domains, certificates, secrets and data at the same time.

A long-term technology partner for startups can design the structure and run it day to day while billing and the top-level account stay with the business. The point to watch is whether access is personal or tied to roles that can be revoked cleanly when people change.

The hosting account is only one item. Others are easy to forget until one of them expires or stops working:

• the domain registrar and DNS settings;
• keys for payment, email, SMS and other outside services;
• monitoring, logging and error-tracking tools;
• app store developer accounts for any mobile apps;
• the password manager or vault where all of the above are kept.

Typical gaps are a production database sitting in a former supplier’s account, a security certificate that nobody at the client could renew, and an outside service registered to the personal email of someone who had left. Each of these tends to start as a shortcut taken under time pressure that nobody came back to.

Documentation that outlives the people who wrote it

Documentation is what separates a system a competent engineer can safely change from one that only its original author dares to touch. It does not need to be long. It needs to be current and to answer the questions a stranger would ask first.

A workable minimum looks like this:

• an architecture overview with the main components and how they talk to each other;
• a description of each environment, such as development, staging and production, and how they differ;
• notes on the data model, especially anything that is not obvious from the schema;
• a list of outside services with what each one does and where its credentials live;
• runbooks for the routine and the urgent: how to deploy, how to roll back, how to rotate a key, how to restart a stuck job, what to check first when orders or payments stop.

The four arrangements tend to produce different kinds of documentation, often without anyone planning it. A co-founder keeps much of it in their head, because they are always there to ask. A fractional CTO often writes strategy and decision records and leaves low-level runbooks to whoever builds. A vendor that ships and leaves documents what the contract requires. A long-term partner documents what it needs to work efficiently itself, which may or may not be what a future team needs without it.

The runbook that matters most is the one for rolling back a bad release. It is also the one most often missing, because it is only needed on a bad day and nobody wants to write it on a good one.

Who answers at 2am after launch

The question of who gets the call during an outage is often left vague until the first real incident. Then it gets answered in the worst possible way, by whoever happens to be awake and has access.

A technical co-founder is often on call informally, around the clock. That works for a while. It does not scale, and it leaves the business exposed whenever that person is ill, travelling or simply exhausted.

A fractional CTO is usually an adviser, closer to consulting than to day-to-day project management. Unless their agreement says otherwise, they are unlikely to be the one restarting services in the middle of the night, and they may not have the hands-on familiarity with the code to do it quickly.

A vendor that ships and leaves may offer a short support period after acceptance, sometimes limited to defect fixes during office hours. After that, an outage is a new piece of work to be quoted and scheduled.

A long-term partner can agree support windows, escalation paths and response expectations in writing. The value is that the people responding are often the ones who wrote the code. The limit is that any team has working hours, and round-the-clock cover is a separate commitment that needs to be explicit.

Whatever the arrangement, a usable incident setup has a few parts in common: a named person or rota, an agreed channel for communications during an incident, a shared definition of what counts as urgent, and clarity on who may approve an emergency change or switch off a feature under pressure. Time zones matter here too. For a business in Singapore working with a team in Ho Chi Minh City, the one-hour difference between UTC+8 and UTC+7 means working days overlap almost entirely.

Monitoring is often set up only for launch-day traffic. The first busy promotion overwhelms the system, and nobody is alerted because no thresholds were ever set for real load. The incident is first reported by customers, which is the worst possible way to learn about load.

What a handover must contain

Every technology partnership ends at some point, or changes shape. A handover is the moment when ownership is either made real or quietly lost. A good handover of resources works as a checklist that someone has actually walked through.

• Administrator access to every repository, moved to people at the business and confirmed by them logging in.
• Top-level ownership of the hosting account and billing, with the outgoing party’s access reduced or removed.
• Control of the domain, DNS and certificates, with renewal dates written down.
• Every outside service account listed, with the credentials moved into a vault the business controls.
• The documentation described above, checked against the system as it runs today.
• A record of known issues, workarounds and anything deferred, with the reasons it was deferred.
• A live walkthrough with the engineers who built the system, so that questions can be asked of the people who know the answers and their insights are not lost.

The walkthrough is the item most often skipped and the one that carries the most context. Documents describe what exists, and the engineers who built it can explain the reasons behind the design and which parts they would be nervous to change.

Two details are easy to miss. Fixes applied directly on a server during an incident need to be reflected in the code, or the next deployment will quietly undo them. Dependencies that are not pinned to versions can change underneath the system on the next build, which turns a routine release into an investigation.

What goes wrong when a partner leaves

Most of the risk in any of these arrangements shows up when the partner steps back: at the end of a contract, after a falling-out, or when a co-founder leaves the company. The problems are predictable, and they tend to arrive together.

The first is missing documentation. The system runs, but nobody left knows why it was built that way, how it is deployed or what the unusual parts of the data model mean. Every change becomes slow and cautious, and some changes stop being attempted at all.

The second is infrastructure in someone else’s name. The live system sits in an account the business does not control, or depends on a domain, certificate or service registered to someone who has gone. Getting it back depends on goodwill, and goodwill is in short supply at the end of a relationship that ended badly.

The third is that nobody has read the code. The business may hold every file, yet no one available has ever worked in it. A new team has to learn the system before it can safely change anything, and in the meantime the product is effectively frozen.

Each arrangement is exposed to these in a different way. A departing co-founder takes the most context with them, because they usually carried the most. A fractional CTO’s exit can leave a gap between the direction they set and the code that was actually written. A vendor that ships and leaves was always going to go, so the risk depends entirely on how well the handover was done. A long-term partner that leaves after years carries a great deal of history, which makes the walkthrough and the documentation more important still.

The best time to plan for an exit is at the start, while relations are good and nobody is in a hurry. A useful test is whether the system could be rebuilt from the repository and the documentation alone, without anyone’s memory. Most systems fail that test the first time it is tried, and finding out early is far less painful than finding out during an incident.

The four options side by side

Laid out on the same points, the trade-offs look like this. Each one moves risk to a different place.

Technical co-founder. Architecture and incident response sit with one deeply committed person, which gives speed and long-term alignment. The exposure is concentration of access, context and on-call duty in one individual.

Fractional CTO. Senior judgement is available without a full-time hire, and an experienced outsourced CTO can spot problems early and help a founder read proposals and hire. The exposure is distance from the code, so direction can drift from practice.

A vendor that ships and leaves. Scope, dates and responsibility are clear, and the relationship ends cleanly by design. The exposure is everything after acceptance, which depends on how complete the handover is.

Long-term partner. Context carries from release to release, and the people answering incidents tend to be the people who wrote the code. The exposure is dependence, unless code, accounts and documentation stay with the business throughout.

Many businesses combine these. A fractional CTO may review the work of a development team, for example, or join planning meetings. A co-founder may lead a small in-house group alongside an outside software development partner. The questions in this article apply to each party in the mix, and the gaps usually appear at the boundaries between them, where each side assumes the other is responsible.

For a technical partner for non-technical founders in particular, the questions become a way to check claims that are otherwise hard to judge. A founder does not need to read the code to confirm whose organisation it lives in, whose name is on the hosting account, or whether a rollback runbook exists.

Frequently asked questions

What is a technical partner?

The term covers any person or team that holds ongoing decisions about a live product, whatever the contract calls them. What matters most is who can act on the code, accounts and incidents day to day.

What is a technology partner?

The two terms are often used interchangeably. In this article, a technology partner usually means an outside team that stays with a product across releases, so the same people carry context from one change to the next.

What other types of partners are there?

Real arrangements often blend the four described above. A fractional CTO may review the work of an outside team, for example, and the gaps in ownership usually appear at the boundaries between parties.

Why is it so hard to find a good technical partner?

Many of the claims that matter are hard to judge before something goes wrong. Ownership gaps usually show only at the first serious incident, the first new hire or the first change of supplier. Checking whose organisation holds the code, whose name is on the hosting account and whether a rollback runbook exists makes those claims testable early.

What should a handover from a technical partner include?

A good handover of resources is a checklist someone has walked through, so the team can use that access immediately. It moves administrator access to repositories, the hosting account and billing, domains, DNS and certificates to the business. It lists every outside service, moves credentials into a vault the business controls, checks documentation against the live system and includes a walkthrough with the engineers who built it.

A Malaysian paint manufacturer runs its orders, stock and production on a system KVY built and has operated since January 2025. A network marketplace in Dubai that KVY built is still run by KVY today. In both cases the team that built the system is the team that runs it: after launch the same team stays on a support contract and reviews what to improve at day 60. How code, accounts and documentation stay with the client is set out on our how we work page, and the same terms apply to early products built through MVP development.

If you are weighing this for your own business, start with a plan. In two to three weeks we map how the system would connect to your ERP, warehouse, payments and sales channels, set out the build in phases with the cost to run it over three years, and give a fixed quote for the first phase. You keep the plan whatever you decide.