Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Data and AI platform engineering: one foundation your workflows share

The service builds the shared data and AI foundation several workflows draw on: pipelines and data contracts, governed data products, retrieval and vector indexes, an evaluation store, model operations, and the access policy and cost model that hold it together. It is the platform layer underneath the individual workflows, not a replacement for building any one of them.

Submit a project Assess data readiness first

Reviewed by David Nguyen (CEO) · Updated 29 Sep 2026

star

OutsourcingVN is operated by Netbase JSC. Every capability in this platform — retrieval, evaluation, model operations — is new to every supplier in the current AI era, and Netbase takes each one on and combines it into delivery rather than waiting for a long track record to form around it.

What does the platform build?

Pipelines and data contracts

Extraction, transformation and load jobs with an explicit contract per feed: source, owner, schema, freshness and what happens when a feed breaks.

Governed data products

Named datasets with a business and technical owner, a quality bar and a documented access rule, so a workflow reads from one governed source rather than a private copy.

Retrieval and vector indexes

A source register, chunking and indexing pipeline and permission filter shared by every workflow that needs grounded answers or semantic matching.

An evaluation store

Versioned test cases, thresholds and results for every model, prompt or retrieval change, kept as a record rather than rebuilt per project.

Model operations

Model and prompt version pinning, rollout and rollback, usage and cost monitoring, and a re-test trigger on every change.

Access policy and cost model

Roles, data classes and spend limits defined once and enforced everywhere the platform is used.

Each part has a named owner and a documented interface, so a new workflow can be added to the platform without renegotiating how the underlying data is governed.

Good fit

  • Two or more workflows need governed pipelines, retrieval indexes and model operations, not a one-off build
  • A shared evaluation store and access policy must serve several AI features consistently
  • The retrieval architecture question is already settled and now needs a governed, running platform
  • A named data and platform owner can commit to the access policy and cost model

Another route fits better

How the platform is built

  1. Map the data and workflows

    Inventory the datasets, sources and workflows the platform must serve, their owners, freshness needs and access rules.

  2. Build the governed pipelines and indexes

    Stand up extraction, transformation and load jobs with contracts, then the retrieval and vector indexes with permission filtering applied at query time.

  3. Wire the evaluation store and model operations

    Version every model and prompt, build the evaluation cases each workflow needs, and connect usage and cost monitoring with an owner who reviews it.

  4. Onboard workflows and widen

    Connect the first workflows to the shared platform, then add new datasets, indexes and evaluation cases as coverage grows, re-testing on every change.

Where this sits among the AI-era services

Netbase works with commercial and open-source AI models chosen per project (model-agnostic); no vendor partnership is implied by any component this platform combines. Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines, which is the practical base this service draws its pipeline, retrieval and evaluation patterns from. A single retrieval-based AI knowledge assistant can be built as its own solution; this service is what a client reaches for once a second or third workflow needs the same governed sources, the same evaluation store and the same access policy instead of a separate copy each time. The relevance judgement behind a search or matching feature is a related but distinct decision, covered in the embeddings and semantic search guide.

A worked scenario: three product teams, one data platform

A B2B software company has three product teams that each want an AI feature: a support assistant grounded in help-centre articles, a semantic search box in its catalogue, and a document-extraction step in onboarding. Each team has started sketching its own pipeline and its own index.

The platform engagement inventories the three data sources, agrees one owner per dataset, and builds a shared ingestion pipeline with per-source contracts. A single retrieval and vector index serves the support assistant and the catalogue search, filtered by permission and document class at query time; the document-extraction workflow reads from the same governed onboarding dataset instead of its own export. One evaluation store holds the test cases for all three features, so a shared embedding-model upgrade reruns every affected case set automatically rather than three teams discovering the change separately. Usage and cost are monitored once, against one budget, with a named platform owner reviewing the signal weekly. The three teams keep their own product roadmaps; only the underlying data and evaluation layer is shared.

What technical stack does Netbase draw on?

Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS platform for a US client that is not named. Its first phase, from 2020 to 2023, covered CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management and API integrations, on a stack that includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS; a later retail phase was planned work when that profile was written and is not presented as delivered. Wider ERP experience covers Odoo consultancy and customization delivered with a local implementation partner, e-commerce integration with ERP by API synchronisation of catalogues, inventory, orders and customer data, a Vtiger CRM to ERP upgrade and Redmine to ERP development, with modules spanning finance, inventory, sales orders, HR, CRM, project planning and reporting. No client name, figure or result is published for any of it. See the multi-tenant cloud ERP SaaS platform record and the Odoo implementations record.

