After the Man-Month: FPT Software's AI Accountability Test

Summary

• FPT Software's economic problem is no longer simply supplying skilled engineers at a reduced global cost. AI can reduce the labour needed for certain coding, testing and documentation tasks, so the company must increasingly prove it can contract for accepted outcomes rather than just selling more hours.
• The operational base is substantial, but its public financial evidence is mainly reported through the broader Global IT Services segment of FPT Corporation. That segment recorded revenue of VND 35,382 billion in 2025, with Japan accounting for 44% of the regional split; these figures are useful context, not standalone accounts for the legal entity covered here.
• FPT's proposed delivery architecture combines local governance, nearshore overlap and offshore execution centred on Vietnam. This can offer time-zone coverage and specialist scale, but accountability becomes difficult when subsidiaries, cloud providers, enterprise software vendors and automated development tools all sit inside the same engagement.
• The strongest sourcing test is not a demo of generated code. It is whether FPT can show a representative modernisation project with an agreed baseline, independently measured defects, traceable human approval, secure handling of client material, enforceable acceptance criteria and a usable exit package.
• Evidence of ambition is abundant; evidence of repeatable results in the AI era is thinner. FPT publishes productivity targets and case-study gains, while independent studies of AI-assisted software work show strongly context-dependent outcomes. Buyers should embed that uncertainty into pilots, warranties, service credits and transition rights.

The bill is the strategy

Imagine the first business meeting for a ten-year-old enterprise application. The client has brittle interfaces, a shrinking group of people who understand the code, security findings that cannot be cleanly fixed, and a cloud or ERP programme waiting on the other side. Under the familiar offshore model, a vendor estimates a team, assigns roles, proposes a blended monthly rate and adds governance around the resulting effort. The bill is readable even when the outcome is not: people multiplied by time.

FPT Software now presents a different value unit. ItsDigital Foundry proposaldescribes story-point velocity pricing for software delivery, volume bands and prevention credits for application support, and a gradual transition from time-and-materials to hybrid and outcome-focused contracts. A separateFlezi Metis presentationframes the transition even more directly: moving from selling man-months to selling 'system certainty'.

This is not just a pricing experiment. It is an attempt to redesign the outsourcing business.

The conventional model monetises labour leverage. A vendor recruits, trains and organises a large base of engineers in a lower-cost location, places a smaller group near the client, standardises delivery and earns a margin between the value of the work and the cost of supplying it. Better tools can improve the margin if the client keeps buying the same capacity. But if an automated coding or testing tool actually removes a large part of the effort, a transparent client will ask why it should keep paying for hours that have disappeared.

The vendor then has three choices: lower the price, redeploy the capacity into a broader scope, or charge for an outcome whose value is not directly tied to headcount.

FPT is visibly choosing the third choice. In May 2026 it stated it wantedabout one-third of revenue to come from 'AI-first' projectsand set itself a productivity improvement ambition of 30%. These are corporate targets, not audited achievements. They nonetheless reveal the strategic pressure. If automation makes junior coding capacity less scarce, the advantage of having many engineers in Vietnam becomes less defensible in itself. FPT must transform that workforce into a system of discovery, control, verification, integration and support – activities for which clients will still pay when raw code generation becomes cheap.

The bet may work. Legacy systems rarely fail to be modernised because nobody can type new code. They fail because requirements are incomplete, business rules are embedded in old behaviour, data is inconsistent, interfaces are undocumented, cutovers cannot be interrupted, and no executive will sign the acceptance certificate when the replacement behaves differently. AI-assisted analysis can accelerate reconstructing that knowledge. A global delivery organisation can then apply specialists repeatedly across languages, platforms and regulated domains.

But the same shift can make accountability less clear. If an automated tool proposes a conversion, an offshore engineer reviews it, a nearshore team integrates it, an onshore architect approves the design, a cloud provider hosts it and the client accepts it, who bears the cost when the system fails six months later? A contract that pays for story-point velocity may reward movement through a backlog while leaving the hardest question – whether the software is safe and fit for purpose – with the buyer. FPT's future advantage therefore depends less on how many artefacts it generates than on how much accountability it can make travel with them.

The company, not the conglomerate

The subject is FPT Software Company Limited, also identified in Vietnamese as Công ty TNHH Phần mềm FPT. Itsofficial corporate pagegives business registration number 0101601092 and a registered address at FPT Cau Giay Building in Hanoi. TheFPT Corporation member company registerdates the software business to January 1999. The reviewed 2025 interim financial statements of FPT Corporation list FPT Software Company Limited as a direct subsidiary in software products and services, with100% ownership and voting poweras of 30 June 2025 and 31 December 2024.

This boundary matters because 'FPT' can refer to a much wider Vietnamese group spanning technology, telecommunications and education. The parent company invests in AI infrastructure, and it uses its education arm as part of a broader talent strategy. These activities may strengthen FPT Software, but they are not interchangeable with the contracts, employees, liabilities or delivery records of the operating company. A client buying application support from FPT Software is not automatically buying every capability advertised elsewhere in the group.

The boundary also becomes porous in the opposite direction. FPT Software has grown through acquisitions and specialised operations. Its public history records the purchase of RWE IT Slovakia in 2014, the acquisition of US consultancy Intellinet in 2018, and further expansions. More recent transactions have added nearshore delivery capability viaIntertec International's IT services division, product engineering viaCardinal Peak, and European consultancy via a majority stake inAOSIS. Cardinal Peak's own site describes it aswholly owned by FPT, while the acquisition announcement said it would remain an independent entity.

