Production systems · 8+ years

Nguyen Linh Thanh Nhan

Technical Lead, hands-on — Backend & Edge Computer Vision

Drop frames, not alerts. Keep video on site when it must not leave. Check identity on every data path.

At InnoVerse, I lead a team of up to 10 engineers. For more than eight years, I have built systems used in day-to-day operations: camera monitoring, fleet monitoring, city-scale water metering, and enterprise platforms.

10Engineers in the team I lead at InnoVerse
3Enterprise products sharing the same foundation
2h → 15mTime needed to release changes at TVT
~3sDelay before operators see live video in the marine work
  1. 01Timely over completeA stale detection has no operational value. Frames may be skipped; alerts may not arrive late.
  2. 02Edge when video cannot leaveDetection runs on a Jetson Orin NX at the site. Only alert metadata leaves.
  3. 03Isolated on every pathTenant and permission checks sit on every path that reads data — not only at sign-in.

Introduction

Who I am

  1. 2018Backend Developer · Modoho
  2. 2021Technical Lead · TVT Group
  3. 2024Technical Lead · InnoVerse

I started in backend development in 2018. Since 2021 I have worked as a Technical Lead — first at TVT Group, and from 2024 at InnoVerse, alongside Tech Heart until early 2025.

Along the way I have led teams of up to 10 people and built monitoring for several hundred vessels, city-scale water metering, and enterprise platforms used in day-to-day operations. My work sits between software architecture and solution architecture: I decide how a system is built on the inside, while also accounting for the conditions it must be deployed and operated under, then lead the team that puts it into real use. I studied mathematics at Ho Chi Minh City University of Science and left after two years when a full-time engineering role opened up; the self-study has continued in the work ever since.

How I work

What I own, write, and delegate

Technical Lead means deciding the architecture myself, and not delegating the parts that are hardest to fix if they are designed wrong.

01

Own

  • Splitting the management layer (cameras, users, settings) from the processing layer (video and events)
  • How a new AI model is checked and approved before it reaches a site; shared APIs and sign-in
02

Write

  • The detection path itself, and the camera and event APIs
  • How work is queued, and how each customer's data is kept separate on the busiest paths
03

Delegate

  • UI and mobile after contracts are fixed
  • Repetitive asset conversion once patterns exist

Never delegate

  • What an event means, and the rule for dropping frames instead of delaying alerts
  • Signing software updates for on-site appliances
  • Checking the customer's identity on every path that reads data

Selected projects

Real systems, running in production

The three central projects come first, followed by four further ones. Each account starts with the operational problem and a diagram of the system, then sets out the decisions that shaped it, the trade-offs they carried, where the limits lie, and the part I personally owned.

The three central projects

Marine Fire Detection & Automatic Firefighting · TVT Group, 2021–2024

Shore-side monitoring for a fleet-scale marine fire platform

Operators on shore monitor several hundred vessels. When sensors suggest a fire risk, that signal takes its own fast path, while live video lets a person verify before acting.

ResultLive HLS about ~3s in-region and ~5s cross-region for operator verification; safety events isolated from routine telemetry volume.
Main trade-offExtra paths and read models cost more than one table, but a routine backlog must not delay a safety event.
ApplicationRemote fleets; control rooms that need live video before deciding a response.
View case study

Enterprise platform · TVT Group, 2021–2024

Strangler migration from a .NET Framework monolith

One large .NET system was replaced piece by piece — one business area at a time, while the old system kept running. Deployments fell from about two hours of manual work to about fifteen minutes.

ResultDeploy time from about 2 hours to about 15 minutes after CI/CD and service split; first domain service extracted without a big-bang rewrite.
Main trade-offSmaller services increase network and operational surface; the win is safer, faster change on the domains that hurt most.
ApplicationLegacy .NET estates that must modernise without stopping the business.
View case study

Further projects

Smart Water Metering & Pipeline Monitoring · TVT Group, 2021–2024

City-scale smart water metering with separated ingest and reads

Household water meters across a city report to one monitoring centre. Freezing risk and water flowing the wrong way are spotted from patterns over time, not from a single stray reading.

ResultOperational monitoring across a major city's household meters; alerts driven by window rules, not single samples.
Main trade-offRead models lag ingest by seconds; operators accept that instead of scanning raw history on every dashboard load.
ApplicationCity-scale utility networks with bursts of readings through the day.
View case study

Construction BIM & LiDAR Platform · InnoVerse, 2024–present

As-designed models and as-built LiDAR in one coordinate frame

What was designed (the 3D model) and what has actually been built (a drone laser scan) are shown together in the same project coordinates — but a scan on its own never changes the official progress record.

ResultFederated models open from converted view files; LiDAR overlays the design in the project frame; field readings never write official progress.
Main trade-offSurvey evidence requires engineering confirmation, so a scan cannot become a pay quantity on its own.
ApplicationProjects comparing design with reality without letting a scan become the official record.
View case study

HRM SaaS · AI Assistant · InnoVerse, 2025–present

Permission-scoped AI over live HR data

