Skip to main content

System Operations &
Maintenance

After launch, we keep your AI agents, data pipelines, scrapers and apps running: watched, patched and improved by engineers who know the code.

System operations and maintenance services for AI, data and web systems after launch. We monitor what runs in production, respond to incidents, fix faults, keep models, APIs, runtimes and dependencies current, and tune cost and performance, for systems we built and, after an onboarding review, for systems other teams built. The work happens in your accounts, on a monthly retainer sized to what your systems need.

Tran Tien Van, founder of Van Data Team

Tran Tien Van

Founder, AI and data engineer

150+

Projects

Delivered for clients worldwide

30

Days

Of support after launch in every build

5.0/5.0

Rating

Average client rating

71

Upwork Reviews

Client reviews on Upwork

Monitoring and alerts on every system we take overIncident response, with a written cause and fixUpgrades for models, APIs, runtimes and dependencies

Last updated:

What do system operations and maintenance services cover?

Six questions teams ask before they hand their production systems to an outside team, answered from the systems we build and run.

01 / 06

What does an operations and maintenance retainer cover?

Everything a system needs after launch to keep doing its job, for every kind of system you hand us: AI agents, data pipelines, scrapers, web apps and websites.

  • Watching: monitoring, alerts and dashboards on the signals that matter for each system.
  • Responding: incidents handled within the hours agreed in the retainer, each with a written cause and fix.
  • Maintaining: the four kinds of software maintenance, corrective (fix faults), adaptive (keep up with changes around the system), perfective (make it faster, cheaper or better) and preventive (head off the next fault).
  • Reporting: a monthly review of health, incidents, changes, cost and what is due next.

Key takeaway: Operations is a job with an owner and a report, not favours asked of whoever built the system.

02 / 06

Why do AI agents and data systems need maintenance when nothing changed?

Because the world around them changes. Model providers retire model versions on published schedules, and a model update can change answers even when your prompts did not.

APIs and SaaS sources rename fields and change limits, websites redesign the pages a scraper reads, and data volumes grow past what a job was sized for.

Platforms move too. AWS deprecates a Lambda runtime when its language version leaves long-term support; after that it may no longer receive security patches, and AWS warns account owners at least 180 days ahead.

Key takeaway: A system nobody maintains does not stay the same; it falls behind everything it depends on.

Source: AWS Lambda runtime deprecation policy(opens in a new tab)

03 / 06

What do you monitor?

For services, the four golden signals from Google’s Site Reliability Engineering book: latency, traffic, errors and saturation.

  • For AI agents, quality and cost as well: scores on a fixed set of evaluation questions, cost per conversation, tool errors and how often the fallback model answers.
  • For data pipelines: freshness, row counts against the usual range, schema changes and failed tests.
  • For scrapers: success and block rates per source and how full each field is, so a redesign shows up before blanks reach your data.
  • For websites: uptime from outside, errors inside, and the dates that expire quietly, from SSL certificates and domains to runtime support.

Key takeaway: Every alert names the system, the signal and the first thing to check.

Source: Google SRE book: Monitoring Distributed Systems(opens in a new tab)

04 / 06

What happens when something breaks?

The alert reaches the engineer who knows the system, with what it takes to start: the failing trace, the batch or the page.

Every incident ends with a short written review of what happened, why, and what changes so it cannot happen the same way again. Reviews look for causes in the system, not for people to blame.

  • First we limit the damage: roll back, switch to the fallback model, hold back the bad batch or pause the job. Then we fix the cause through a pull request and the same tests as any other change.

Key takeaway: Restore first, then fix, then make sure it cannot happen the same way twice.

Source: Google SRE book: Postmortem Culture(opens in a new tab)

05 / 06

Can you take over a system another team built?

Yes, after an onboarding review. With read-only access we read the code, the infrastructure and whatever documentation exists, map every dependency, account and renewal date, and list the risks.

If the review shows that rebuilding would cost less than keeping the system alive, we say so, and show the numbers.

  • Then we add what operating it needs: health checks, alerts, evaluation sets for agents, data tests for pipelines and runbooks for the failures we can foresee.

Key takeaway: We only take on incidents for a system we have read.

06 / 06

How is it priced?

Every system we build includes 30 days of support after launch. After that, a monthly retainer covers about 40 to 200 engineering hours, sized to how many systems we run and how often they change, and is quoted at a fixed monthly fee after a free consultation.

One-off work, such as a single upgrade or fix, is quoted at a fixed price per task. Coverage hours and response times are agreed in writing before a retainer starts.

Key takeaway: You pay for engineering hours on your own systems, not for a seat in a ticket queue.

How do we take a system over? Through the four stages below, led by the founder from the first call.

Book a consultation

How we run systems

Four kinds of systems, watched and maintained