For sourcing, the brand architecture is not a formality. The proposal must identify the legal contracting party, each delivery subsidiary, the countries from which personnel will access systems, which entity owns the pre-existing tools, and which entity carries professional liability, cyber cover and post-termination obligations. A group-capabilities slide cannot replace this accountability map.

The scale is visible; the standalone economics are not

FPT Software's website currently claimsover 33,000 employees, 1,100 clients, operations in more than 30 countries and more than 90 offices or representative locations. Itsglobal presence directoryshows an operational footprint across Asia, the Americas and Europe. These are company-published scale indicators. They are plausible in the context of the parent company's disclosures, but the public documents examined do not provide a separate audited income statement, client concentration table or margin bridge for FPT Software Company Limited alone.

The closest financial lens is FPT Corporation's Global IT Services segment. According to the parent company's2025 earnings report, that segment generated VND 35,382 billion in revenue and VND 5,467 billion in profit before tax in 2025, increases of 14.3% and 14.6% respectively. Digital transformation revenue was VND 16,751 billion, up 16.8%. Signed revenue reached VND 40,636 billion, and the group reported 26 new signed contracts worth over USD 10 million each and 266 clients generating more than USD 1 million in revenue.

These figures demonstrate commercial mass. They should not be pasted onto the legal entity as if they were its own statutory accounts. 'Global IT Services' may include subsidiaries and operational arrangements beyond the precise entity in the directory. The numbers are therefore best read as the economic environment in which FPT Software operates.

The geographic breakdown is more revealing. The same report attributes 44% of Global IT Services' 2025 revenue to Japan, 23% to the US, 23% to Asia-Pacific ex-Japan and 10% to Europe. Japan grew by 25.4% in Vietnamese dong, or 21.9% in Japanese yen. In April 2026, the parent company reported that Global IT Services first-quarter revenue had increased by 10.4% to VND 9,034 billion, with Japan advancing 18.8%, while signed revenue rose by 22.2% toVND 13,833 billion.

This composition gives FPT both protection and exposure. Japan rewards long-term relationships, local language and process discipline; these are hard for a new entrant to replicate. It also leaves a large portion of the segment dependent on a single country, its currency and its corporate investment cycle. The US offers larger transformation programmes but exposes FPT to a different procurement culture, higher litigation risk, more aggressive cloud competition and a shorter tolerance for communication friction.

Large contracts can accelerate the shift. FPT's 2025 report highlighted a five-year USD 256 million energy-sector agreement covering requirements, design, development, testing, deployment, operations and documentation, as well as a three-year USD 100 million US contract covering consulting, cloud, infrastructure, application operations, AI and data. Clients were not named in the report. These wins show that the parent segment can sell end-to-end accountability at a scale far beyond headcount augmentation.

They also raise execution risk: a single poorly defined transformation programme can consume scarce senior attention and create material warranty, service-credit or reputational costs.

Public evidence does not disclose the largest client share of revenue, the top-ten share, renewal rates or gross margin by contract type. FPT stated in a 2024 management announcement that itsmillion-dollar client portfolio represented 80% of revenue. That statement suggests a business anchored in substantial accounts, but it does not reveal whether revenue is broadly spread within that group. The proper conclusion is not that FPT is dangerously concentrated or safely diversified. It is that client concentration remains an unresolved diligence item despite a high number of large accounts.

Japan is the proving ground

Japan is where FPT's labour-arbitrage story became an operating model. FPT says its Japan business exceededUSD 500 million in revenue in 2024, supported by 17 offices, over 4,000 locally based employees and a broader pool of 15,000 engineers serving the market. It also reported approximately 450 Japanese clients. Again, these are company figures, but they align with the parent segment's regional composition.

An independent World Bank study offers a useful explanation of the mechanism. In interviews for its 2024 services report on East Asia, FPT described a workforce of about 25,000 in Vietnam and 5,000–6,000 outside the country at the time, with Japan as its largest market. The report'sFPT case materialemphasises the combination of offshore, nearshore and onshore resources, along with linguistic, cultural and time-zone proximity. It also places FPT within a broader Vietnamese challenge: moving from cost-based services to higher-value digital work requiring deeper skills.

Japan's legacy problem is unusually compatible with this proposition. Japan's Ministry of Economy, Trade and Industry warned again in 2025 that legacy systems remained a barrier to digital transformation and industrial competitiveness, reviving the concern known as the'2025 digital cliff'. Another METI report highlighted structural shortages and the need to reshapedigital workforce skills in the age of generative AI. FPT can offer Japanese-language coordination close to the client and a much larger engineering base in Vietnam for analysis, conversion, testing and support.

Historical World Bank research on IT services in Vietnam found that FPT was already moving beyond basic coding and testing into more complex engineering and architecture work, and that Japanese buyers' long-standing relationships with vendors createdhigher switching costs than simple hourly-rate comparisons suggested. The evidence is older and should not be treated as a description of FPT's current quality. It nonetheless identifies a durable business model: local trust opens the account, offshore scale widens it, and accumulated system knowledge makes the relationship sticky.

