Why do B2B software projects collapse right before launch?
When enterprise buyers and agency partners evaluate a development vendor, they often hear a familiar pitch: every feature is possible, AI integration included, on a tight budget and a fast timeline. It sounds reassuring at signing time, but it is where many project failures begin.
This is rarely malicious. Many vendors want the contract, so they agree before checking whether the technical constraints actually allow it, on the logic of "win the deal first, work out the hard part later." The constraints do not disappear. They surface later, usually weeks before go-live.
Three patterns show up when that happens: a real-time data sync requirement turns out to be incompatible with the client's legacy database, an initial budget balloons two to three times over "unexpected technical complexity," or an AI chatbot promised to answer accurately starts giving customers wrong information in production.
Who pays when technical limits stay hidden?
Not stating what cannot be done upfront costs everyone in the chain.
The client ends up with a system that does not work, or an outage on cutover day, after committing real budget and months of time. The agency or SIer in between loses credibility with its end client for choosing a vendor that had not mapped its own technical risk. The development team itself ends up overworked trying to deliver on a promise that was never realistic, which is a common path to project abandonment.
Vendors avoid saying "we cannot do this" mostly out of fear of losing the deal to a competitor, and sometimes because they lack the architecture depth to spot the limit early. This is not one company's problem. It is a common sales pattern across the industry.
VAON's principle: stating what we won't do before the contract
VAON works the other way. We define scope boundaries, what we will not do, during the consultation stage, before any contract is signed.
In practice, this is a separate Spec Lock Phase, 2 to 4 weeks depending on project size, priced fixed and disclosed upfront. At the end of it, you receive a requirements document, screen designs, database design, and a fixed quote for the build phase.
The commitment attached to it: if rework during the build phase traces back to an error or omission in the specification VAON wrote, VAON covers that cost. If the client changes requirements after the spec is locked, that goes through a separate, written change-request process instead.
Case 1: a 132 MB CPU-only multilingual OCR engine
A client needed high-accuracy multilingual OCR for Vietnamese and Japanese documents. The common approach on the market is deploying a large AI model on cloud GPU servers.
Before starting, VAON stated two things it would not do: build a system dependent on cloud GPUs, since the monthly infrastructure cost climbs with volume, and promise full accuracy without a rigorous image pre-processing step first.
Instead, VAON fine-tuned a proprietary 132 MB CPU-only OCR engine on more than 500,000 real Vietnamese character samples. On one deployed project, this raised extraction accuracy from 70% to no errors observed on the tested dataset, while cutting infrastructure cost 80% versus a GPU-based option for the same volume. All processing runs on internal infrastructure, with no data sent to a third-party cloud API, meeting Japan's APPI requirements.
Case 2: modernizing a 20-year-old CMS without touching the database
A CMS running for 20 years, hosting millions of pages, needed modernization. The typical proposal for this situation is a full rebuild, database and application both, usually taking one to two years with real downtime risk at cutover.
VAON stated two things it would not do from the start: dismantle a database that had run reliably for 20 years, since the failure risk outweighs the benefit, and accept a migration method with even one minute of downtime.
The answer was a Strangler Fig migration: keep 100% of the existing database and editorial workflow, while an automated pipeline generates static HTML in the background and serves it through an Edge CDN. The project finished in 4 months with zero downtime, sub-50ms TTFB, a 66% cut in development time versus a full rebuild, and a 70% reduction in infrastructure cost. The 99.5% uptime SLA is what VAON offers for this specific class of static-distribution architecture, not a default guarantee for every engagement.
What stating limits upfront actually delivers
Saying what won't be done is not a polite way of saying no. It is scope engineering, and it reduces real risk.
When technical boundaries are agreed early, mid-project cost overruns and delays drop, because both sides already know what is in and out of scope. Naming the limits of an AI model or a database upfront also prevents the kind of surprise failure that shows up only in production. For agencies and SIers looking for a technical partner to work under their own brand, one that names its limits gives them a stronger position with their end clients than one that leaves them explaining a surprise later.
Where this approach falls short
None of this is a formula that applies to every project, and it comes with limits worth knowing.
The 4-month timeline and improvement figures in the CMS case are tied to that project's specific scale and complexity. A smaller CMS could finish faster; one with deeper internal integrations could take longer. Likewise, the "no errors observed" result for the OCR engine was measured on one tested dataset, not a blanket accuracy guarantee across every document type or industry. The lexicon layer built for finance and retail terminology would need to be rebuilt for a different sector, such as healthcare or banking.
VAON's commitment to cover rework cost also has a clear boundary in the contract: if the client changes requirements after the spec is locked, or an external condition changes such as a law or a third-party API, that cost sits outside the commitment.
Wrap-up
Stating what we won't do first does not make an offer less attractive. It makes the offer match reality, which lowers the odds of an expensive fix later.
If you are evaluating a system development or AI integration project and want to know the specific technical limits for your case, VAON can walk through an initial assessment. If you are an agency or SIer looking for a technical partner for an OEM arrangement, we are open to discussing how that could work.
Official Website: https://vaon.com.vn/en