An assistant embedded in a multi-tenant HRM, answering and acting through the platform's own services, limited to what the signed-in user may already see or do.

ResultDozens of governed tools across personal, team, and company HR scopes; every tool call audited; leave submission only after explicit confirmation.
Main trade-offScoping the model to existing permissions limits what it can answer, but an assistant that sees more than its user is a data breach.
ApplicationProducts with sensitive data where an assistant must respect each user's permissions.
View case study

Smart Office Platform · Tech Heart (Tini Group), 2024–2025

Multi-tenant smart office backend with IoT access control

One backend decides who may open which door — by smart lock, fingerprint, or card reader — and buildings keep a predictable rule when the network drops. A later change of product direction reused that foundation instead of rebuilding it.

ResultFirst product shipped in about 2 months with scope cut; team of 9 onboarded with mandatory review; platform pivot without re-architecting identity.
Main trade-offKeeping shared tenant and auth cores speeded the pivot; domain-specific tables and devices were what we replaced, not the security model.
ApplicationBuildings whose readers must follow a predictable door rule while offline.
View case study

Technical stack

The technology behind these systems

Four areas, grouped by the kind of problem they solve. The tools follow from the problem, not the other way round.

Edge and server computer vision

RTSP ingest, YOLO-family detection, bounded queues, DeepStream on Orin NX, signed updates.

RTSPYOLOTensorRTDeepStreamJetson Orin NX

Event-driven backends

RabbitMQ paths with different SLAs, Redis dedup on alerts, batch and aggregate reads.

RabbitMQRedisNestJSPostgreSQLTimescaleDB

Fleet IoT and .NET migration

Marine shore backends, water-meter ingest, strangler split from .NET Framework 4.7 to .NET 7.

Node.jsHLS.NET 7AWS

Multi-tenant product cores

OIDC identity reused across products, BIM job queues, permission-scoped HRM assistant.

OIDCNestJSIFCLLM tool calling

Capabilities

What I can run, not just build

Building a system is only part of the work. These are the disciplines that keep it running, safe to change, and within its boundaries once people depend on it.

Server and GPU server administration

Linux servers in production — reverse proxy, TLS, Docker on AWS — and modern GPU machines used to build and validate inference models before they reach a site. The same discipline runs the Jetson appliances in the field.

CI/CD process design

The pipeline work behind the 2-hour to 15-minute deploy change, the standard CI and AWS template cloned for each new project, and mandatory-review weekly releases for a greenfield team.

Team building and delivery process

Building and onboarding engineering teams (up to 10, and 9 at a greenfield company): branching and review rules, and one vertical slice per new engineer in week one so the process is learned by shipping.

Security, from small systems to layered environments

Security sized to the risk. A small internal system gets clean sign-in, tenant separation, and reviewed code. A restricted environment — a laboratory, a site whose video must not leave — gets layers that do not trust each other: identity checked on every data path, permissions resolved before any action (or before an AI assistant may even see a tool), devices holding only a time-limited snapshot of who may enter, signed updates verified before installation, and sensitive actions written to an audit trail. One layer failing does not open the next.

Business analysis in deep technical domains

Turning domain rules into system rules: when a water network is at freezing risk, which vessel events are safety-class, when a scan may not become official progress, and who may see which HR record.

Advanced mathematics

I studied mathematics at Ho Chi Minh City University of Science, leaving after two years when a full-time engineering opportunity was the better path at the time — but I never stopped studying; the research simply moved into the work. I use that foundation on real problems: deciding whether a person actually entered a restricted zone or only passed its edge, and how long they stayed; placing the design model and the field scan in the same coordinate system so the two can be compared — and not concluding “not built” when a scan simply did not see something; and selecting HVAC fans by checking whether a fan's performance curve meets the required airflow and pressure, then ranking the fans that do. In short: I am used to numbers that have to be right, and to knowing when a number is not yet enough to conclude from.

Work history

Where I have worked

  1. 05/2018 — 03/2021

    Backend Developer · Modoho

    Greenfield .NET/Node marketplace backends, thousands of daily users, Jenkins and Docker on AWS.

    2 yrs 10 mos
  2. 03/2021 — 03/2024

    Technical Lead · TVT Group

    Marine fire monitoring, city water metering, monolith to .NET 7 microservices, deploy 2h to 15m.

    3 yrs
  3. 06/2024 — 02/2025

    Technical Lead · Tech Heart (Tini Group)

    CI, review culture, team of 9, smart office with IoT access control. Concurrent from 08/2024; InnoVerse primary.

    8 mosConcurrent role
  4. 08/2024 — Present

    Technical Lead · InnoVerse Solution

    Camera platform, Jetson appliances, BIM/LiDAR, HRM with governed AI — team up to 10, hands-on inference and APIs.

    2 yrs 3 mosPresent

Ho Chi Minh City University of Science (HCMUS) — Mathematics, 2017–2019. Left after 2 of 4 years (no degree) when a full-time engineering role became the better opportunity; the self-study never stopped — it continued into production work.