AI could strengthen this model by helping engineers reconstruct undocumented systems and transfer knowledge between languages. It could also destabilise it. If automated tools reduce the amount of offshore implementation work, FPT needs more bilingual architects, domain experts and accountable service managers, not simply more junior developers. Japan's value to FPT will then depend on the company's ability to shift its centre of gravity from labour provision to institutional knowledge without losing the cost advantage that won the work.

What a client actually buys

'Application modernisation' sounds like a product category. In practice it is a chain of decisions with different standards of proof.

The first step is discovery. The vendor inventories source code, interfaces, databases, operational jobs, security constraints and business owners. It distinguishes systems that can be retired from those that must be rehosted, replatformed, refactored or rewritten. FPT'sapplication services catalogueoffers reverse engineering, source conversion, data migration, rearchitecture, interface work, verification, testing and managed services. The breadth is credible as a catalogue; it does not show how these capabilities are assembled coherently on real projects.

The second step is knowledge reconstruction. Existing behaviour is often the only remaining specification. A billing rule may exist in code, an operations manual, an employee's memory and a spreadsheet exception list, each with a different answer. FPT's Flezi NEXT material says it can use automated analysis to rebuild architecture, dependencies and business logic before rebuilding or converting a system. In May 2026, FPT claimed experience onover 100 modernisation projects and 300 million lines of legacy code, as well as large reductions in preparation effort and project time. These figures come from FPT, with no public project sample, baseline or independent validation. They support the existence of a method, not the certainty of an outcome.

The third step is target design. The client and vendor choose a cloud, data architecture, integration model, security perimeter and operating model. This is where modernisation can quietly become a dependency substitution. A mainframe or custom application may be replaced by SAP S/4HANA, Microsoft Dynamics 365, a hyper-scaler service or a vendor accelerator. The new system may be easier to maintain but more dependent on vendor licenses, cloud consumption and specialist configuration.

The fourth step is implementation. FPT's public 'best-shore' description allocates onshore teams to decision-making and regulatory or outcome ownership, nearshore teams for time-zone overlap and offshore teams for high-volume engineering. In one company example, onshore governance was paired withover 200 SAP consultants in Vietnam. This is a sensible division of labour. Its weakness is the density of handovers. Requirements may be interpreted differently as they flow between client specialists, local consultants, offshore developers and automated tools.

The fifth step is verification. Unit tests establish that a component behaves as expected in isolation. Integration tests check its neighbours. Regression tests protect old behaviour. Performance, resilience, security and data reconciliation tests address different failure modes. User acceptance testing asks the business to decide whether the outcome is usable. No single 'test accuracy' percentage can represent all of this. The contract must specify which tests FPT owns, what evidence it must keep, who approves exceptions, and whether acceptance covers generated code, converted data and operational recovery.

The sixth step is cutover and support. FPT'smanaged services offerincludes incident, problem, change, release and configuration management; application support; cloud and on-premises operations; and L1, L2 and L3 service levels. It advertises configurable service levels and 24-hour delivery. A buyer needs the actual service design: monitoring ownership, support hours by location, escalation names, recovery objectives, dependency exclusions, chronic-incident handling, and the boundary between defect warranty and chargeable change.

The client is therefore not buying 'developers in Vietnam'. It is buying a distributed decision system. FPT's ability to make that system work depends on the ratio of senior reviewers to automated output, the authority of its local staff, the quality of its knowledge transfer, and whether its contract makes a single party accountable for the entire path from reconstructed requirement to stable operation.

AI moves the bottleneck to acceptance

FPT's documents on AI for software engineering are more commercially important than their product names. CodeVista is presented as an enterprise coding assistant with private deployment, customisation and usage controls. Flezi NEXT targets legacy system understanding and transformation. Flezi Metis is described as a logical model of a software asset that can support impact analysis, root-cause investigation and change verification. The Digital Foundry proposal combines these ideas into a governed delivery environment with planning, coding, review, test, security, documentation and architectural assistance capabilities.

The architecture is coherent. A large services company sees many repetitive tasks: reading unfamiliar code, identifying dependencies, creating tests, converting languages, documenting interfaces, triaging incidents and verifying standards. If FPT can capture useful patterns without exposing client material, it can make each engagement inform the method for the next. Its scale becomes a learning advantage rather than just a headcount advantage.

Yet productivity evidence is unusually context-sensitive. A controlled study associated with GitHub and Microsoft found that developers using Copilot completed a limited small programming task55.8% faster. That is evidence that assistance can speed up some work. It is not evidence that a banking core conversion, a SAP deployment or an embedded automotive programme will finish 55.8% faster.

METR obtained the opposite result in a different setting. Its 2025 randomised study found that experienced open-source developers working on repositories they knew took19% longer with early-2025 AI tools, despite an expectation of speedup. METR's February 2026 update found signs that newer tools might help, but its estimates still hadwide confidence intervals. The studies do not prove that AI is harmful or helpful in general. Together, they show that task shape, repository familiarity, model capability, review effort and measurement design can reverse the result.

Google Cloud's 2024 DORA research found a similarly mixed association: greater AI adoption correlated with reported improvements in documentation, code quality and review speed, while its model estimated declines indelivery throughput and stability. This was observational evidence, not a controlled causal test. It warns against measuring only the speed of an individual development step.

For FPT, this shifts the bottleneck. Generating a conversion or a test is less valuable than proving it preserves intended behaviour. Faster coding can create a review queue. More generated tests can create false confidence if they encode the same faulty assumption as the generated implementation. Automated documentation can make a system feel understood while critical exceptions remain in an operator's memory. A tool can reduce visible effort while increasing the amount of senior attention needed to establish trust.

