Why do technical constraints surface so close to delivery?
Technical constraints surface late because nobody has an incentive to state them during the sale. Proposals and contracts focus on features and timelines. "What this system will not do" rarely gets its own section.
For the vendor, stating limits feels like weakening the bid, especially when a competitor is promising everything. For the buyer, without knowing what to ask, there is nothing to check against. The result is a silence both sides quietly accept, often with a familiar reassurance: "Let's launch first and handle it in production."
That silence usually breaks in one of three ways:
- Late budget overruns: near the end of the project, the database design turns out unable to handle real load, and the core has to be redesigned.
- Launch-day incidents: load limits were never measured, and the system overloads on the day of a major campaign.
- AI chatbot hallucinations: the data the AI is allowed to answer from was never scoped, and real customers receive wrong information.
Who pays when constraints stay unspoken?
An unstated technical constraint hurts all three parties in the delivery chain, not only the buyer.
Vendors avoid stating limits for two reasons: fear of losing the deal, and a lack of architecture analysis skills to see the limits early. The second is more dangerous, because the vendor is not hiding anything. They simply don't know yet.
5 questions that bring technical constraints out before signing
The most reliable way to see technical constraints is to ask for them directly, with questions that can be verified. These five work with any vendor, including VAON.
- “Which parts of this proposal have already run in production elsewhere, and which need a PoC?”
A good answer splits the two clearly. A PoC (Proof of Concept) is a trial run on your infrastructure before full rollout. Watch out for: every item is "doable" and nothing needs testing. - “What load can the system handle, and how was that number measured?”
A good answer has a number, the test conditions, and a date. Watch out for: "it scales well" with no number, or a number with no conditions. - “In which cases will the AI decline to answer?”
Ask this for any chatbot or RAG (Retrieval-Augmented Generation) project. A good answer defines the data scope and the conditions under which the AI must say "I don't have that information." Watch out for: "the AI can answer anything." - “Which parts of our current system will you not touch?”
For legacy upgrades, a good answer names the no-touch zones, such as the core database. Watch out for: a full rewrite proposal with no migration risk assessment. - “If the defect is in the specification itself, who pays to fix it?”
A good answer separates vendor spec errors from client requirement changes, and puts that in the contract. Watch out for: every change billed to the client.
If a vendor answers all five in writing, you hold something more valuable than the proposal: a technical limitations document.
What does a real technical limitations document look like?
A good technical limitations document is short, specific, and verifiable. The example below is the limitations section VAON published for its own multilingual identifier-extraction OCR service (2026).
The service has 54 automated tests: 42 unit tests and 12 integration tests running against the real model. During development, a new route was found to be missing the upload size limit. It was fixed before release, and an 11 MB upload is now rejected as designed. Three limitations are recorded as they are:
This list does not make the service less valuable. It tells users exactly where the service fits, and what must be added before using it elsewhere. Details are in the multilingual identifier-extraction OCR case study.
How does VAON write constraints into project documents?
VAON writes a Technical Boundaries Document alongside the feature list, starting in the consulting phase. Three principles shape what goes into it.
Principle 1: separate "verified" from "needs PoC".
VAON does not say "definitely doable" on instinct. Items proven in past projects are listed separately. Items that depend on your own infrastructure are marked as needing a PoC, with a test plan.
Principle 2: scope the data and the refusal conditions for the ONEBOT AI chatbot.
When deploying ONEBOT, VAON defines which documents RAG may use, and when the AI must answer "no information" instead of guessing. This sharply reduces wrong answers, but no AI system removes that risk entirely, so VAON states the remaining risk too. In the Vietnamese OCR project for ONEBOT, extraction accuracy went from 70% to zero recorded errors on the tested dataset, and that article states the result does not apply to every document type.
Principle 3: declare no-touch zones in legacy modernization.
For legacy systems, VAON uses the Strangler Fig pattern: build the new layer around the old one instead of tearing it down. In the 20-year-old CMS modernization, VAON committed up front not to touch the stable core database. The project finished in 4 months with zero downtime. That result reflects the scale of that project, not a default for every project.
These principles are part of VAON's Spec Lock Phase. How VAON splits responsibility when a defect traces to the spec is covered in Saying What We Won't Do First.
What doesn't constraint transparency solve?
Stating technical constraints reduces surprises, but it does not remove every risk. Three things to know:
- A limitations document is only as good as its inputs. If an unwritten business rule never comes up during consulting, the document cannot reflect it.
- "Needs PoC" still means "unknown". Marking it tells you where the risk sits, but the PoC can still show the original approach won't work.
- The 5 questions don't replace legal or security due diligence. Projects with certification or subcontracting requirements still need their own review.
Closing
A vendor who states limits up front is not weaker than one who promises everything. They are showing you early what you would see eventually anyway.
If you are preparing a software or AI project, send VAON a short description of what you plan to build. We will answer the 5 questions above for your specific case, in writing. If you are an agency or SIer looking for an OEM technical partner, we are happy to talk too.
Send my project and get a technical limitations review: https://vaon.com.vn/en/contact