7 Things to Verify Before You Work With a Chinese Software Vendor

Look at what the vendor is made of, not just how the project is run

Most published advice about offshore development failure is about process: requirement granularity, progress reporting, acceptance terms. Those are things a buyer can improve through its own management. But some gaps cannot be closed by management. Whether the vendor has ever worked on a factory floor, whether it can produce documentation in your language, whether anyone answers the phone after handover — these are attributes of the vendor, and they do not change once the contract is signed.

So verification splits into two layers. The upper layer is project management. The lower layer is supplier eligibility. This article deals with the lower layer: the seven items that tell you what a vendor is made of before you commit. Few companies can answer all seven in writing, which is exactly what makes the list useful for narrowing a shortlist.

Seven items to verify before signing

• ① Shop-floor experience, not just IT outsourcing history — ask about PLCs, fieldbus and electrical control rather than a portfolio of delivered applications. Reading data out of equipment is a different kind of work from building a web system. Ask which PLC brands they have connected on a real production line and over which protocols, and the answer tells you immediately whether the experience is there.
• ② Working language and documentation language — the question is not whether an interpreter joins the meeting, but whether specifications and operating manuals can be delivered in English. Documents that operators cannot read will not be used after go-live. Ask whether the vendor has an English-speaking contact window that stays constant through the project, and whether it has delivered engineering documents in more than one language.
• ③ Whether the deliverable documents form a system — look for a full list from kickoff to maintenance, not a single design document. Project proposal, technical agreement, specification, I/O allocation table, address allocation table, network topology diagram, screen design document, operating manual, database table document, data interface document, test report, acceptance package, maintenance list, annual maintenance report — the differentiator is whether a vendor can put a list like this in front of you up front.
• ④ How information security and data handling are managed — connection method (VPN or dedicated line), access rights management, operation log retention, where source code and drawings are stored, and whether data stays in your country or is also held on the vendor side. Beyond the wording of the NDA, check whether they can describe this as a working procedure people follow day to day.
• ⑤ Whether a narrow pilot is possible — instead of ordering the whole scope at once, ask whether they will take on a pilot limited to one machine or one line. A vendor that refuses a pilot, or cannot explain how pilot cost relates to full-project cost, may not be used to drawing scope boundaries. Also confirm whether the pilot output can be reused directly as the basis for the full build.
• ⑥ Whether acceptance criteria can go into the technical agreement — not "implement the functionality", but measurable conditions such as the upper bound on data latency, the aggregation definition for each report, and whether data remains complete after a network recovery. A vendor that says "yes, we can write that in" on the spot is in a different position from one that offers verbal assurance.
• ⑦ How maintenance and response after handover are committed — contact window, response time, the scope of annual maintenance work, how line changes are handled, and how often reports are issued. If the vendor already has an annual maintenance contract template and a maintenance report format, you can see whether continuing support is a real practice.

Of the seven, ① ② ③ are vendor attributes and ④ ⑤ ⑥ ⑦ are things you can negotiate into the contract. When the attribute side is not satisfied, no amount of careful contract drafting reduces the load that lands on your own team.

Pure IT outsourcing versus a vendor with shop-floor background

Two companies can both call themselves software developers and still be strong at completely different stages. This comparison is not about which type is right; it is about knowing where the effort accumulates in a plant system.

The table above contrasts tendencies; it is not an assessment of any individual company, and some vendors genuinely combine both characters. Your basis for judgement is not the category but the substance of the answers to items ① through ⑦.

Fix the document list before signing, not later

The moment friction usually appears in a plant system is when someone realises after go-live that a particular document does not exist. Staff changes, equipment upgrades, a second-phase extension — in every one of those situations, the range of documents you hold is the range of work you can handle yourself. Documentation is not an attachment to the deliverable; it is a deliverable.

The check is simple: before signing, ask the vendor to list the documents it will deliver. If no list appears, or the reply is "we provide the usual set", there is probably no system behind it. A vendor that does have one can present the list in categories like the following.

• Planning and contract: project proposal, technical agreement, specification — documents that define scope and acceptance conditions
• Design: I/O allocation table, address allocation table, network topology diagram, screen design document — documents that define where each signal comes from and how it is displayed
• Operation: operating manual, database table document, data interface document — documents your operators and IT department use after go-live
• Verification: test report, acceptance package — documents that show the agreed criteria were met
• Maintenance: maintenance list, annual maintenance report — documents that record post-handover work scope and what was actually done

Five things to observe during a narrow pilot

Even with written answers to all seven items, you still cannot see how the working relationship will feel. Placing a scoped pilot first exposes in weeks what no document package shows. Vendors that work in a structured way run engagements in distinct stages — diagnosis, pilot, implementation, acceptance, maintenance, extension — so carving out the pilot stage alone is a request they can accommodate.

One machine or one line is enough for a pilot. What you observe is not only the quality of the output, but the five points below.

• The questions they ask — do they come back to confirm site conditions, or take the requirements document at face value and proceed
• Speed and form of response — do answers stay verbal, or are they left behind as documents and diagrams
• Granularity of documentation — is pilot-stage material still readable when you come back to it later
• How changes are handled — do they state the impact scope before acting, or quietly rebuild
• Actual quality of the English documents — do they read like raw machine translation, or like text an operator can follow