FPT's own business documents recognise some of this. The Digital Foundry document describes strict human approval for material, security-sensitive or regulated decisions, lighter oversight for routine work, and continuous proof of actions and approvals. This is the right direction. The unresolved questions are operational:

• What makes a change 'material', and can a delivery manager lower that threshold under deadline pressure?
• Is the reviewer independent from the person or system that produced the work?
• What evidence shows the reviewer had sufficient context, rather than simply clicking approval?
• Are the model, retrieval sources, tool versions and policy parameters recorded for later investigation?
• Can client source code, tickets, logs or personal data be used to improve a shared tool?
• What happens when an AI provider changes the model during a regulated programme?
• Who pays when automated output passes agreed tests but fails in production because the tests were incomplete?

The NIST AI-focused extension to the Secure Software Development Framework treats these as lifecycle controls rather than optional ethics language.SP 800-218Acalls for documented accountability, protection of development artefacts, provenance, versioning, monitoring and explicit security requirements in acquisition. It also recognises shared responsibility among producers, acquirers and service providers. A buyer can turn these guidelines into contractual appendices: approved tools, permitted data, evidence retention, human authority, vulnerability handling and notification when a model or control changes.

FPT's internal adoption provides a limited case. AMicrosoft customer storyindicates that FPT first introduced Microsoft 365 Copilot to about 500 back-office employees, used recommendations to adjust adoption, and observed an eightfold increase in engagement in some groups. The story demonstrates structured deployment and measurement, but it covers workplace use inside FPT, not externally accepted software engineering outcomes. It should not be confused with evidence of application modernisation productivity.

The sourcing implication is straightforward: ask for a distribution, not a headline. FPT must show cycle time, escaped defects, rework, security findings, rollback frequency, review effort and client acceptance for comparable tasks before and after assistance. It must disclose failed or neutral pilots alongside successful ones. A 30% average productivity claim is commercially meaningless if the gains are in low-risk documentation while the critical path remains architecture review, data reconciliation or business acceptance.

Platforms make delivery possible – and exit harder

FPT does not modernise applications in a vacuum. It sits between clients and the major platform vendors.

The official SAP partner directory lists FPT Software Company Limited and describes services including assessment, implementation, deployment, migration, application management, training and testing. ThisSAP listingis a useful third-party confirmation of a formal role in the ecosystem. It does not verify project success rates or the validity of each consultant certification. FPT's own 2026 SAP brochure claims over 1,600 SAP employees, more than 350 clients and high satisfaction; these numbers require project-level substantiation in a sourcing process.

FPT also marketsAWS migration and managed services, and a broadMicrosoft practicecovering Azure, Dynamics 365 and Copilot-related work. These relationships can reduce implementation risk because FPT can draw on established reference architectures, training and support channels. They can also align vendor recommendations with partner incentives. The technically cleanest target may not be the cheapest or least constraining operating model for the client over ten years.

Consider an application replacement decision. A vendor can rewrite the system on portable infrastructure, move it to cloud-native managed services, or map the process into an ERP product. The first may preserve control but require more custom engineering. The second may reduce operations work while increasing hyper-scaler dependency and data egress costs. The third may standardise the process but impose licensing, upgrade and configuration constraints. FPT may be capable of all three, but its accelerators, certifications and partner economics may make one path easier to sell.

The same applies to FPT's own tools. A code intelligence layer that rebuilds dependencies can create durable value during a modernisation. If its logical model, annotations and validation records remain accessible only through a proprietary service, the client becomes dependent on FPT to understand the very system FPT has just modernised. The company says Flezi Metis aims to preserve system knowledge and reduce dependence on individual experts. That claim becomes valuable only if the client can export the knowledge in documented, usable formats and continue to operate when the FPT engagement ends.

Cloud and enterprise software also complicate accountability. A performance failure may originate from FPT's code, a client configuration, a SAP extension, a hyper-scaler service limit or an upstream outage. Contracts often exclude third-party failures while designs rely heavily on third parties. The buyer must require FPT to own diagnosis and coordination even if financial liability is allocated elsewhere. Otherwise, the 'end-to-end' provider becomes a traffic controller that can identify multiple possible causes but is accountable for none.

The substitution set is broader than choosing another offshore vendor. A client can compare FPT with global consulting firms and system integrators, large India-centred IT services companies, Japanese integrators, specialist engineering firms, cloud provider professional services and its own global capability centre. Airbus's 2019 Skywise programme, for example, named FPT alongsideAccenture, Capgemini, IBM and Sopra Steria. These companies may be competitors on one engagement and partners on another. Kyndryl and FPT themselves announced a partnership on AI, cloud and application modernisation.

FPT's differentiator is therefore not a unique service catalogue. Most large competitors can offer cloud migration, ERP implementation, managed services and automated development support. FPT's case is the combination of Vietnam delivery scale, Japanese depth, growing nearshore footprint, product engineering capability and a willingness to reshape commercial terms. Buyers should test the combination rather than awarding points for each logo separately.

Engineering services raise the cost of error

Enterprise application defects can delay invoices or inconvenience staff. Embedded and automotive defects can affect physical behaviour, safety obligations and product recalls. FPT's expansion into engineering services therefore tests whether its quality system works outside conventional enterprise software.