Each diagram is how we operate one kind of system after launch. Play an incident step by step, from the first signal to the fix, or switch to the signals view to see what we watch on each part and the guards that keep the damage small.

Traces · nightly evals · eval gate

An AI agent in production: from a drop in quality to a tested fix

Agents fail quietly: answers drift, a tool starts erroring, a model version is retired. We trace every call, score answers every night and fix through an eval gate, while a fallback model keeps users answered.

  1. Each conversation is recorded with its latency, tokens, cost and tool calls, and a fixed set of questions is scored every night against the answers we expect.

    • Users and Slack
    • Agent service
    • Traces and evals
  2. The nightly score falls below the line agreed with you, cost per conversation jumps, a tool starts failing, or the provider announces a retirement date for the model.

    • Alert
  3. If the primary model errors or times out, requests route to the fallback model, so the agent keeps working while we find the cause.

    • Fallback model
  4. The alert reaches the engineer who built or onboarded the agent, with the failing traces attached, within the hours agreed in your retainer.

    • VDT engineer
  5. The change, whether a prompt, a tool or a model version, goes through a pull request, and the eval suite has to pass in CI before it can merge.

    • Fix in a pull request
    • Eval gate in CI
  6. The fix rolls out in stages; we compare scores and cost with the baseline and record the cause and the change in the monthly report.

    • Staged release
    • Agent service

Drawn from how we instrument the agents we build, such as alice/ai, traced in LangSmith. Read the case study

How we take over a system

Four stages, each ending in something you can check: a map of the system and its risks, alerts and runbooks you can see, incidents with written causes, and a monthly review.

  1. Stage 01

    Onboarding Review

    Weeks 1 to 2

    We read the system before we take on its incidents, with read-only access.

    • Code, infrastructure, accounts and documentation, read end to end
    • A dependency map: models, APIs, sources, runtimes, certificates and renewal dates
    • Risks ranked by impact, with what to fix first

    Output: a system map and a ranked list of risks.

  2. Stage 02

    Observability Baseline

    Weeks 2 to 3

    We add what operating the system needs, and test every alert before relying on it.

    • Health checks and alerts routed to the right channel
    • Evaluation sets for agents, data tests for pipelines, fill-rate checks for scrapers
    • Runbooks for the failures we can foresee
  3. Stage 03

    Steady-State Operations

    Monthly

    Monitoring, incident response and maintenance within the hours agreed in your retainer.

    • Incidents restored first, then fixed through pull requests and tests
    • Upgrades planned ahead of retirement and end-of-support dates
    • Small improvements from your backlog

    Output: every incident with a written cause and fix.

  4. Stage 04

    Monthly Review

    One page and a short call: how the systems did and what comes next.

    • Uptime, incidents, changes and cost compared with last month
    • What is due: model retirements, runtime upgrades and renewals
    • Documentation kept current, so your team can take over at any time

A system left after launch vs an operated system

Most systems do not fail on launch day. They fail months later, when something they depend on changes and nobody is watching. This is the difference an owner makes.

Failures
Left after launchFound by a user, a customer or an empty report
Operated systemCaught by alerts and routed to an engineer who knows the system
Model and API changes
Left after launchBreak the system on the provider’s deadline
Operated systemTracked ahead of retirement dates and tested before the switch
Data quality
Left after launchWrong numbers reach dashboards and decisions
Operated systemBad batches held back, while dashboards keep the last good data
Security patches
Left after launchPostponed until something forces them
Operated systemApplied on a schedule, through tests and a staged release
Knowledge
Left after launchLives in one person’s head
Operated systemRunbooks, diagrams and a change log in your repository
Cost
Left after launchDrifts up unnoticed
Operated systemReviewed every month with the other signals

What a retainer covers

Four kinds of maintenance, across every system you run

Software maintenance comes in four kinds, and production systems need all of them. A retainer covers each one on AI agents, data pipelines, scrapers, apps and websites alike.

The four kinds of maintenance

  • Corrective

    Fix what breaks

    Incidents restored, then their causes fixed and written up.

    • A tool call that started failing
    • A load that broke on bad data
    • A scraper returning empty fields
    • An error that came with a release
  • Adaptive

    Keep up with change

    The world around a system moves; the system moves with it.

    • A model version retired by its provider
    • An API that changed its fields or limits
    • A website redesign under a scraper
    • A runtime reaching end of support
  • Perfective

    Make it better

    Improvements measured against the baseline, never guessed.

    • Faster responses and pages
    • Lower cost per call or per run
    • Better answers from a tuned prompt
    • Small features from your backlog
  • Preventive

    Stop the next incident

    The quiet work that keeps the next alert from firing.

    • Dependency and security patches
    • Certificate and domain renewals
    • Backup restores tested on a schedule
    • Actions from every incident review