What company-level practice backs this service?

Security practices include secure code review and version control, role-based access control, multi-factor authentication for admin dashboards, contributors under NDA, and NDAs and data processing agreements available on request; the same access controls that protect a client's application code apply to the pipelines and indexes this platform runs. Netbase's compliance practices are GDPR alignment for data privacy in Europe, HIPAA-aligned methodologies for healthcare data handling, and CCPA compliance for clients with U.S. customer bases, and none of it substitutes for a client's own regulatory assessment of the specific data the platform holds.

Evidence and related work

The closest published examples of the underlying data and integration discipline this platform standardises are the multi-tenant cloud ERP SaaS platform record, where Netbase has held a continuing offshore development and managing-partner role since 2020, and the Odoo implementations record, delivered with a local implementation partner for retail chains, a food and beverage franchise and manufacturing, trading and distribution companies that are not named. Neither is a published retrieval or evaluation-store project; they show the governed-pipeline and integration base this platform engineering service is built on.

Multi-tenant cloud ERP SaaS platform
Multi-tenant cloud ERP SaaS platform

Since 2020, Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP that a US software company offers as SaaS to small and mid-sized businesses.

Keep Reading
Odoo consultancy and customisation, with a local implementation partner
Odoo consultancy and customisation, with a local implementation partner

Working with a local Odoo implementation partner, Netbase has consulted on and customised Odoo in Vietnam for a range of organisations, none of which is named.

Keep Reading

Questions to ask a data and AI platform supplier

  • How many workflows will the platform serve on day one, and later?

    A named list, not "everything eventually"

  • Who owns each dataset and each retrieval collection?

    Named business and technical owners, agreed before build

  • How is the evaluation store kept current?

    A re-test trigger tied to every model, prompt or source change

  • How are permissions enforced across every workflow the platform serves?

    Filtering inside the query, from identity, not copied once and left to drift

  • How is cost monitored and capped?

    A named budget owner and a usage alert, not a bill reviewed after the fact

What failure modes should you watch for?

  • Every workflow builds its own copy

    Signal: three teams each maintain a similar pipeline. Owner: the platform owner, who consolidates ingestion behind one contract per source.

  • The evaluation store goes stale

    Signal: a shared model upgrade ships without every dependent workflow being retested. Owner: the platform owner, who ties re-runs to every change, not a calendar.

  • Access policy drifts per workflow

    Signal: two features apply different rules to the same dataset. Owner: the data owner, who enforces one policy at the platform layer.

  • Cost is discovered, not managed

    Signal: a usage spike is found in a monthly bill. Owner: the platform owner, who wires usage alerts before launch, not after.

  • The platform never widens

    Signal: a fourth workflow builds its own pipeline anyway. Owner: the platform owner, who treats a new workflow as an onboarding task, not an exception.

Frequently asked questions

AI Workflow Automation builds and ships one operating workflow end to end. This service builds the shared pipelines, indexes, evaluation store and access policy several workflows draw on; the two combine well when a workflow needs a governed data foundation under it.

Not necessarily. A single AI knowledge assistant can be scoped and built on its own. This service becomes the better route once a second or third workflow needs the same sources, evaluation store and access policy instead of a separate copy each time.

That is a separate question the data platform readiness assessment answers first: dataset ownership, quality, access and a reliable way to extract each feed.

A named person on your side or ours, agreed at the start; an unowned platform degrades into pipelines nobody maintains.

Yes, where data rules require it. Access is scoped per role inside your environment, following the same security practices Netbase applies on any engagement.

Netbase works with commercial and open-source AI models chosen per project (model-agnostic); the evaluation store lets a model or embedding change be re-tested and compared before it replaces the one in production.

Ready to line up the platform?

Bring the workflows the platform must serve, the datasets and their current owners, and which of them already has an evaluation set. Submit a project with that scope, and a person will reply with which part to build first. OutsourcingVN is Netbase's own outsourcing-services platform.

Tell us what you want to build or automate.

Submit a project