TATrương Tuấn AnhTuna / truongtuananh.vn

All systems

System 03MediaLive

NoLimit ERP

Chief Operating Officer (COO), since 11/2025

In-house ERP for a 19-person media agency, from idea to publication and measurement, with a Telegram assistant that chases work and routes posts for approval.

Company
NoLimit Group - media agency (Đà Nẵng)
Role
Chief Operating Officer - governance, compliance, internal control; also the person who built and runs the whole system
Status

Web on Vercel, bot on Fly.io (Singapore), its own Supabase. Staff have used it daily since July 2026.

Internal system, open inside the company only.

A mock-up rebuilt from the real structure, not a screenshot: internal system, no public address.

Metrics

  • 19internal users: 3 directors, 1 PM, 15 staff
  • 64bot actions, 41 commands, 15 scheduled jobs on Vietnam time
  • 9post states, with a hard approval gate in the data layer; every write path goes through it, the admin path included
  • 138automated test cases for the Telegram assistant, in 12 groups; the web side adds 5 more

The story

The problem

A 19-person agency produces content for several clients at once, and posts drift between stages, out of the team's sight. Before building anything I measured two sample projects: close to half the posts ran late (43/87 and 27/103), all 190 posts lacked a formal approval step, the post-publication figures were left blank, and one person carried 80 to 90% of the work.

What the team needed was a place where work stops and gets approved.

Read on: approach and principle

Approach

I took the ERP I had already built for my engineering company, shifted its center of gravity to content operations and rebuilt it: clients, campaigns, a drag-and-drop work board, a 9-step post workflow, plus a Telegram assistant that understands Vietnamese, so work is assigned, deadlines chased and posts approved inside the group chat.

Principle

The operating rule: AI drafts arrive flagged as needing approval, a person presses approve, and the system changes state only once an approval row exists. Every improvement is anchored to a measurable number, such as the share of open cards with no owner, or the share of notifications actually read.

Technical decisions

  1. The approval gate lives in the database

    Moving a post to scheduled or published requires an approval row; without that row the database refuses the write outright. The state table has to match in two places, database and code, so changing one means changing both.

  2. Every number has to be recountable

    There was a stretch when the live system showed 1,000 projects and 300 clients because the software had quietly fallen back to demo data. Now an empty screen reads as empty; rule one on this project is that every number comes from a count with somewhere to check it against.

  3. Measure before fixing

    The operations metrics are read-only and repeatable: the 25 Jul 2026 baseline showed 82% of open cards with no owner and only 4.2% of "submitted for approval" notifications read, against 84% for "work assigned". Every change in the management package is anchored to a number like that.

  4. "The site is slow", measured before it was fixed

    The database answered in 67-266 ms and pages weighed 102-222 kB, both normal; the culprit was that nothing showed a pending state, so after a click the page simply sat there. Added 12 loading skeletons matching the real layout, and kept per-user rendering because of the risk of one person seeing another's data.

From this system

Is work drifting between stages at your company too?

I measured, built and now run this system for my own agency. If you want money in and out to be reconciled and work to carry a named approver, show me how your company runs today.