Ways to work with us

  • Support after launch

    Includedin every build

    30 days after launch for fixes, tuning and your team’s questions.

    • Fixes to anything we shipped
    • Tuning on real traffic and data
    • Runbooks and access handed over
  • Operations retainer

    Fixed monthly feequoted after a free call

    About 40 to 200 engineering hours a month, sized to your systems.

    • Monitoring and incident response
    • All four kinds of maintenance
    • A monthly review and report
  • One-off work

    Fixed quoteper task

    A single upgrade, fix or review, with no monthly commitment.

    • A model or runtime upgrade
    • Help with one incident
    • A review before a retainer

Coverage hours and response times are written into the retainer before it starts, never assumed.

Book a consultation
Tran Tien Van, founder of Van Data Team

Warning signs

Signs your systems need an owner after launch

If two or more of these sound familiar, your production systems are running on luck.

  • 01You learn about failures from users, or from a dashboard that went quiet.
  • 02Nobody can say which model, runtime or API version is in production.
  • 03The engineer who built it has moved on, and nobody else can ship a fix.
  • 04A scraper or pipeline fails silently, and the gap turns up weeks later.
  • 05Security updates wait until something forces them.
  • 06Your AI bill or your agent’s answers changed, and nobody knows why.

If you're seeing any of these, it's time to talk.

Book a consultation

Built to run

Systems built to be operated, not just launched

Retries, alerts, audit logs and safe re-runs are part of the build. Named products where the clients have agreed; the rest stay unnamed. Every number comes from the project itself.

Production health score of a five-agent platform
94.7%
Tests that run before a healthcare release ships
255+
Confidence an AI programme needs to reach a user
85%
OBJX Intelligence logoClient project

Enterprise SaaS

OBJX Intelligence Multi-Agent Platform

Agent-first multi-tenant platform built around persistent memory, covering project management, financial operations, proposal generation, and a real-time dashboard.

platform health score in production
94.7%

FastAPI · LangGraph · MEM0 · PostgreSQL 15 · Redis · Celery · React 18 · DigitalOcean

More systems built to keep running

Engagements where operating the system was part of the design. The clients stay unnamed; the safeguards are what shipped.

  • Lambda integration suite

    Four SaaS integrations moved off always-on servers into stateless Lambda functions, with SNS alerts when a run fails.

    AWS Lambda · RDS MySQL · SNS

  • Multi-tenant Shopify data hub

    A failed tenant is retried on its own, so one store’s error never holds up the others.

    Cloud Run · Pub/Sub · BigQuery · Firestore

  • Multi-channel ad ETL on Airflow

    Snowflake MERGE loads that never duplicate rows on retry, across five ad platforms.

    Airflow · Snowflake · Docker

  • LinkedIn ESG research panel

    A five-phase scraper that resumes after an error, so multi-day runs go unattended.

    Python · Selenium · pandas

  • Healthcare analytics on Fargate

    Terraform-managed ECS Fargate with Secrets Manager and OIDC deploys, and 255+ tests before anything ships.

    ECS Fargate · Terraform · Secrets Manager

  • Healthcare claims ETL

    A column-level audit log records every load of member, claims and provider files in four formats.

    Airflow · AWS Glue · Athena · S3

  • EC2 to Lambda scraper migration

    A headless Chromium scraper moved from always-on EC2 to a Lambda container that scales to zero between runs.

    AWS Lambda · ECR · Docker

  • Sales KPIs from Slack

    Claude Haiku turns Slack messages into validated KPI rows in BigQuery, on jobs that bill only while they run.

    Cloud Run Jobs · BigQuery · Claude Haiku

What clients say about working with Van Data Team

Teams bring us AI agents, web scraping, data platforms, reporting and cloud work. Their verified reviews speak to senior, founder-led delivery from prototype to production.

Verified on Upwork

5.0

71 client reviews · 69 of them five-star

  • 5 stars69
  • 4 stars2
  • 3 stars0
  • 2 stars0
  • 1 star0
See Upwork Reviews
CK

Chris K.

December 30, 2025

“Great backend developer, highly recommend!”

FT Platform Phase #2

Verified Upwork review

GB

Gilad B.

December 18, 2025

“Very knowledgeable and professional. Good communication”

Phase 0: Design a granular data schema and structure, and full tool flow

Verified Upwork review

JD

Julio D.

July 16, 2025

“Tran was great, very knowledgeable and quick responses”

Web scraper in R

Verified Upwork review

MM

Madison M.

March 31, 2025

“Very responsive and quick to get started! Produced excellent results. I will definitely reach out again in the future.”

Review Git Pull Requests

Verified Upwork review

DC

David C.

March 29, 2025

“Great platform to interface with developer.”