The identity boundary is particularly important here. FPT announced a separate US-based company,FPT Automotive, in December 2023 to focus on automotive software. The announcement described work on infotainment, electronic control units, safety and security, interfaces and connectivity, and referenced thousands of engineers across the broader operation. This specialist company is part of FPT's strategic context; it is not the same legal entity as FPT Software Company Limited. An automotive buyer must establish which entity supplies the engineers, owns the process assets and signs the warranty.

There is independent evidence that FPT Software has participated in significant aerospace data work. Airbus stated in 2018 that it had signed an agreement with FPT Software to help extend theSkywise aviation data platform in Asia, including training and application development. Airbus later included FPT in the first group of global IT services leaders admitted to its Skywise partner programme. This confirms a relationship and a work domain, not current scope or performance.

FPT also stated in January 2026 that multiple sites in Vietnam had renewed aTISAX assessment labelfor automotive information security. TISAX is relevant because automotive clients use it to exchange assessment results. Its value is scope-specific: the location, assessment objectives and validity matter. It does not establish that every FPT automotive project is safe, nor does it replace product-specific evidence of functional safety and cybersecurity.

AI assistance in engineering work intensifies the acceptance problem. A generated unit test for a web form and a generated test for an electronic control function do not have the same consequence. A buyer must require traceability from requirement to implementation to verification, separation of development and approval roles, tool qualification where necessary, and explicit rules for artefacts that may be produced with automated assistance. The economic gain of faster generation must never be allowed to implicitly redefine the safety case.

This is where FPT's large workforce can become an advantage if it funds specialisation. Domain engineers, security reviewers, safety specialists and local client teams can provide controls that a small, low-cost provider cannot. It becomes a liability if scale is used to substitute interchangeable capacity for scarce expertise. The relevant metric is not how many engineers can be assigned. It is how many have demonstrated authority in the client's domain, how much of their time is guaranteed, and who can stop a release.

The contract decides who owns the gain

FPT does not publish a general pricing grid in the documents examined. One industry page acknowledges conventional forms oftime-and-materials and fixed-price or project-basedpricing, while its 2026 Digital Foundry material proposes a wider set of outcome-oriented structures. This leaves pricing highly specific to scope, location, skill, platform, duration and risk allocation.

Time-and-materials is not intrinsically obsolete. It is often rational when requirements are uncertain and the client wants to control priorities. The danger is weak productivity governance: an AI-assisted team may complete work faster while the client keeps buying the same nominal capacity. A good contract makes the gain visible through throughput, quality and delivered scope rather than assuming busy people equal value.

Fixed price transfers some estimation risk to FPT, but only inside a stable scope. Modernisation rarely has one. Vendors protect themselves through assumptions, exclusions and change requests. The headline price may be fixed while data cleansing, interface remediation, environment delays, performance work and extra acceptance cycles remain chargeable. AI can help FPT estimate code conversion, but it cannot remove unresolved business decisions.

Story-point velocity pricing attempts to align payment with delivery. It also creates measurement problems. Story points are a team-relative planning tool, not a universal unit. The vendor can influence how work is decomposed and estimated. A point may represent a useful business change or technical work the client never sees. If FPT offers this model, the parties need a stable reference team, backlog refinement rules, anti-inflation controls, quality gates and a definition of 'delivered' that requires accepted, deployable software rather than completed development activity.

Application support with volume bands and prevention credits is more promising. It can reward FPT for reducing recurring incidents rather than profiting from ticket volume. The baseline still matters. Tickets can fall because root causes have been eliminated, because users have stopped reporting, because categories have changed, or because work has been moved to an excluded queue. Credits should be tied to service health, recurrence, severity and user impact, with verifiable classification.

Hybrid capability can transition: the client pays for a core team while selected outcomes carry a risk share. This is close to FPT's published transition proposal, which starts with a measured pilot under familiar commercial terms and evolves to outcome-based pricing after baseline establishment. The sequence is sensible because neither party should price an uncertain productivity effect before measuring it.

Whichever model is used, nine allocations determine whether AI productivity becomes shared value or hidden risk.

First, the baseline. FPT and the client must agree on pre-assistance cycle time, defect rate, rework, deployment frequency, review effort and cost for a representative period. A baseline assembled after the pilot invites selective comparison.

Second, the completion unit. Payment should be attached to business-accepted capability, stable operation or a clearly bounded service outcome. Generated code, closed tasks and test counts are intermediate evidence, not outcomes.

Third, acceptance. The contract must state test environments, data sets, tolerances, security thresholds, performance loads, reconciliation rules and the time allowed for review. Deemed acceptance should not activate simply because a client lacks people to inspect a sudden volume of automated output.

Fourth, warranty and latent defects. A defect discovered after acceptance may come from a misread existing rule, a generated implementation, a migration script or an incomplete test. The warranty must not exclude failure simply because the client approved a demonstration. Material defects need cause-based allocation and a duty to preserve evidence.

Fifth, intellectual property. The agreement must identify FPT's pre-existing accelerators, client-specific work, third-party components and generated material. It must require software composition analysis, licence compliance and disclosure of any tool whose terms could affect ownership or confidentiality. An indemnity is only as useful as its scope, cap and survival period.

Sixth, data and model usage. Client code, tickets, architecture diagrams and production logs may contain trade secrets, credentials and personal data. The buyer needs a list of approved services, hosting locations, retention periods, training restrictions, subcontractors, access controls and deletion evidence. 'Private' or 'enterprise' labels are not contractual controls.

