2 landmines investors are missing when buying a software outsourcing company in Vietnam

Why this matters now

Buyers generally underwrite software outsourcing companies on the basis of a well-known business model, which says Revenue is a function of
[billable headcount × utilization × average bill rate].

AI token economics are changing all of that.

Revenue from low-end engineering work such as legacy maintenance and testing is melting away, courtesy of Claude and Codex. At the same time, new demand for AI solutions has not yet materialized. So companies get squeezed.

Lots of outsourcing firms are trying to pivot away from selling billable hours (low-end engineering) and fixed-scope projects (custom software development) and towards selling and delivering AI solutions.

If you’re interested in buying such a company right now, and underwriting the AI-upside narrative, this brings up 2 issues.

The first is an outside-in challenge, the other an inside-out one.

The outside-in challenge: how will you, the buyer, change the sales motion from “Tell me what you want me to build” to “Let’s advise clients on what they think they want to build”?

The inside-out challenge: how will the acquirer change the Software Development Lifecycle (SDLC) from a traditional process to an AI-first process (AI SDLC)?

For the non-technical buyer, these landmines may not look obvious during due diligence. So here is a primer on such landmines.

I’ll write more details on how to overcome them in a separate post.

Landmine #1: the outside-in transformation (aka moving up the value chain)

In the old days, customers somehow knew what they wanted, and said “I want you to build me X”. They gave requirements to an outsourcing firm to execute. That’s how Vietnam built a name for itself as the software outsourcing mecca for the US, ANZ, Japan and to a lesser extent Europe.

In our current AI era, customers still don’t know what the ROI of AI is, and what they really want. All they know is the board and Execs are asking for more AI initiatives.

Enter: AI consulting.

That opens a challenge and an opportunity: going upstream and capturing high-margin AI consulting work is the obvious opportunity. You already own the client relationship. With the right AI consulting chops, you could help the client to not only design the right solution, but also to give it to you for implementation.

“With the right AI consulting chops” is often the deal killer.

Indeed, most outsourcing firms are not equipped to sell consulting, let alone AI consulting. That is just not the DNA of outsourcing. They sell capabilities, man-hours packaged in projects and delivery teams.

But of course, such value gap is where the opportunity lies for you, the buyer.

How do you find out early if the target company can transition to AI consulting? Your “customer concentration” diligence should give you some preliminary hints on this - but more on this at the end of the article.

For now, let me warn you on the second landmine you will definitely find. This one can really blow you up.

Landmine #2: the inside-out transformation (aka adopting an AI SDLC)

The short version of this is:

If you use the traditional Software Development Lifecycle (SDLC) to deliver AI solutions, you will lose every AI deal.

Now, onto the explanation.

In the pre-AI era, the SDLC somehow goes like this:

• Client gives some requirements,
• Business Analysts (BA) clarify them, work with UI/UX designers, re-write requirements in the Software Engineers (SWE) lingo,
• A Technical Architect (TA) overviews the main key decisions,
• SWEs code the thing,
• QA/Testers test,
• DevOps take care of cloud deployment,
• A final Product Manager (PM) or release committee gives the final go/no-go.

I am over simplifying but you get the picture.

Now, most people take the same mental shortcut and think:

“AI writes code faster than SWE, therefore I either need less SWE for the same output, or the same headcount for faster delivery”.

That’s the wrong mental model. Step #4 of the process (eg the engineers) is not where your attention should go.

Let me spare you that mistake by telling you a “secret” about software development.

The software delivery cycle is process-bound, not engineering-bound.

In other words, it does not matter how many AI agents you give to your SWE; if the process has not changed, they’re still relying on someone to give them requirements, someone to test, someone else to validate, etc. You will have achieved absolutely nothing but incurred more costs in the form of AI tokens.

Worse, the client will still not be happy because s/he is not getting faster, better or cheaper delivery.

What should you change so that AI creates value for you then?

Let us look at some stylized numbers, so you see how “AI labor compression” really works.

In traditional SDLC, for a typical product module, you would staff something like 1 BA, 3 SWE, 1 QA, 1 DevOp, 1 TA, 1 PM. Most are not full time on a single project, but generally the BA + SWE + QA team is pretty tight-knit (~ 5 FTE). The rest are shared resources.

Enter: Claude Code (CC) and Codex (C). Let us give them the acronym CCC to be quick.

CCC compresses the job of the BA, the coding part of the SWE, most of the QA job and even some of the DevOps job. It is not doing the full job of 5 FTE, but can get pretty close.

Once you understand that, you understand why Palantir came up with the “Forward Deployed Engineer” (FDE) model: a business-minded, AI-augmented and rather expensive engineer sits with the client, figures out what they want, and build / deploy the whole thing, all at once. Because he sits with the customer, he can rinse and repeat REALLY fast.

The result: client gets faster delivery cycle and shorter feedback loops, resulting in something they can actually use, operationally speaking. This has higher value to them, thus opens the door for higher price and higher margins for you, all at once.

But only if - and this is the kicker - you can move from traditional SDLC to AI SDLC.

While Palantir is an extreme case (no, you don’t need FDEs), you can adapt that concept properly if you ask the right question. Which is:

“If CCC compresses all this labor, what type of people do I need to drive the process and delivery value to clients?”

As a buyer / outsider, it should be easier for you to ask this question. For the outsourcing company you are trying to buy, it is harder, because the mental model is still “How do I tweak the traditional SDLC I already rely on”.

