For manufacturers comparing a Hanoi system development partner, company size and day rates are not enough. Projects spanning production, quality, inventory, equipment and accounting need more than a polished demonstration in which an API connects once. The delivered system must keep data reconcilable during exceptions, stop and recover safely, and leave source assets and operating responsibility with the client. This guide turns that objective into a one-page pre-RFP brief, vendor operating model, RFP deliverables, a proposed 100-point score, a blank TCO worksheet, a proposed 12-week acceptance sequence, FAT/SAT/UAT evidence, and contract and exit terms.
Executive answer: buy acceptance evidence, not just engineering capacity
An outsourced project can fail even when its code runs. A normal scenario may pass while month-end reconciliation fails; a retry after a network break may create a duplicate; equipment and ERP clocks may disagree; an exception approval may never be implemented; or nobody may be able to deploy after the vendor’s key engineer leaves. These are failures of an undefined boundary.
Evaluate five things as one acceptance system:
- Which factory decision is supported by which system of record?
- Which system owns each field, and who approves a change?
- What evidence accepts normal, abnormal, offline and recovery behavior?
- Who owns monitoring, first response, root-cause analysis, change and retest after go-live?
- How will source, configuration, data, keys, procedures and open issues be returned at exit?
A company profile is only an entry point. The final comparison is whether requirements, design, tests, operations and handover can be traced with shared IDs. A Hanoi office is not itself a quality guarantee; assess the people actually assigned and the artifacts the client can reproduce.
Why Hanoi vendor delivery governance matters now
Hanoi’s official English portal reported that the city’s digital economy was estimated at 16.7% of GRDP in the first half of 2026—about US$5.5 billion and 10.6% higher year on year—with a target of 22% by the end of 2026. The same report cited about US$2.22 billion in science-and-technology-related industries and 68% of registered FDI through 26 June. These are city-level estimates and targets, not evidence that any individual vendor can deliver.
The capital’s Decision 3806/QD-UBND is described as a 2026–2030 digital economy and digital society program. Vietnam’s Ministry of Industry and Trade also discussed smart manufacturing and digital transformation through an August 2026 forum and the program under Decision 2708/QD-BCT. An official MoIT institute summary attributes to Decision 840/QD-TTg government program targets of at least US$300 billion in digital-technology-industry revenue and average annual growth of at least 12% for 2026–2030. These are government targets, not forecasts or guarantees of project return.
More activity can mean more potential suppliers and a wider range of technology choices. That makes it even more important to avoid assumptions such as “Hanoi is inexpensive” or “a growth market is safe.” Select by who owns factory integration boundaries, what will be tested, and what will be handed over. For the countrywide delivery model and general comparison questions, see Vietnam system development in 2026. This article starts at the next decision: narrowing Hanoi candidates through factory-integration acceptance evidence.
Build a one-page pre-RFP brief
Before asking vendors for proposals, the client should freeze a one-page project brief. It is not a complete specification. It is the baseline that makes every bidder answer the same problem.
| Field | What to record | Accountable owner |
|---|---|---|
| Business outcome | Which decision or process should improve, and how it will be measured | Factory/business owner |
| Scope boundary | Factory, line, item, language, shift and exclusions | Process owner |
| System boundary | ERP, MES, WMS, QMS, equipment, forms and external services | IT owner |
| System of record | Master source for item, BOM, order, actual, stock and quality data | Data owner |
| Critical conditions | Safety, close, traceability, stop, recovery, personal and confidential data | Quality/legal/security |
| Decision condition | When, who and what evidence decides GO, REWORK or STOP | Sponsor |
“Replace the current system” is too broad. A useful statement is closer to: “Collect production actuals from Line A, match them to approved work orders, transmit them to ERP without duplication after a network interruption, and let factory staff review a daily reconciliation.” That sentence makes input, decision, output, exception and reconciliation visible.
For package capabilities and production-management-specific RFP content, use the Vietnam production management system RFP guide. The focus here is the delivery governance of a development company connecting factory operations and multiple systems.
Choose the Hanoi vendor operating model first
There are two broad delivery models. Neither is always better; the choice depends on internal PMO and architecture capability.
| Model | Integration accountability | When it fits | Main caution |
|---|---|---|---|
| Single accountable integrator | The Hanoi prime contractor coordinates design, integration, tests and migration | The client PMO is small and wants one boundary owner | Contract subcontracting, knowledge concentration and asset recovery at exit |
| Client-led multi-vendor | The client PMO integrates ERP, MES, equipment and cloud vendors | The client has an architect and test lead | The client must control gaps, blame shifting and version drift |
“Single accountable” must not mean “unmanaged.” The client retains approval of architecture, access, acceptance and system-specific decisions. In the multi-vendor model, the interface register, RACI, integrated test environment, defect triage and change board become mandatory client PMO functions.
In both models, review the real project manager, business analyst, architect, developers, QA, DevOps, security lead and site-startup staff—not only the sales team. If names cannot yet be fixed, require capabilities, allocation, substitution conditions, handover time, languages, factory-access eligibility, and after-hours boundaries.
Split data and legal responsibility at field level
Calling everything “client data” hides important differences. Item codes, BOMs, work orders, machine signals, operator IDs, inspection values, defect images, maintenance records, costs and customer drawings need different ownership and controls.
| Subject | The client decides | The vendor proves | Acceptance evidence |
|---|---|---|---|
| Meaning and record | Source system, unit, timestamp, precision and code scheme | Mapping, conversion, missing and duplicate handling | Data dictionary and reconciliation result |
| Purpose | Permitted use in build, test, operations and analytics | Architecture and access preventing other uses | Access list, logs and configuration |
| Storage and transfer | Region, cross-border transfer, retention, deletion and backup | Actual location, path, deletion and restore procedure | Architecture, deletion proof, recovery record |
| Personal/confidential | Classification, masking and viewing approval | Least privilege, secret handling and incident response | Access tests, audit log and training record |
| Exit | Return format, destination and deletion deadline | Complete export and residual-copy treatment | Receipt, deletion confirmation and key revocation |
Vietnam’s Law 91/2025/QH15 on Personal Data Protection was issued on 26 June 2025 and took effect on 1 January 2026. Law 71/2025/QH15 on the Digital Technology Industry was issued on 14 June 2025 and also took effect on 1 January 2026. Those dates do not establish the specific duties, cross-border position, filing, contract clause or data-subject process for a particular project. Confirm applicability against the actual data, people, processing, location, sector and contract with qualified Vietnamese counsel and privacy and security specialists.
Give each RACI decision one accountable owner. The client should not outsource the determination of whether information is personal data: the client’s data owner and legal function can remain Accountable, while the vendor is Responsible or Consulted for implementation. The vendor can own execution of access logging and deletion procedures. Decision accountability and execution responsibility should not be blurred.
Require eight RFP deliverables
An RFP should order artifacts and evidence, not merely ask “Can you do this?” The following register is a proposal example and should be adjusted for the project.
| ID | Deliverable | Minimum content | Acceptance evidence |
|---|---|---|---|
| D01 | Requirements traceability register | Business and non-functional requirements, criticality, design and test IDs | Every requirement has an owner and test |
| D02 | Integration and data design | Record owners, API, batch, event, time, retry and reconciliation | Representative data traced end to end |
| D03 | Security design | Threats, authentication, roles, secrets, logs and vulnerability treatment | Review, tests and remediation record |
| D04 | Source and build assets | Source, dependencies, configuration, IaC, build and SBOM-equivalent information | Rebuild in a clean environment |
| D05 | Test pack | FAT, SAT, UAT, performance, recovery and security | Raw logs, results, defects and retests |
| D06 | Migration and cutover plan | Initial load, delta, freeze, reconciliation and rollback | Rehearsal and decision record |
| D07 | Operations pack | Monitoring, alerts, runbook, SLA, change and support roster | Client repeats incident and recovery drill |
| D08 | Handover and exit pack | Asset list, training, keys, open issues, return and deletion | Client or successor reproduces operations |
For each artifact, define format, language, draft date, approver, correction allowance and final repository. Replace “full documentation” with named repositories, API specifications, data dictionaries, test evidence and monitoring definitions. Reusing the D01–D08 IDs in estimates, contracts, sprints, issues, acceptance and payment milestones makes scope changes traceable.
A proposed 100-point score with separate critical gates
The following allocation and 70-point pass mark are a proposal example, not an external statistic, industry benchmark or legal standard. Adjust them to the system’s importance, safety profile and client capability.
| Evaluation area | Proposed points | Evidence reviewed |
|---|---|---|
| Factory process and requirements | 20 | Scenarios, exceptions, systems of record, exclusions, decision makers |
| Integration and data design | 25 | API, retry, deduplication, time, reconciliation, migration and performance |
| Quality and security | 20 | Test design, defects, threats, roles, logs and recovery |
| Delivery, operations and transfer | 20 | Source, build, monitoring, runbook, training and exit |
| Team and commercials | 15 | Assigned people, allocation, change, TCO, contract fit and continuity |
| Total | 100 | Evidence-based comparison |
As an example, 70 points may advance a candidate, but critical gates should never be averaged away. Unauthorized extraction of secrets, shared privileged IDs, inability to restore critical data, retries that can double-post, disagreement on source handover, or inability to stop and roll back can be defined as non-compensable failures.
Scorers should include business, factory, IT, quality, security/legal and procurement perspectives. Record the proposal page, demonstration case or answer ID supporting each score. Ask for references by similar factory boundary, actual implementation scope, time in production, incidents and improvements, client responsibilities and handover—not by customer logos alone. Require proposed delivery staff to join scenario explanation and Q&A.
Compare TCO through the same blank worksheet, without invented market rates
Vietnam offshore development cost changes with requirement certainty, languages, site presence, legacy systems, data quality, security, infrastructure, testing and contract terms. This article does not invent currency amounts, day rates or market ranges. Have each bidder complete the same blank structure.
| TCO layer | Initial | Recurring | Unit and assumptions | Variability and ceiling |
|---|---|---|---|---|
| Discovery and design | Factories, workflows, languages and workshop count | Added scope and redesign | ||
| Build and integration | Screens, APIs, equipment, reports and data volume | Specification change and connection limits | ||
| Test and migration | FAT/SAT/UAT, environments and rehearsals | Retests and extra data | ||
| Platform and licences | Cloud, database, monitoring and third parties | Usage, price change and exchange rate | ||
| Operations, transfer and exit | Support hours, SLA, training, travel and maintenance term | After-hours, emergency and vendor change |
Separate fixed and variable fees, taxes, travel, third-party charges and environment-specific costs. Link payment to agreed evidence gates where appropriate, while aligning retention and payment clauses with legal and procurement review. A low initial quote can become expensive when test environments, data preparation, monitoring and handover are excluded as “client responsibility.”
Turn ISO/IEC 25010 and OWASP ASVS into acceptance language
ISO/IEC 25010:2023 defines a product-quality model with nine characteristics and can provide shared vocabulary for requirements, testing and acceptance. It does not mean certification is mandatory for every project. Use relevant characteristics to write measurable acceptance criteria.
Functional suitability should include approval, cancellation, retry and reconciliation, not only a happy path. Performance efficiency should define peak load, equipment count, batch window and timeout, not only an average. Reliability can be tested with network loss, API failure, restart and backup restore. Maintainability includes change impact, automated tests, reproducible builds and diagnostic logs. Compatibility includes coexistence and interoperability with ERP and equipment.
The OWASP Application Security Verification Standard is a catalogue of verifiable technical application-security requirements that can be referenced in procurement contracts. ASVS 5.0.0 was released on 30 May 2025. Select levels and requirements for the exposure, data, threats and connections of the system. Do not accept a single phrase such as “ASVS compliant”; list applicable requirement IDs, exclusions, test method, evidence and residual risk. ASVS alone does not guarantee organizational, cloud, network, legal or operational security.
Separate FAT, SAT and UAT by purpose
Running the same happy-path demonstration three times under different names adds little value. Give each test a distinct risk and signer.
| Test | Primary purpose | Place and conditions | Signer |
|---|---|---|---|
| FAT | The build satisfies design and interface specifications | Vendor-controlled environment, including simulated connections | Vendor QA and client IT |
| SAT | It works with actual site equipment, network, devices, time and roles | Target factory or equivalent environment | Factory IT, equipment and quality |
| UAT | Users can complete normal and exception work | Representative users, approvals and forms included | Process owner |
Every case should carry requirement ID, prerequisites, input, steps, expected outcome, tolerance, log location, executor, time, version, actual result and defect ID. Keep API logs, database reconciliation, monitoring events and audit trails in addition to screenshots. When test data contains production information, include authorization, masking, storage and deletion in the test plan.
Accept APIs, offline behavior and recovery by forcing failure
A factory cannot assume perfect cloud connectivity. Deliberately test:
- whether a retry duplicates a posting when the link fails after sending but before the response;
- how event order is restored when equipment, gateway, MES and ERP clocks or time zones disagree;
- what happens when a master-data version changes between send and receive;
- how queue priority, capacity, restart order and catch-up time are observed;
- whether operators can continue or stop safely when an external API slows or fails; and
- where reposting begins after restore, and how the result is reconciled.
The API contract should cover idempotency keys, correlation IDs, error classes, timeout, retry, dead-letter handling, order, maximum size, encoding, units, time and version compatibility. Define local storage volume, encryption, access, data-loss point, manual entry and post-recovery reconciliation for offline operation. “Retry is supported” is not an acceptance result; submit the same event more than once and prove the correct final state.
Contract observability and operating responsibility before development
After go-live, infrastructure uptime alone is not enough. Operations must observe delayed production actuals, unreconciled rows, duplicate candidates, queue buildup, master mismatch, access denial and unfinished batches.
| Event | Detection | First response | Root-cause analysis | Prevention approval |
|---|---|---|---|---|
| Integration stop | Monitoring and roster | Vendor or client operations | Development, platform and endpoint owners | Change board |
| Data variance | Daily reconciliation and factory | Process team | Data owner and development | Business and IT owners |
| Access anomaly | Security logs | Security team | IAM owner and development | Information security |
| Performance degradation | SLI and business clock | Operations | App, DB and network | Service owner |
The SLA should define Severity, response, workaround, recovery, permanent corrective action, customer-wait time and exclusions—not only ticket acknowledgement. Before acceptance, rehearse operational defects such as a responder without log access, no route to an endpoint vendor, or no factory decision maker.
For multi-site rollout, the overseas-site system rollout governance guide helps separate the common template, site variations, decision rights and rollout waves. A configuration accepted at one factory should not be copied without reassessing power, network, equipment, language, forms, shifts and legal requirements.
A proposed 12-week staged acceptance sequence
The following is a 12-week proposal example, not a standard duration, external benchmark or success guarantee. Extend or split it for legacy integration, equipment downtime, procurement, legal/security review and data quality.
| Weeks | Gate | Main work | Required evidence |
|---|---|---|---|
| 1–2 | SCOPE | One-page brief, observation, records, exclusions and RACI | D01 draft, decision makers and issue list |
| 3–4 | DESIGN | Integration, data, roles, threats, migration and test design | D02/D03, API contract and test register |
| 5–6 | BUILD | Representative flow, logs, build automation, unit and integration tests | D04, build record and code review |
| 7–8 | FAT | Normal, abnormal, performance, security and recovery | D05, defects, retests and version record |
| 9–10 | SAT/UAT | Site connections, offline, process exceptions and migration rehearsal | D05/D06, signatures and reconciliation |
| 11–12 | HANDOVER | Monitoring, incident drill, rollback, training, exit and decision | D07/D08 and GO/REWORK/STOP |
Possible proposal gates include execution of 100% of critical interface scenarios, zero open Severity 1 defects, completion of the agreed recovery drill, reproduction of deployment and rollback by a client operator, and reconciliation within the rule agreed for the project. These are examples, not universal thresholds. Some transactions require exact equality; other measurements need explicit rounding or sensor-tolerance rules.
At each gate, decide GO, REWORK or STOP. REWORK must identify defect IDs, owner, deadline, added-cost limit and retest scope rather than granting an indefinite extension. STOP includes recovery of source, data, configuration, logs, decisions and open issues, followed by revocation of access and keys.
Rehearse source, data and environment handover
Receiving files is not completed transfer. Prove that the client or successor can work without a vendor laptop or undocumented process:
- Obtain the specified tag from the governed repository.
- Separate dependencies from secrets and build in a clean environment.
- Explain DEV, UAT and PROD differences as configuration.
- Apply database changes and the required rollback procedure.
- Rerun automated and manual tests and reconcile results.
- Recreate monitoring, alerts, dashboards and log retention.
- Inject a failure, use the runbook to diagnose and recover, and produce the incident record.
The transfer inventory should include source, build definitions, IaC, dependency versions, licences, third-party accounts, domains, certificates, ownership and transfer procedure for API keys, database schemas and migrations, seed and test data, data dictionary, design decisions, known defects and backlog. Do not paste secret values into documents; prove vault ownership and access transfer.
Twelve contract, IP and exit checks
These are practical review points, not legal advice. Use qualified professionals for governing law, data, IP, tax, employment, trade and cloud issues.
- Deliverable IDs, format, language, version, due date, acceptance and remedy.
- Separation of background IP, project IP, reusable components, OSS and third-party assets.
- Rights to use source, configuration, design, tests, data dictionary and operating documents.
- Subcontractor disclosure, change notice, equivalent obligations and access.
- Purpose, storage, transfer, retention, deletion and incident response for personal/confidential data.
- Ownership of repositories, cloud accounts, domains, certificates, keys and admin IDs.
- Responsibility for vulnerabilities, OSS updates, end of support and emergency changes.
- SLA, Severity, contacts, on-site/remote and after-hours boundary.
- Estimate, impact analysis, approval, regression and documentation for change requests.
- Payment milestones tied to evidence, plus correction and retest after rejection.
- Early termination, transition help, data return/deletion and access revocation.
- Safety, data preservation and migration cooperation that continue during a dispute.
“Source code will be delivered” is insufficient. Confirm rights to use, modify, outsource and transition it. If proprietary platforms or reusable vendor components are required, define post-exit operating rights, alternatives, export format and transition period.
Common failure patterns and RFP prevention
1. Starting with the demo screen
A visible screen is easy to discuss, but records, exceptions and accountability fall behind. Review the one-page brief, data dictionary, integration sequence and test register before visual polish.
2. Scattering requirements across chat and minutes
Searchable decisions are not enough when they cannot be traced to implementation and tests. Keep a requirements register linking rationale, approval, impact and test.
3. Estimating “API integration” as one line
Authentication, version, limits, time, retry, order, duplication, errors, reconciliation and endpoint coordination disappear. Require a contract and abnormal test for each API.
4. Calling QA after build completion
Expected results become retrospective and ambiguity becomes a dispute between defect and change. Include QA and process owners during design and test requirements as they are written.
5. Treating cutover as a data-load date
Cutover includes freeze, delta, reconciliation, access, training, support, rollback and decisions. Rehearse roles and elapsed time.
6. Deferring the support contract
Monitoring and logs are omitted, leaving only developers able to diagnose. Include the operations pack and incident drill in build acceptance.
7. Concentrating knowledge in one person
Documents do not prove transfer. Have a substitute or client operator demonstrate deployment, tests and rollback.
8. Mistaking policy targets for vendor capability
Digital-industry growth targets provide market context. Verify each vendor through assigned people, artifacts, similar boundaries, test evidence and customer references.
Final checklist
- [ ] The one-page brief defines outcome, exclusions, systems of record, critical conditions and decision owner.
- [ ] Integration accountability is assigned under a single-integrator or client-led model.
- [ ] The actual PM, architect, QA and operations capabilities and allocation are reviewed.
- [ ] D01–D08-equivalent deliverables have format, date, approver and acceptance evidence.
- [ ] Purpose, storage, transfer, retention, deletion and roles are recorded by data field.
- [ ] Qualified specialists will confirm legal applicability from the project facts.
- [ ] The proposed 100-point score is separate from critical gates.
- [ ] Bidders complete TCO amount, unit, assumptions, variables, ceiling and third-party cost.
- [ ] Relevant ISO/IEC 25010 characteristics are translated into measurable requirements.
- [ ] OWASP ASVS IDs, exclusions, tests and evidence are specified.
- [ ] FAT, SAT and UAT have distinct purposes, environments and signers.
- [ ] Retry, duplication, order, time, offline and recovery are tested.
- [ ] Business observability, first response, root cause and change approval have owners.
- [ ] Client staff reproduce source, configuration, data, keys and runbook procedures.
- [ ] GO/REWORK/STOP and exit return, deletion and revocation are contracted.
FAQ: selecting a Hanoi system development company
1. Should we shortlist Hanoi vendors by price first?
Price matters, but an initial quote may exclude testing, data preparation, site startup, monitoring and handover. Ask every bidder to answer the same deliverables and blank TCO worksheet, then compare assumptions, variables and evidence. This article provides no invented currency or day-rate benchmark.
2. How do we verify a Hanoi IT vendor’s technical capability?
Use a similar factory boundary and ask the assigned team to explain and demonstrate records, retry behavior, exceptions, tests, monitoring, rollback and clean source rebuild. Credentials and a sales demo alone are insufficient; the client must be able to rerun the evidence.
3. Do Vietnam manufacturing projects need FAT, SAT and UAT?
The names are less important than acceptance of three different risks: the build, the real site and the user workflow. A small project may combine ceremonies, but it should preserve the relevant tests and accountable signers.
4. Does the proposed 12-week plan guarantee production go-live?
No. It is a proposal example for explaining evidence gates, not a standard or guarantee. Equipment access, legacy APIs, data quality, legal/security review and procurement may require extension or separate phases.
5. Is source-code delivery enough for Vietnam offshore development handover?
No. Include dependencies, build, configuration, IaC, database changes, tests, monitoring, key ownership, licences, known defects and runbooks. The client or successor should rebuild, deploy and roll back from a clean environment.
6. Can the development company own Personal Data Protection Law compliance?
It can perform agreed controls, but the client’s decision accountability does not automatically transfer. Confirm the applicability of Law 91/2025/QH15, roles, transfer, retention and contract terms with qualified Vietnamese legal and privacy specialists based on the project’s facts.
7. Is one contract sentence on ISO/IEC 25010 and OWASP ASVS enough?
No. Select relevant quality characteristics and ASVS requirement IDs, then define measurement, test environment, evidence, exclusions and residual risks. A named standard is vocabulary, not a guarantee.
8. Should the Hanoi company or a home-country company be prime contractor?
Location alone should not decide it. Compare integration accountability, factory support, contracts and language, architecture, QA, after-hours boundary, asset ownership and exit support. A strong client PMO may manage multiple vendors; a smaller PMO may prefer one accountable integrator.
Conclusion: move the selection table from schedule to reproducible evidence
When selecting a Hanoi system development company, local growth and development rates are secondary to accepting factory integration boundaries. Align bidders through a one-page brief, then trace D01–D08 deliverables, critical gates, a blank TCO, FAT/SAT/UAT, offline and recovery tests, observability, and source/data handover in one register. The proposed 12-week model is not a rush to production; it is a structure for evidence-based GO, REWORK or STOP decisions.
TOMAS TECH can support the early stage: defining the one-page brief, structuring RFP deliverables, mapping interfaces to existing ERP/MES/equipment, and designing acceptance and transfer conditions. You can contact us even while requirements are still being framed; share the target factory, current systems and operational concern as far as they are known.
References
- Hanoi Capital Portal / VGP, Ha Noi targets 22% of GRDP by end-2026, 30 July 2026.
- Hanoi Capital Portal, Decision 3806/QD-UBND digital economy and digital society program to 2030, 3 August 2026.
- Ministry of Industry and Trade, Smart manufacturing and digital transformation forum / Decision 2708/QD-BCT, 6 August 2026.
- Government of Vietnam, Law 91/2025/QH15 on Personal Data Protection, issued 26 June 2025, effective 1 January 2026.
- Government of Vietnam, Law 71/2025/QH15 on Digital Technology Industry, issued 14 June 2025, effective 1 January 2026.
- Vietnam Institute of Strategy and Policy for Industry and Trade, Decision 840/QD-TTg program summary, 17 July 2026.
- ISO, ISO/IEC 25010:2023 Systems and software quality models.
- OWASP, Application Security Verification Standard, ASVS 5.0.0 released 30 May 2025.
- Ministry of Industry and Trade, Supporting industries development program 2026–2035, 26 May 2026.
Sources checked 8 September 2026. Government numbers are published estimates or policy targets; they do not guarantee vendor capability, project outcomes or return on investment. The application of laws, standards and contracts depends on the project’s data, sector, processing, integrations and governing law. Check current primary documents and qualified professional advice before implementation. The 100-point allocation, 70-point guide, 12-week sequence and acceptance thresholds in this article are proposal examples, not external benchmarks.
