This guide is for a CTO, VP Engineering or founder who has already decided to work with an offshore development center or a dedicated development team (the outsourcing pillar covers that decision) and who is now reading a shortlisted vendor's portfolio page, where some or all of the AI project proof has no client name attached.
In this guide
- Why do AI vendors anonymize their case studies in the first place?
- What should a trustworthy anonymized case record actually contain?
- The anonymized-record checklist
- How much can an anonymized record actually prove, and how much is still a gap?
- A sequencing plan for reading vendor proof
- Where AI fits in evaluating a vendor's AI delivery proof
- What delivery record exists, and what does not
- Alternatives: what to do when the anonymized record alone is not enough
- Limits of this guide
- Frequently asked questions
- Next step
Why do AI vendors anonymize their case studies in the first place?
Most offshore AI delivery work sits under a non-disclosure agreement, because the client's data, model choices or product roadmap are themselves a competitive asset; a vendor that could legally publish every logo it has worked with usually already does, so routine anonymization is a signal about the client's confidentiality terms, not automatically a signal about the vendor's competence. Netbase, for example, names 4over4 as a client because that case study was published with 4over4's consent, while describing its other delivered AI projects — a RAG knowledge assistant, a document-AI platform and an MLOps pipeline — only by scope, because no comparable publication consent exists for them. Treat anonymization as the default state of AI delivery proof, not as the exception that needs explaining away.
What should a trustworthy anonymized case record actually contain?
A trustworthy anonymized record still states four things even without naming the client: a dated scope (when the engagement ran, not just "recently"), the named technology and model stack used, a milestone or phase breakdown of what was delivered in what order, and an explicit statement of what is not disclosed, rather than silence where a figure should be. A record that is vague on all four — no dates, no stack, no structure, and figures implied rather than stated as withheld — gives you nothing to check against anything else the vendor tells you later.
The anonymized-record checklist
| What to check | What a disclosed version looks like | What a thin version looks like |
|---|---|---|
| Dated scope | A start date or engagement year, and a stated duration or milestone count | "Recently" or no timeframe at all |
| Named stack | Specific models, frameworks or platforms named as the build, not "AI-powered" alone | Only marketing adjectives, no named technology |
| Delivery structure | Milestones or phases described in sequence, matching a real project shape | One paragraph of outcomes with no visible structure |
| Explicit non-claims | A stated line that no name, figure or result is published, so silence reads as a rule, not an omission | No figures given, but also no statement that none exist — you cannot tell if one was simply left out |
How much can an anonymized record actually prove, and how much is still a gap?
An anonymized record that clears the checklist above proves that a project of that shape and stack was really built and that the vendor is willing to be specific about structure while protecting the client's identity; it does not prove the result the client got, the vendor's current team capacity, or that your own project — different data, different constraints — will go the same way. Close that second gap with your own evidence: a short reference call scoped to process questions the NDA allows ("what changed between the first and final milestone," not "which client was this"), or a small paid pilot on a slice of your own problem, as the hiring and screening guide recommends for individual candidates. A record passing the checklist narrows how much verification you still owe yourself; it never replaces it.
A sequencing plan for reading vendor proof
-
Collect every case record the vendor publishes,
named and anonymized, before judging any single one.
-
Run the checklist above on each anonymized record
dated scope, named stack, delivery structure, explicit non-claims.
-
Cross-check the named cases for consistency
with the vendor's own stated specialisms; a vendor whose only named case has nothing to do with AI delivery is leaning on an anonymized claim it cannot otherwise support.
-
Ask for one process-level reference call
on the anonymized record that is closest to your own project, scoped to questions an NDA would allow.
-
Request a small paid pilot
on a real slice of your own problem before a full contract, so the proof you act on is proof about your own data and constraints, not someone else's.
-
Write your own scope and acceptance criteria into the contract
before work starts, following the security and partner-diligence questions guide for what else to confirm alongside delivery proof.
Where AI fits in evaluating a vendor's AI delivery proof
AI tooling can speed up reading a large shortlist of vendor pages, but it cannot verify a claim the vendor itself has not published.
-
In delivered work
A retrieval-augmented knowledge assistant
Built as AI consultant, engineer and integrator for a client that is not named, this record shows the checklist above applied by Netbase itself: a dated scope, a named stack, and no client name, count or figure published.
-
Available capability
AI-assisted vendor-proof review
Summarising a long shortlist of vendor case pages against the checklist above, and flagging which ones are missing a dated scope or a named stack, is a generative AI reading-assistance task; not yet tied to a published Netbase case for vendor evaluation itself, and it never substitutes for a reference call or a pilot on a real engagement.
What delivery record exists, and what does not
Netbase's own AI delivery proof follows the same anonymized pattern this guide asks you to check, so it is worth reading as an example of the checklist rather than only as a source:
- 4over4 (named, with consent). A product recommendation engine built from browsing and purchase history for 4over4's online printing store is the one AI delivery case Netbase names, because 4over4 consented to publication.
- RAG, document AI and MLOps (anonymized, dated and scoped). Beyond 4over4, Netbase has delivered a retrieval-augmented knowledge assistant and an MLOps pipeline for clients that are not named; each record states the role Netbase played (AI consultant, engineer and integrator) and the kind of system built, with no client name, count, accuracy figure or result published.
- Classifieds platform AI moderation (anonymized, milestone-dated). A bilingual classifieds marketplace for a founder, not named, includes an AI content-filtering feature that flags offensive content into an admin review queue, delivered in six milestones over four months; the moderation vendor is not named in the agreed scope.
- WhatsApp AI chatbot with CRM integration (anonymized, model-named). A WhatsApp Business chatbot built on OpenAI language models with Dialogflow or Amazon Lex for intent handling, synchronised with the client's CRM, for a client not named, delivered in milestones from prototype through integration, tuning and 30 days of support.
- Cloud ERP for a US client (named only as a type, phase-dated). Since 2020, Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP for an unnamed US client, with a stated phase-1 scope (2020-2023) and a named stack; no usage figure from that engagement is published.
What does not exist. No published Netbase record names the client behind the RAG assistant, the MLOps pipeline, the classifieds AI-moderation feature or the WhatsApp chatbot, and none publishes an accuracy rate, a cost figure or a time-to-value number for any of them; the US client ERP engagement names no company size or product name. Most Netbase projects run on fixed-price contracts after a discovery phase, and Netbase works with major commercial and open-source AI models and vendors (OpenAI, Anthropic, Google, Meta, among others), chosen per project rather than through a single preferred stack.
Alternatives: what to do when the anonymized record alone is not enough
| Route | Strength | Choose it when |
|---|---|---|
| Accept the anonymized record as sufficient | Fastest path; no added cost or delay | The record clears every item on the checklist and your project is low-risk or small in scope |
| Request a scoped reference call | Verifies process and working style without breaking an NDA | The record is strong but you want to hear the client's side of the milestone structure |
| Run a small paid pilot | Proof is about your own data and constraints, not someone else's | The project is high-risk, high-spend, or the anonymized record is thin on stack or structure |
Limits of this guide
- A vendor's willingness to publish a detailed anonymized record is evidence of disclosure discipline, not a guarantee of outcome quality on your own project.
- Netbase's own anonymized records above describe agreed or delivered scope, never a measured result; no duration, cost or accuracy figure is claimed for any of them.
- NDA terms vary by client and by vendor; what a reference call is allowed to cover depends on the specific agreement, not on this guide.
Plan the next step with a Netbase consultant
Frequently asked questions
No. Anonymization is the default outcome of an NDA, not a sign the work did not happen; judge the record by whether it states a dated scope, a named stack and an explicit non-claims line, not by whether a client name is attached.
Ask the vendor to add that detail, or ask for a different, more detailed anonymized record; a record with no timeframe and no named technology gives you nothing to check later against what the vendor tells you in the sales process.
A well-scoped one should not: keep questions to process and structure ("what changed between the first and final milestone") rather than to facts the NDA protects, such as the client's name or its own data.
No. A strong named case study shows the vendor can publish results when a client consents; it does not tell you anything about the engagements where no consent exists, which still need the checklist above.
Next step
Tell us which anonymized case record raised a question, and we will book a solution review to walk through the scope, the stack and what a pilot on your own project would look like. You can also read about our AI knowledge assistant work or browse more Netbase insights.
Related services and solutions
An AI-augmented dedicated development team in Vietnam that answers for results
Netbase provides dedicated development teams from Vietnam for product companies and enterprises that need engineering capacity. Teams of 3 to 30 people work only on your product, use AI-assisted engineering under review, report to a named account manager and project manager, typically start within one to two weeks after discovery, and the IP they create is yours.
Learn More
An AI-enabled offshore development center in Hanoi, when a long roadmap needs one
An offshore development center (ODC) in Vietnam is a long-running engineering team that a partner abroad staffs, manages and documents for your product roadmap. Netbase runs ODC teams from its only office, in Hanoi, with AI-assisted engineering, weekly governance and knowledge transfer built in. When the work has a defined outcome, a fixed-price project usually fits better.
Learn More
AI knowledge assistant: answers from company knowledge, with sources and access control
An AI knowledge assistant is an internal tool that answers employees' questions from your company's own documents and systems, cites the source behind every answer and shows each person only what they may see. Netbase offers it as a growth capability, designed with retrieval, evaluation and human review from the first pilot, and has delivered one for an unnamed client.
Learn More
Work with Netbase remotely
Every Netbase engagement is delivered remotely, so clients in any country and any industry can work with us; Netbase has worked with clients in 80 countries. Contracts and invoices are issued by Netbase JSC, and payment is made by bank transfer to Netbase JSC's company account or PayPal Business. Talk to the CEO, Huy Nguyen (David), on WhatsApp or by email.
Discuss a project
Netbase JSC helps organizations design, build, modernize, and operate digital products and AI-enabled business systems.project@netbasejsc.com
+84 937 869 689
91 Nguyen Chi Thanh, Dong Da, Hanoi, Vietnam
Get in touch
Tell us what you want to build, modernize, or operate.