You will get AWS, GCP and Azure Data pipeline

Verified Upwork review

AJ

Alex J.

February 18, 2025

“Fast, responsive, professional. Really appreciated the thorough documentation too.”

You will get Data Scraping | Data Extraction | Web Scraper | Automation Tools

Verified Upwork review

TS

Tomer S.

December 12, 2024

“Van exceeded all expectations with exceptional professionalism and expertise. They delivered high-quality work ahead of schedule, communicated effectively throughout the project, and made the collaboration seamless and enjoyable. I highly recommend Van to anyone looking for a skilled and reliable freelancer.”

Create Web scraper for Facebook

Verified Upwork review

PT

Preska T.

October 21, 2024

“I recently had the pleasure of working with Tran, and I can't express enough how impressed I am with his work. From the very beginning, he demonstrated a deep understanding of our project requirements and brought a level of expertise that made a significant difference in the outcome. What truly sets Tran apart is his commitment to excellence.”

You will get Data Scraping | Data Extraction | Web Scraper | Automation Tools

Verified Upwork review

AW

Alice W.

May 26, 2024

“AMAZING. We are lucky that we found Van. He helped us with our database structure. He is very knowledgeable and very cooperative. We are still continuing to work with him further. I can only highly recommend.”

Admin Panel for Data Management

Verified Upwork review

NS

Nic S.

May 15, 2024

“Excellent work. I'd be very happy to work with Tran in the future.”

Web scraping: Project review and proposal

Verified Upwork review

PK

Paris K.

March 22, 2024

“Tran did a great job on a LAMP REST API deployment to Microsoft Azure. We'd be happy to work with this freelancer again.”

Seeking developers experienced with LAMP (Python) and REST APIs for UX Research Study / gstd-2024-1

Verified Upwork review

YK

Yalcin K.

March 18, 2024

“Van is a great data engineer, and I highly recommend it. He joined our project and helped build a custom data pipeline within weeks.”

Python Developer to Build a Shopify Integration

Verified Upwork review

The Van Data Team difference

Why teams trust us with their production systems

Five reasons the systems stay healthy, and stay yours.

Tran Tien Van, founder of Van Data Team

Tran Tien Van

Founder, AI and software architect

Top Rated Plus on Upwork
The engineer who scopes your project is the one who builds it.
Projects delivered
150+
Upwork rating from 71 reviews
5.0
Countries served
15+
Years of development experience
5+
  1. 01

    The engineers who built it

    For systems we built, the people who answer the alert wrote the code, so diagnosis starts from knowledge, not from reading.

  2. 02

    AI, data and web in one retainer

    Agents, pipelines, scrapers, apps and websites run by one team, so an incident that crosses them has one owner.

  3. 03

    Everything in your accounts

    Alerts, runbooks, dashboards and code live in your cloud and your repository; nothing is locked inside our tools.

  4. 04

    Written down, not remembered

    Every incident gets a written review and every change a pull request, so the knowledge stays when people change.

  5. 05

    The founder on the escalation path

    The founder who scoped the work stays your escalation point, with no account manager between you and the engineer.

150+ Projects Delivered With VANDATATEAM

VanDataTeam has delivered 150+ projects for teams across 15+ countries, building lasting success through production grade AI Agent systems and data engineering expertise.

Ahrvo logo

Ahrvo

Banking, Payments & Compliance API

Athenahealth logo
Clear Gene logo
Conversion Finder logo
Debit My Data logo
Ellipsis Earth logo

Ellipsis Earth

Litter and pollution intelligence

Forskningslogen Friederich Munter logo
alice/ai logo
HBC logo
iRASSHAi logo
Kejora logo
Lunada logo
OBJX logo
Setmore logo
Supply Bridge logo
Voodoo logo

Voodoo

Iconic apps and games

Wajooba logo
White Ribbon Alliance logo
YouHeal logo

FROM DELIVERED PROJECTS

The operations stack we work with

48 technologies across 8 layers, every one of them used in delivered client work.

Pick a layer, or let the orbit walk you through them.

Monitoring and Alerts

7 tools

Metrics, logs, errors and uptime, with alerts routed to the engineer on duty.

  • Grafana
  • Sentry
  • Prometheus
  • Datadog
  • CloudWatch
  • OpenTelemetry
  • Structured logging

On the orbitGrafana · Sentry

System operations and maintenance FAQ

Tell us what you need kept running

Book a free 30-minute call with the founder. Bring a list of the systems you run and what breaks most often, and we will tell you what we would watch first and what a retainer would cover. No deck, no pressure.

We use these details only to reply about your project. See our privacy policy.

Tran Tien Van, Founder of Van Data Team, ready to help

Keep exploring

Services teams often pair with this one, delivered by the same founder-led team.

See all 6 services