Seventh, security responsibility. FPT must be accountable for secure configuration and development within its control, prompt notification, investigation support and remediation. Exclusions for cloud and platform must not eliminate its duty to design defensively or coordinate recovery.

Eighth, productivity sharing. If FPT reduces effort significantly, does the economy reduce the price, broaden the scope, improve the margin or fund stronger assurance? Any answer can be legitimate if agreed. Silence usually leaves the client paying old labour prices for a new cost base.

Ninth, exit. Outcome-based pricing can create the strongest lock-in because the client sees less of the underlying team and method. The contract must fund documentation, knowledge transfer and ongoing exportation as a continuous activity, not an urgent last-month task.

FPT's commercial transformation will be credible when these conditions become normal rather than bespoke concessions won by sophisticated clients. Until then, 'AI-first' describes a sales direction more clearly than a standard allocation of accountability.

Labour leverage becomes a quality-control problem

Vietnam remains central to FPT's economics. The country offers a large and growing technology workforce at lower cost than major client markets. FPT can recruit at scale, train engineers through group-linked education channels, develop Japanese-language capability and spread specialist investments across many accounts. The World Bank'sServices Unboundreport presents FPT as an example of a regional firm using cross-border service delivery to move into higher-value research, software engineering and support.

The same World Bank report warns that advanced digital services require higher skills, while its 2025 report on Vietnam indicates that the country needs to move into more sophisticated services and addressshortages of advanced capabilities. FPT is exposed to this constraint at a larger scale than most of its local competitors. Each major expansion into Japan, North America, cloud, SAP, automotive or AI requires people combining technical depth with domain knowledge, language and client authority.

Traditional offshore delivery often uses a pyramid: many junior engineers, fewer experienced leads and a small senior layer. FPT's Digital Foundry material proposes a more diamond-shaped workforce where automation absorbs routine work and a wider middle layer directs and validates it. Economically, this is plausible. It also creates a transition risk. Junior work is how future senior engineers learn a system. If automated tools perform the first draft, diagnosis and documentation, FPT must redesign learning rather than simply remove the bottom tier.

Quality control can fail in two opposite ways. Too little supervision lets plausible but wrong output into the product. Too much supervision consumes the productivity gain. The optimal review intensity varies by task, client and consequence, making a single productivity target misleading. FPT needs a risk-based control model and enough senior staff to operate it.

Attrition and turnover add another dimension. FPT's public documents examined do not disclose current attrition for the legal entity, distribution by seniority, average tenure by market or the proportion of subcontractors. These are important because a vendor can meet headcount commitments while losing accumulated knowledge. AI-assisted documentation may reduce dependence on individuals, but it can also hide superficial understanding until an abnormal incident occurs.

Client concentration interacts with workforce control. Large multi-year contracts can justify dedicated academies, stable teams and reusable controls. They can also attract senior staff away from smaller accounts and make FPT dependent on successful renewals. The reported USD 256 million and USD 100 million deals increase the importance of portfolio-level governance: who decides which accounts get the scarce architects, security reviewers and bilingual leads?

Due diligence is therefore not a tour of a large delivery centre. It is a cohort analysis: named key roles, committed allocation, tenure on similar systems, planned replacements, review ratios, training pathways, subcontractor share and evidence that incident lessons change delivery practices. Workforce scale is valuable only if the organisation can keep its knowledge and authority aligned with client outcomes.

Security credentials are perimeters, not umbrellas

FPT publishes a set of security and process credentials. In February 2026, it announced HITRUST r2 certification for a defined scope covering application services, database and deployment systems, and its Hanoi data centre, along with an AI-focused security certification. TheHITRUST announcementis significant for the listed environment. It should not be represented as a universal certification for all offices, acquired companies, cloud configurations or client projects.

FPT also announced Cyber Essentials and Cyber Essentials Plus certifications in June 2026, and aCMMI maturity level five re-appraisalin 2023 that it says is valid until October 2026. CMMI is evidence of assessed process maturity within its appraisal scope. It does not prove that a particular release is secure, that requirements were correct or that an acquired delivery unit follows the same practice.

The company'sdata protection policydescribes access control, cross-border processing, protection and retention principles. Its policy library also lists governance documents related to business continuity and AI. Published policies establish intent and provide a basis for contractual questions. They are not operational evidence. A buyer must ask for the version of the policy incorporated into the engagement, audit results, exception registers, recovery tests and proof that controls extend to every delivery location and tool.

No credible complete public incident history or central service-status archive for FPT Software was identified in the sources examined. This is a limitation of evidence, not proof that the company has had no security incidents or outages. IT service failures can also occur in client environments and never appear as a vendor-level event. Sourcing must request multiple years of material security and availability incidents relevant to the proposed service, including near misses, root causes, client notifications and corrective actions, subject to legitimate confidentiality constraints.

AI-assisted delivery creates additional attack and leakage surfaces. Source code may be exposed through a tool connector. Malicious instructions may enter through tickets, documents or repositories. Generated dependencies may carry vulnerabilities or incompatible licences. Automated remediation may make a broad change faster than a human team can review it. These risks require technical controls – isolated environments, least privilege, secret scanning, dependency review, signed artefacts, audit logs and restricted data use – as well as an incident clause that treats the AI service as part of the delivery environment.