In a sense, outsourcing companies are stuck in a variation of the Innovators dilemma, which essentially says that because their margins and incentives are aligned to the old model, they will struggle in adopting a new model.

In all fairness, it is extremely hard to go full AI SDLC.

There are legacy projects that are still based on the old model. There are SWEs who are overwhelmed by the pace of change. There are delivery unit heads who are still trying to figure out how to manage AI coding agents. And sadly, there are also probably people to lay off.

Not a fun time for outsourcing companies. But if you’re a buyer and read up to here, that is because you’re interested in the opportunity this represents. If a proper AI SDLC is not in place yet, you know that it is spelled “D I S C O U N T”.

But the industry is moving fast, so don’t hold your breathe either, thinking that the window of opportunity will stay open forever. It won’t :)

Now, let’s talk about risks and how to flag them in your DD.

How to adjust your pre-IC and post-IC checklist for the AI era?

You now know about the 2 landmines.

“Outside-in” landmine: can we move away from outsourcing DNA towards AI consulting DNA?

“Inside-out” landmine: can we move away from traditional SDLC to AI SDLC?

Shall you not address these, there a 2 big risks:

• The revenue you bought will keep melting away, in a foreseeable manner. International clients will keep demanding less and less of the “automatable with CCC” work - eg legacy migration, QA and testing work, at the very least
• You’ll entirely miss out on a new category of revenue stemming from the growing demand for AI solutions. Clients won’t magically come up with their own AI solutions. They’ll still need you. Will you be there, AI-ready?

Then, how to adjust your pre-IC DD checklist to take these risks into account?

Here are my suggestions:

• Quality of Revenue: I would bucket “legacy migration & maintenance” + “QA / Testing” together into “sunset revenue”. Slash any growth projections for this, for it will only go down from here. If they only bucket by type of contract (eg revenue from billable hours, fixed-project, long-term maintenance, etc.) it won’t tell you enough (a 3-year maintenance contract is still likely to sunset), so make sure to get that breakdown right
• AI-tinted data work: If they have a bucket “data migration / engineering” that shows growth because of AI, pressure test that. What are those projects and what’s the tie with AI? A lot of AI works starts with data engineering work, but you need certainty that it’s not just the legacy “Please clean my data and report back” type of projects
• Customer appetite for AI solutions: US, Singapore, EU is where the big pull is expected to be. Does the customer geo base lend itself to this future demand?
• Customer type concentration: notice I didn’t put Japan in the previous bullet point. Japan is about 40% of all VN outsourcing…big contracts. That’s not necessarily a good thing for your books: what they outsource matters. Historically, it has been legacy, low-end engineering stuff. So treat the “JAPAN specialist” narrative very carefully.
• Culture: harder to assess if you’re a tech outsider. But basically, some outsourcing companies have a culture of “give me the requirements and we’ll just get it done” while others are “we do that, plus we have a history of over delivering to clients”. Of course, prefer the latter, almost product-like type of businesses
• Headcount interpretation: Don’t get fooled by “number of billable engineers”. The billable hour model is under scrutiny as we speak. In fact, if most SWE are working on sunsetting revenue, big SWE headcount becomes a liability, not an asset anymore.
• Talent mapping: Instead of headcount, seek to understand “among these SWE: who has good engineering fundamentals, who is proactively learning about AI SDLC, and who has a growth mindset to drive a full delivery pod augmented with CCC”. This is where you will find your next AI SDLC champions.

On the last point, my preferred way to do this is to just sit and talk 1-1. All it takes is 15-20 min of well-informed, precise conversation. Call it snap judgment if you will, but someone who has been in enough tech trenches and had to sort out enough AI mess can generally tell pretty quickly.

What to add to the post-IC value creation playbook

Budget for outside help to do the AI SDLC overhaul. Profile? Former tech operator who’s been in the trenches, understand SWE psychology and has already gone through the AI SDLC from A to Z. Anti-profile? Generic, non-engineer, non-operator consultant. Do not buy the naive “This is just process change management as usual” consulting narrative.

Likewise for the shift to AI consulting. Some internal people may be up for it, but they’ll need someone to get them across the credibility line. I can tell you that I see lots of people who can vibe code stuff to show a pretty demo, but the moment they’re asked about AI governance, AI architecture or AI risks, they melt. No experience in AI architecture shows very quickly, so budget for external help here.

Positioning: you already have a thesis as to why you want to buy the company. I would sharpen it around 1-2 industry verticals. AI solutions are very bespoke to the client’s workflow and moats can only really be built around very specific industries. Don’t buy an “Ecommerce platform specialist” hoping they can do “AI for insurance” on the basis that “Both domains are data-first”.

Budget for “AI SDLC training + AI engineering bootcamp”. This doesn’t come easily nor naturally, and if you leave it for SWE to “just figure it out” things will blow up.

And of course, budget for AI tokens :) As of now, CCC is as what you want. Don’t even think of Copilot.

There’s nothing fancy in my suggestions. Very operational, hands-on work. While you can probably buy at a good valuation, making those changes to capture the AI upside is actually the name of the game.

We’ve only scratched the surface here and didn’t go into the operational weeds of “how to go upstream” and “how to implement AI SDLC”.

This deserves an article of its own, which I’ll write later. If you’re interested in the next step, continue with Can the outsourcing company you bought transition to the AI Consulting Org Design?.

Until then, happy hunting :)