At some point a serious buyer or investor stops asking about your revenue and starts asking about your technology.
They send people. Those people talk to your engineers, read your contracts, look at how your system is built, and try to work out what they would actually be taking on.
Most founders approach this as an exam they might fail on technical merit. That is the wrong model. Reviewers know your system is imperfect, because every system is. What they are looking for is surprises, and the difference between a business that reviews well and one that does not is almost never the quality of the code.
This article covers what gets examined, what genuinely damages deals, and what to do in the year before you need any of it.
What it is and when it happens
Technical due diligence is the part of a transaction where a buyer examines your technology rather than your accounts.
It usually happens after headline terms are agreed but before money moves. That sequencing is the whole reason preparation matters. By the time it starts, there is a price on the table, and anything found tends to move that price in one direction.
The people doing it are usually an external technical firm engaged by the buyer, sometimes the buyer's own engineering leadership, occasionally both. They are experienced and they have seen a great many businesses, which cuts in your favour more than founders expect. They are not surprised by mess. They are surprised by mess you did not mention.
The work itself is typically days to a couple of weeks for a small business, and a month or more for a larger transaction. What determines the length is rarely the size of your codebase. It is how quickly you can answer questions.
The three questions underneath everything
Every question a reviewer asks maps back to one of three things. Holding that in mind makes the whole process easier to prepare for.
Does the technology do what you said it does? Whether the product genuinely works as described, whether the metrics come from where you claim, whether the thing demonstrated in a sales meeting is the thing that exists.
What will it cost to run and improve after we own it? Infrastructure costs, the size of team needed, how long changes take, what needs fixing before anything new can be built.
What are we taking on that we have not been told about? Legal exposure, security problems, dependencies, obligations.
Notice that only the second is really about engineering. The first and third are about accuracy and disclosure, which is why honesty is the dominant variable in how these processes go.
The eight areas they examine
1. Code and architecture
Founders expect this to be the main event. It usually is not, and reviewers are far less interested in style than people fear.
What they actually assess:
Could somebody new work in this? A developer joining should be able to become productive without a specific individual explaining everything.
Is it tested enough that changes are safe? Not test coverage as a percentage, but whether a change can be made with reasonable confidence that nothing else breaks.
Is anything so fragile that nobody touches it? Almost every business has one of these. Having one is normal. Not knowing you have one is the problem.
Does the architecture match the business plan? A system built for a hundred customers, attached to a plan for ten thousand, raises a question worth answering.
The unintuitive conclusion: ugly code that is well tested reviews better than elegant code nobody dares change. Reviewers care about whether the system can be worked on, not whether it is beautiful.
2. Infrastructure and operations
Where it runs, what it costs, whether it survives growth, and whether anybody could rebuild it.
The most common finding here is infrastructure configured by hand over several years with no record of how. Nobody can recreate it, nobody fully understands everything running, and the knowledge exists only in whoever set it up.
Hosting cost matters more than founders expect, because it is a recurring cost the buyer inherits and it is trivially easy to model. Infrastructure spend that is high relative to revenue, or growing faster than revenue, shows up immediately in a financial model. It is also one of the more fixable items in the year before a process.
Our guide on systems breaking when you grow covers the limits question, which reviewers ask in the form of "what happens at ten times this volume".
3. Security
What they ask: have you had a breach, how is access controlled, are dependencies patched, is anything sensitive stored badly, and would you know if something went wrong?
The single worst answer to any of those is "nobody knows", because it invites the reviewer to assume the worst and they are professionally obliged to.
Our guides on access control and cybersecurity for small business cover the underlying practices. The specific things that come up repeatedly are shared administrator accounts, staff who left with access intact, dependencies years out of date, and no monitoring at all.
On past incidents: whether and how to disclose is a legal question for your adviser. What is clear commercially is that buyers routinely accept that incidents happen, and do not accept discovering one after closing that they were not told about. That moves the conversation from valuation to warranty claims, which is a considerably worse place to be.
4. Intellectual property ownership
This is the most common deal-breaker, and it is the one most businesses have never checked.
The question is simple: does the business clearly own what it is selling?
Three ways the answer turns out to be no:
Contractors and agencies without written assignment. Somebody wrote code for you, was paid, and the contract never assigned the intellectual property to the business. This is extremely common in businesses that started with freelance help.
Open source components with licence obligations. Some licences impose conditions that can affect what a buyer may do with the software afterwards. Most businesses have never audited this. Most findings are straightforward to fix once identified, and it becomes serious only where a licence conflicts with the buyer's intended use.
A founder or early employee who left. They wrote a significant part of the system, there was no assignment agreement because everybody was friends, and they now hold rights nobody accounted for.
Our guide on who owns your code covers how to check, and our guide on the accounts your business must own covers the parallel question about infrastructure and domains, which is examined just as closely.
Fix this first, and fix it now. It costs signatures rather than engineering time, and the price of a signature rises sharply once the other party knows you need it for a transaction.
5. Data and privacy
What personal data do you hold, where is it, what basis do you have for holding it, and how long do you keep it?
A business that cannot answer those is carrying an unquantified liability into somebody else's ownership, and buyers price unquantified liabilities pessimistically.
This is genuinely hard to assemble quickly, which is why it belongs in early preparation. Our guides on data retention and data residency cover the underlying work. The deliverable a reviewer wants is a table: what data, in which system, where stored, for how long, on what basis.
Most businesses have never produced that table. Producing it takes days and it is one of the highest-return preparation tasks available.
6. Key-person risk
How much of your technology depends on specific individuals?
If one person understands the core system, holds the critical credentials, and has never written any of it down, the buyer is acquiring a dependency on a human being who may leave once their equity vests.
This is one of the most commonly raised findings and one of the most damaging, because it cannot be fixed by writing a cheque.
Reducing it takes months. Documentation somebody else can follow. More than one person with production access. Code reviewed by a second person before shipping. Credentials held by the business rather than an individual. None of that is fast, which is precisely why it belongs in the year before rather than the month before.
Reviewers frequently interview your engineers, and those conversations are more informative than any document. They ask what worries people, what they would fix first, and how confident they are in the tests. Engineers generally answer honestly.
Tell your team the process is happening and ask them to answer honestly. Do not coach them toward particular answers. Reviewers are experienced at noticing that, and it damages trust far more than any technical finding would. Honest engineers describing real problems is a normal, survivable outcome.
7. Third-party dependencies and contracts
What you rely on, what it costs, what the contracts say, and what happens if one disappears.
A business built substantially on a single supplier with a short notice period carries a risk that will be priced. So does a business that could not extract its own data if a provider failed. Our guide on getting your data out covers testing that rather than assuming it.
Contracts with development agencies get read closely, both for the IP question above and for what happens on a change of control. Some agreements allow a supplier to terminate or renegotiate when a business is sold, which is exactly the sort of thing a buyer would rather know before than after.
8. Technical debt and roadmap credibility
Buyers expect technical debt. It exists in every business they have ever looked at. Finding it is not the problem.
What damages a deal is technical debt the seller did not know about or did not mention.
A written list of known problems with rough remediation estimates reads as competence and control. The identical problems, discovered one at a time by a reviewer over three weeks, read as concealment and raise the question of what else is there.
Our guide on technical debt covers how to describe it in terms a buyer will understand, which is principal and interest rather than engineering complaint.
On the roadmap: reviewers assess whether your commercial plan and your technical reality are consistent. A roadmap promising rapid delivery on a codebase nobody can safely change is a warning sign rather than an asset, because it means either the plan is wrong or somebody has not thought about it.
What actually kills deals
Three things come up repeatedly, and two of them are about disclosure rather than engineering.
Unclear code ownership. The most common. Entirely knowable today. Fixable with signatures.
A serious undisclosed security problem. Not the existence of the problem, the fact that it was undisclosed.
Technology that does not do what was claimed. The demo showed something the system does not actually do reliably, or metrics came from somewhere other than where the buyer was told.
Everything else tends to reprice rather than terminate. Findings become a lower price, a holdback where part of the payment is retained until something is fixed, or specific warranties you have to give personally.
It is worth being honest about the direction of travel here: diligence almost never increases a valuation. A clean process protects the price you agreed. That is the realistic goal, and it is a valuable one, because the alternative is a renegotiation from a weak position.
How a finding becomes a deal term
It helps to see the mechanism, because founders tend to imagine diligence findings as a pass or fail judgement when they are actually inputs to a negotiation.
Take a real and very common example. The reviewer establishes that two developers who built a substantial part of the system were engaged as contractors, paid properly, and never signed anything assigning intellectual property to the company. One still works with you. The other left in 2023 and is now employed elsewhere.
Nothing about the software has changed. The code is the same code it was yesterday. What has changed is that the buyer now knows they may not be acquiring clear title to part of what they are paying for.
Four things can happen next, roughly in order of how well the seller handled the situation.
You fix it before closing. You contact both contractors, explain the position, and get assignments signed. The one still working with you signs readily. The one who left may want something, and whatever they want is now more expensive than it would have been last year. The deal proceeds.
A holdback. The buyer retains part of the purchase price until the assignments are produced, typically with a deadline. You get the money eventually, and you have handed the other side a reason to be patient while you negotiate with somebody who now understands their leverage.
A specific warranty and indemnity. You personally guarantee that ownership is clear and agree to cover the cost if it turns out not to be. That is a liability that survives the deal, sometimes for years, and it sits with you rather than with the company you just sold.
A price reduction. The buyer discounts for the risk and proceeds. This is the outcome that feels least painful in the moment and frequently costs the most.
Now consider the same finding where the seller raised it themselves in week one, with a note saying two assignments are outstanding, here is who, here is our plan to obtain them. It becomes a task on a checklist rather than a discovery, and it rarely reaches any of the four outcomes above.
The finding was identical. The handling was not, and the handling is the part you control.
What a good preparation timeline looks like
Twelve months out, if you have the choice. The two things that most often damage deals, ownership gaps and key-person risk, both take months to fix properly. Start there: get IP assignments signed, move accounts into the business's name, get a second person into every critical system, and start writing things down.
Three months out. Assemble the data room. Produce the data inventory. Write the known-issues list. Audit dependency licences. Fix the obvious security items: shared accounts, departed staff with access, badly out-of-date dependencies.
One month out. Organise what exists, rehearse the architecture explanation, and brief your team. There is not time to fix anything structural, and pretending otherwise leads to rushed changes that create new problems.
Already in a process and unprepared? Prioritise rather than panicking. Establish your ownership position first, because it is the most likely deal-breaker. Assemble what documents you have. Write the known-issues list and disclose early rather than waiting to be asked. A prepared answer about a real problem is far better than a scramble when it surfaces.
The questions to ask yourself first
Before any of the preparation work, ten questions. If you can answer all ten confidently and in writing, you are in better shape than most businesses entering a process. If four or more make you uncomfortable, you have found your priority list.
Do we have a signed agreement assigning intellectual property from every person who has written code for us? Including former employees, freelancers and agencies.
Are all our critical accounts in the company's name rather than an individual's? Domain, hosting, code repository, payment provider, app store.
Could somebody other than one specific person deploy a change to production tomorrow?
Do we know what personal data we hold, where it sits, and how long we keep it?
Do we know what every third-party component in our system is licensed under?
Has anyone left in the last two years who still has access to something?
Do we know what our infrastructure costs each month, and whether that is growing faster than revenue?
Could we describe our architecture to an intelligent non-specialist in ten minutes?
Do we have a written list of the things in our system that worry us?
Would our engineers, asked privately, describe the system the same way we just did?
That last question is the one worth sitting with. In businesses that review badly, the gap between the founder's account and the engineering team's account is usually the thing that surfaces first, and it undermines everything else the founder has said.
None of these ten requires an adviser to answer. All ten can be worked through in a week. The businesses that come out of due diligence well are, almost without exception, the ones that had answered them long before anybody asked.
The technical data room
The data room is the organised collection of documents you provide. For the technical portion, nine items cover almost everything asked for:
| Item | What it is |
|---|---|
| Architecture overview | How the system fits together, in language a non-specialist can follow |
| Infrastructure and cost summary | What runs where, and what it costs monthly |
| Dependency list with licences | Every third-party component and its licence terms |
| Access control approach | Who has access to what, and how that is managed |
| Incident history | Security and availability incidents, and what changed after each |
| Data inventory | What personal data, in which system, where, for how long, on what basis |
| Contracts with technical suppliers | Including change-of-control provisions |
| IP assignment agreements | For every person who has written code |
| Known issues list | Written honestly, with rough remediation estimates |
Most businesses can assemble seven of those within a week. The two that take longer are the data inventory and the IP assignments, which is another reason to start those early.
One test worth running on your own documentation before anybody else does: give it to somebody who has never seen your system and ask them to follow it. Reviewers frequently do exactly this. Documentation is judged by whether somebody new could use it to do something, not by how much of it there is. A short accurate setup guide beats a large wiki that has drifted from reality.
Who should run this on your side
One person needs to own the technical side of the process, and it should not be whoever is negotiating the deal.
The founder or chief executive is usually leading commercial discussions, managing the relationship with the buyer, and carrying the emotional weight of the transaction. Adding responsibility for assembling architecture documents and chasing contractor signatures to that load produces a slow, distracted process at precisely the moment speed matters.
Give it to your most senior technical person, or if you do not have one, to whoever knows the systems best, and give them explicit authority to pull other people off delivery work. Diligence questions arrive with short expectations, and a team still trying to hit a product deadline will answer them badly.
Two practical points about that role. They need access to the commercial context, because a question about infrastructure cost means something different when you know the buyer is modelling five-year operating expense. And they need permission to say "I do not know, I will find out" rather than guessing, because a confident wrong answer discovered later damages trust across everything else that was said.
Where a business genuinely has nobody suitable internally, this is a reasonable thing to bring in help for. What is not reasonable is leaving it to the buyer's reviewers to work things out unaided, because their working assumptions in the absence of information are rarely generous.
How to behave during the process
The behavioural advice matters as much as the technical preparation, and it is simpler.
Volunteer your problems early. A seller who hands over a known-issues list at the start has framed the conversation and demonstrated they understand their own system. A seller whose problems emerge one at a time creates the impression there may be more.
Answer quickly. Response speed is read as a proxy for how well you know your business. It also directly shortens the process, which reduces cost and deal fatigue.
Do not oversell. Reviewers have seen many businesses and they discount enthusiasm automatically. Specific, measured description carries far more weight than confidence.
Know your own weaknesses well enough to describe them. The most effective posture available is a founder who says "the billing module is fragile, here is why, here is roughly what fixing it would take." That answer demonstrates control. "Everything is fine," followed by three findings, does the opposite.
Investment versus acquisition
The core questions are the same and the emphasis differs.
Investors care more about whether the technology can support the growth in your plan. Can it handle ten times the volume, can the team ship fast enough to hit the roadmap, will the architecture need replacing before the next round.
Acquirers care more about what they are taking on and how it fits with what they already own. Integration cost, duplicated systems, whether your team will stay, what they will have to maintain.
Preparation is largely identical, which is convenient, because most businesses do not know at the outset which of the two will happen first, and some end up doing both within a few years of each other.
Outsourced development is not a problem
Worth saying plainly, because founders who used an agency often assume it counts against them.
It does not, provided four things are true: the arrangement is documented, the intellectual property is properly assigned, some knowledge of the system exists inside your business, and the relationship could survive a change of ownership.
Where it becomes a problem is when none of those hold, and the buyer discovers that the business owns neither the code nor any understanding of it. Our guide on bringing development in-house covers what has to transfer if you decide to make that change.
Scale the effort to the transaction
A small acquisition might involve two days of review rather than a month. The areas do not change with deal size; the depth does.
Small businesses are frequently caught out by assuming they will not be asked at all, and then find themselves answering the same ownership, dependency and key-person questions with no preparation.
The proportionate version for a small business is: know your ownership position, have a dependency list, know your infrastructure cost, have a known-issues list, and have somebody other than one person who understands the system. Five things, achievable in a few weeks, and between them they answer most of what a proportionate review will actually ask.
What this is worth
A clean process does not raise your valuation. It protects it.
What it actually buys you is speed, fewer warranties, a smaller holdback, and a buyer who believes what you have told them. Those are real commercial outcomes, and they are worth considerably more than they sound, because the alternative is renegotiating from a weak position with a deadline approaching.
The single highest-return thing to do today is establish whether you clearly own your code and your accounts. It is the most common deal-breaker, it is entirely knowable within a week, and fixing it costs signatures rather than engineering time.
A meaningful proportion of businesses running that check find something worth resolving. Finding it now costs a conversation and a signature. Finding it during a transaction costs money, leverage, and sometimes the deal itself.
If you want help, a technical readiness review covering what a buyer would examine, where your gaps are and what to fix in what order starts from around AED 10,000 with us, and produces the written material a data room needs. Reviewing a target business on the buy side is priced separately by scope. Final pricing depends on scope, and these are our own figures rather than a market survey. Anything turning on contract terms or disclosure obligations belongs with your legal adviser.
References
- SKIMBOX, who owns your code in the UAE
- SKIMBOX, the accounts your business must own
- SKIMBOX, technical debt explained
- SKIMBOX, single sign-on and access control
- SKIMBOX, cybersecurity for small business in the UAE
- SKIMBOX, data retention for a UAE business
- SKIMBOX, data residency in the UAE
- SKIMBOX, getting your data out
- SKIMBOX, your system breaks when you grow
- SKIMBOX, bringing development in-house
- SKIMBOX, software escrow in the UAE
This article describes what technical due diligence typically covers, based on the areas buyers commonly examine. It is not legal or financial advice. Disclosure obligations, warranty terms and anything turning on your specific contracts should go to a qualified adviser.