Business continuity deserves equal attention. A 'best-shore' model can route work between locations, but not all roles are fungible. A disaster affecting one centre in Vietnam, a regional network, a critical cloud service or a specialist review team can disrupt the same engagement in different ways. FPT must show tested recovery for the client's actual toolchain, people, credentials and communication pathways, with recovery time and recovery point objectives that match the contract. A generic business continuity certificate cannot answer whether a named application can be restored and supported.

Exit is a deliverable, not a termination clause

The deepest switching cost in software services is rarely the notice period. It is the accumulated context.

Over a multi-year programme, FPT may learn why a client tolerates a particular data inconsistency, which interface fails at quarter-end, how a Japanese business unit approves changes, which cloud boundary matters, and which test is unreliable. Some of this knowledge enters code and documentation. Another part stays in tickets, discussions, tool configurations or individual memory. The more effectively FPT uses its own analysis and automation environment, the more it matters who gets to use the resulting knowledge.

Platform choices add structural lock-in. SAP customisations, Dynamics extensions, hyper-scaler services and vendor accelerators each have a different exit path. Moving to another vendor may be technically possible but economically unattractive because the replacement must recreate the credentials, tools and unwritten context. An internal team may face the same difficulty.

FPT claims that its system logical models and automated documentation can reduce dependence on individuals. This could improve portability if the artefacts are accurate, current and exportable. It could worsen lock-in if the client receives only reports while the working model stays inside a proprietary FPT environment.

A credible exit package must be built during delivery and tested before termination. It must include current source repositories; build and deployment instructions; infrastructure definitions; architecture decisions; interface and data models; test suites and test data rules; software bills of materials; security findings and accepted exceptions; operations manuals; service history; known defects; model and tool configuration needed to reproduce material outputs; audit evidence; licence inventories; and a comprehensible backlog.

Credentials must be transferred securely, client data must be returned or deleted, and FPT must attest to deletion at subcontractors and work locations.

The contract also needs a transition capability. Named staff must be available for a defined period, with service levels maintained during knowledge transfer. Fees should be predictable rather than negotiated after leverage has shifted. If an incoming vendor is involved, FPT must cooperate under confidentiality and security rules. The client should be able to test the package by asking an independent team to build, deploy and diagnose a representative component before the main contract expires.

Exit design is not anti-vendor. It can make a longer relationship easier to approve because the client knows it retains the power to act. For FPT, strong portability would also support the claim that its value lies in the continuing quality of delivery, not in captivity.

A sourcing test designed for FPT's bet

A conventional request for proposal will produce conventional responses: office count, certifications, partner levels, hourly rates and selected references. FPT's AI-assisted modernisation claim requires a more demanding test.

Start with legal and operational identity.Require FPT Software Company Limited to identify the signing entity, delivery subsidiaries, subcontractors, hosting providers and access countries. Ask which acquired companies or specialist group companies will supply people or intellectual property. Map each obligation – security, warranty, indemnity, insurance, data deletion and transition – to the entity that can actually perform it.

Choose a representative pilot, not a showcase.The pilot must contain undocumented logic, interfaces, imperfect tests and a significant non-functional requirement. It must be small enough to control but similar enough to the target system for the result to matter. A greenfield demo or isolated coding exercise will overstate the benefit.

Freeze the baseline before assistance starts.Record current effort and outcomes for comparable work: discovery time, cycle time, defects by severity, test coverage that reflects behaviour rather than line counts, review hours, rework, security findings, deployment failures and recovery time. Agree who owns the measurement and how exclusions are approved.

Separate generation from assurance.FPT must disclose which tasks use automated assistance and which require independent human approval. Reviewers must have authority, domain context and sufficient time. The buyer must sample decisions and reproduce critical outputs. A pass rate supplied by the same delivery process is not independent assurance.

Test system understanding.Give FPT several known edge cases and a hidden dependency. Ask it to reconstruct the relevant business rules, data flows and operational consequences. Compare the output with experienced maintainers. This tests whether the method finds meaning rather than simply producing documentation.

Test change impact.Introduce a realistic requirement change after the initial plan. Measure whether FPT identifies the affected services, tests, data, controls and support documents. Legacy modernisation is dominated by change; a method that works only on a frozen snapshot will fail commercially.

Measure end-to-end outcomes.Track accepted capability, escaped defects, production stability and business reconciliation, not just code completion. Include client review effort. If FPT saves 100 development hours but consumes 120 additional hours of scarce business specialists, the project has not become more productive.

Inspect the evidence chain.For a sample of material changes, require the requirement, source context, proposed implementation, human decision, test result, security review and deployment record. The evidence must survive a tool version change and remain usable outside the FPT environment.

Define approved AI use.List permitted models and services, hosting and data locations, retention, training restrictions, subcontractors, access controls and change notification. Require a process for newly discovered vulnerabilities, licence concerns and inaccurate generated material. Prohibit silent substitution of a tool that changes the risk profile.

Challenge the commercial unit.If FPT proposes story points, ask how estimates are standardised and audited. If it proposes incident bands, inspect classification and recurrence rules. If it proposes fixed outcome, list assumptions and change triggers. Model three cases: expected productivity, no productivity gain and a quality failure requiring substantial rework. The contract must remain viable under all three.

Make accountability follow control.FPT must bear responsibility for choices and artefacts within its control, including its automation environment. Client approval must not nullify liability for hidden defects, security negligence or failure to meet agreed controls. Caps, exclusions and service credits must reflect the consequence of service, not just annual fees.

Verify talent rather than count it.Interview the proposed architect, service manager, security lead and key bilingual staff. Examine their allocation, replacement rules and relevant work. Ask how junior engineers develop judgement when automated tools perform routine tasks. Require notice and approval for material role changes.

Define every credential.Map HITRUST, TISAX, CMMI, cloud partner status and other evidence to the locations, systems, dates and services in the proposal. Obtain recent reports or letters under confidentiality as applicable. A credential that does not cover the delivery environment should be treated as supporting context, not proof of control.

Run a recovery exercise.Simulate the loss of a delivery location, cloud dependency or key specialist. Require FPT to restore access, rebuild current state and continue priority service within the proposed objectives. Include client communication and decision authority.

Run an exit exercise before award.Ask FPT to provide a specimen export from its code intelligence and delivery environment. Have a separate team build or understand from it. Price the transition assistance, define deletion evidence and identify artefacts that cannot be transferred. Non-exportable knowledge must be treated as a lock-in cost in the business case.

Speak to comparable clients, including a troubled reference.Ideal references share geography, legacy complexity, platform and regulatory stakes. Ask about estimation accuracy, senior attention after contract signing, defect ownership, change-order behaviour, staff turnover, incident transparency and exit readiness. A reference selected only for satisfaction will reveal little about accountability under stress.

This test is demanding because FPT's proposition is ambitious. A vendor that wants to be paid for certainty should be willing to show how certainty is measured, governed and restored when something goes wrong.

What to watch

The first watch point is the conversion of aspiration into revenue. FPT has set an AI-first revenue target of one-third and a productivity ambition of 30%. Future disclosures should clarify what qualifies as AI-first, whether the figure is signed or recognised revenue, and whether clients are paying for outcomes or simply receiving assisted delivery under old contracts.

The second is quality alongside speed. FPT should increasingly disclose accepted cycle time, escaped defects, rollback, incident recurrence, review effort and client-side work. Productivity without these measures can hide displaced effort.

The third is Japan. Its 44% share of the parent segment's 2025 regional composition makes growth, currency, local hiring and client retention material. Evidence that FPT can continue to extend its local authority while using Vietnamese scale would support the model.

The fourth is large contract execution. The USD 256 million and USD 100 million deals demonstrate reach, but their unnamed status limits external verification. Renewals, expansions, provisions, delays or unusual working-capital movements would be informative.

The fifth is workforce shape. Watch for evidence that the proposed diamond model is real: more experienced reviewers and domain specialists, redesigned training for junior staff, and lower dependence on a few bilingual leads. Headcount growth alone will become less meaningful.

The sixth is scope discipline. Acquisitions and specialist subsidiaries broaden the offer, but clients need clarity on which entity delivers. A more transparent mapping of subsidiaries, locations and certifications would reduce diligence friction.

The seventh is incident transparency. A central status history, scope-defined security disclosures and meaningful corrective-action summaries would make FPT's managed-service claims easier to assess without compromising client confidentiality.

The eighth is portability. If Flezi and related tools become central to delivery, FPT should publish clearer export, retention and client ownership terms. The best proof that system certainty belongs to the client is that the client can leave with it.

The accountability test

FPT Software has already travelled further than the 'Vietnamese subcontractor' label suggests. Its history encompasses Japanese corporate relationships, US consultancy acquisitions, European and Latin American delivery capabilities, cloud and ERP partnerships, managed services, product engineering and large end-to-end contracts. The parent company's disclosures show a business operating at significant global scale, with Japan as an unusually strong base.

Its next move is not guaranteed by that history. AI assistance attacks the simple economic logic of selling large amounts of engineering time. If less labour is needed per unit of output, FPT must either give up revenue, absorb the gain in margin, broaden the client's scope or persuade the client to pay for a better outcome. The company has chosen to argue for the outcome.

This choice raises the bar for evidence. FPT's own documents describe governed automation, human approval, system logical models, prevention credits and outcome-based pricing. These are credible design elements. Public evidence does not yet show how often they produce faster accepted modernisation, what the full distribution of outcomes looks like, or how FPT assumes accountability when the automated method is wrong.

The unresolved question is not whether AI can write code. It can. Nor is it whether Vietnam remains a valuable engineering base. It does. The question is whether FPT can combine low-cost scale, senior judgement, local client authority and machine assistance into a delivery system whose evidence is strong enough for a client to sign acceptance – and whose contract still holds when acceptance proves wrong.

If FPT succeeds, it can move from offshore capacity provider to accountable operator of enterprise change. Japan gives it relationship depth, Vietnam gives it engineering leverage, acquisitions give it proximity and specialist reach, and its tool investment gives it a chance to preserve knowledge across large programmes. This combination could be hard to copy.

If it fails, automation can expose the weakness of the old model. Coding hours will become cheaper, review will remain scarce, defects will cross organisational boundaries, and clients will discover that 'outcome-based' pricing did not actually transfer outcome risk. The vendor may then have more sophisticated tools but less pricing power.

The decisive artefact will not be a generated application, a partner badge or a productivity slide. It will be a contract and an evidence file that connect every requirement to an accountable decision, every decision to an accepted outcome, and every outcome to a clean exit path. FPT Software's AI strategy is ultimately a bet that it can sell fewer hours and carry more accountability. Buyers should judge it on accountability, not on hours.