Implementing AI at STR Network: From Technology to Management

"AI isn't a tech problem. It's a management problem." That's Sunny, co-founder of STR Network, in Business Weekly issue 1963.

It sounds like a line from a consulting deck. But at STR Network (薩泰爾娛樂), Taiwan's largest satirical-comedy production company, it's a description of engineering order. While most companies are still comparing ChatGPT, Cursor, and n8n to figure out which one is strongest, this co-founder has flipped the question around: first define what the company actually needs to manage. Then the tools mean something.

This piece is a tour of the internal systems STR runs on Zeabur. But the order of the story — and why STR's engineering tempo doesn't match the usual "startup moves fast" picture — starts with how they organize themselves.

At a glance

I. How STR Onboards AI and Other New Tools

STR Network started in satirical comedy and produces shows including The Night Night Show with Brian Tseng. The DNA is content — writers' rooms, production, talent management. The engineering department is, strictly speaking, one person: Feng.

From Zeabur's vantage point, STR ships internal systems faster than content companies of similar size. Not because the team has more engineering muscle. Because the roles inside the team are crisp.

Co-founder Sunny owns the brief. She defines what the company manages, who sees what, how permissions split, what framework catches each new tool as it comes in. That layer of judgment gets compressed into a brief and handed downstream.

Feng turns the brief into running systems. Process audit and engineering build aren't a relay race here — they're two people at the same table. Feng will read Sunny's spec and ask back, "does this field really need that permission scope?" and sync with her at the weekly brief.

It's the Sunny-decides + Feng-builds structure that filters every new tool and system before it enters the company — not a single engineer carrying governance, design, and construction at the same time. STR has been running this "governance structure" for years. The real reason most mid-sized companies are drowning in AI tools right now is that they don't have it.

Concretely: every show has to reserve anywhere from 20 to 200 complimentary tickets — for board guests, press, business partners, talent contacts, and an assistant for each VIP. The contracts to sign each year, the talent payment slips to track, the ticketing reports to reconcile — the volume crossed the threshold of what a Google Sheet can hold a long time ago.

Everyone knows they should systematize. STR was already attacking this problem systematically in the pre-AI era. For a company without an engineering department, the next question is never "which AI tool should we use?" — it's "what are we actually trying to manage?" STR was thinking about this as far back as 2022, when ChatGPT launched — and even earlier, in the GPT-3 era.

II. The Three Layers of "Management Debt" at STR

"Management debt" is a phrase Sunny used in the Business Weekly 1963 interview, and it's the opening epigraph of this piece. In her conversation with Zeabur she unpacked it further — into three layers.

Layer 1: Management has to be defined before system design.

"Once management is defined, the system designs and concepts can grow out of it."

Her concrete example: the internal idea of a "ledger." A single show project might run two or three ledgers; each ledger has different permissions; all of them roll up to the same project. Whether a system can do that is an engineering question. The precondition for doing it is that the management layer has already defined the rules — payroll is personal data, do not expose; meal expenses can be filed by any assistant. In engineering terms, the data permissions get defined first.

Without step one, step two has no foundation.

Layer 2: Every small change has a communication cost.

"Adding a tag, adding a status, adding a user role, adding a thing to use — the cost is high. The communication cost is high."

Adding a column to a spreadsheet is free. Once it's a system, every field change pulls on engineering time, permission design, downstream maintenance, and training the relevant roles. Working that chain out — counting time and counting people — is something STR finishes before deciding to build. Not letting engineers move first and then mopping up the communication fallout.

Layer 3: When the person leaves, the system has no inheritor.

Sunny is cautious about migrating the system (specifically, the INVITI guest-invitation project Jerry kicked off, covered below) from a Google Sheet to a custom-built web app. She put it plainly, with a dark joke (the comedy company hazard — everyone tells jokes):

"It's fine if I get hit by a truck and die tomorrow. But if Feng leaves, this whole thing — nobody else knows how it works, nobody can pick up the maintenance. That problem hasn't actually been solved yet."

Systematizing a process creates a new dependency, and that dependency lands on the one engineer. "Management debt" at this layer means: until you've cleared the "only one person understands this" dependency, every new system you build is more debt taken on.

Stack the three layers and you get what management debt means at STR — not a question of which tool to use, but the discipline of laying out what the organization manages, who manages it, who sees what, defining it, tracking it, and then deciding whether to systematize. The discipline matters more now, not less, when writing anything is trivially easy.

III. "Tech Debt" Is Sunny's Direct Concern About Vibe Coding

STR is not anti-AI. The opposite — they've run a round of automation, hooked up RAG with Gemini Embedding, and Sunny herself writes Claude Code Skills. What she's worried about is something else — the new AI management problem. Near the end of the interview she said it bluntly:

"STR is okay — operations and business model are stable. But a lot of younger companies, in the recent AI anxiety, have a sprint mindset. Everyone wants to make a lot of things, layer them on top of the existing product. The painful part is that people might build a hundred similar things that are basically duplicate work. Pushing vibe coding indiscriminately actually creates a bigger efficiency problem — more tech debt, and the operational debt that comes with it."

"If you just tell ChatGPT or Cursor that you need a system, what you get back is going to be pretty bad," Feng said in an interview with Global Views Monthly.

Tech debt and operational debt — those are the two risks she named outright. The day after the interview (April 2), she made a public Facebook post titled "How to Read the Vibes" that filled out the worry:

"What I've cared about isn't how strong any individual becomes — it's what we never have to do again that interests me. And my deepest fear is that mass construction turns into more illegal-structure tech debt and management debt. When everyone gets tired of maintenance and construction is cheap, we lose belief in 'how to design a framework that lasts.'"

"Illegal structures" — her concrete image for what runaway vibe coding produces. One sentence later she pivoted:

"Don't get me wrong, I'm not anti-construction. The whole point of needing a management framework is so you can construct without fear."

Her response was to write a Dev Diagnosis Skill — now public on GitHub as a Claude Code Skill. The README opens with "before you build, identify the value," followed by the sharper line: "high-efficiency garbage production is still garbage production."

The Skill breaks incoming requests into four stages — diagnose → choose treatment → triage → ship. Sunny explained the evolution in her Facebook post:

"Last year at STR Network I made an issue-triage flowchart that crossed 'scope × duration × complexity' to produce three severity levels for how we should govern. But 'scope × duration × complexity' is itself too abstract. I kept thinking about the skill of diagnosis — patients can describe symptoms, and a doctor's wisdom is in mapping symptoms to a diagnosis and then a treatment."

In other words, she's rewriting the management framework itself. Instead of teaching users the "scope × duration × complexity" vocabulary, she lets them describe symptoms, and the Skill maps symptoms to the development mode that fits.

A Skill isn't a tool. It's company governance written into markdown. Sunny's own summary: "What I care about is whether a team can hit consensus on basic judgment calls. Once consistency goes up, then you can amplify what different individuals bring to the table."

The answer to "construct without fear" is to look at every new system, at the source, with structure and intent, and ask whether building it is actually necessary.

IV. The Systems Running on Zeabur

Below are the products and systems STR Network runs on Zeabur. Some live on Zeabur's shared cluster (no new projects after 2026-02-23), some run on their own GCP machines through BYOS.

1. INVITI — the guest invitation system

INVITI didn't start with code. It started with the CEO's assistant, Jerry, spending a month auditing the comp-ticket workflow because it had become a headache to handle.

As mentioned above: every STR show reserves 20 to 200 complimentary tickets depending on scale — for board guests, press lists, the business team's partners, the talent team's media contacts. Behind every ticket is a relationship; every relationship has an assistant. The volume blew past what a single Google Sheet could carry.

Sunny and Feng described what Jerry did: "He spent about a month at the start auditing the entire guest-invitation flow he himself walks through." He turned the full invitation process into a "role mapping" document — who invites whom, which role sees which fields, how ticket types get classified, what happens at each step. The document isn't a system architecture diagram. It's the actual real-world flow.

Then Feng spent a month and a half building the database and frontend. On Zeabur's role in this — what made the in-house build possible — he was direct:

"Zeabur's biggest help here was one-click Postgres. Before that, we had basically nothing for data deployment outside of BigQuery and other Google services. One-click Postgres on Zeabur made local testing a lot easier. When I don't have to test in the cloud, my costs drop a lot."

2. The operations platform — the internal hub that pulls every number and process together

"The whole thing is deployed on Zeabur," Feng repeated four times in the interview. He's talking about the internal hub — STR's operations platform — that handles expense filing, talent payment slips, ticketing performance reports, project lists. "Every number in the company gets collected. It all flows into this one site."

The architecture is a full web stack: Django + Celery at the app layer, PostgreSQL for data, Redis running workers and background jobs, django-celery-beat for scheduled tasks, Nginx as reverse proxy. Feng mentioned that "we didn't deliberately push toward microservices, but looking back we already have the embryonic form" — services decoupled, running independently, isolated from each other. That said, this is still some distance from microservices in the strict sense, with independent databases and independent deployment (Pan, a Zeabur backend engineer, gave a SITCON 2025 talk on what microservices actually are). STR is iterating the system; the next stage is to progressively isolate services — lowering dependency risk and improving development velocity at the same time:

"Ideally, this service lives on this host, and the other service lives on a different host."

But the hard part of the operations platform isn't the technical stack. It's permissions.

Sunny pointed out that the team behind a large production is, at its core, outsourced collaboration — most of the people working an event aren't full-time employees. Which ledgers they see, which projects, which payroll data — it all has to be cleanly partitioned. The system uses RBAC, but Sunny's earlier line is the precondition: "Once management is defined, the system designs and concepts can grow out of it."

The "ledger" idea STR designed into project management — one project can have two or three ledgers, each with different permissions, all rolling up to the same project — is essentially the Principle of Least Privilege (PoLP) from information security. Each role sees only the ledger needed to do their job. Nothing extra.

The design intent is that external contractors can come into the system and prep work for full-time staff: "These are our internal tools, but they can't be internal-only. If they're internal-only, they hit a ceiling — they get bottlenecked by the internal team's throughput," Sunny added.

That's the outward-facing side. Same management logic applied inward: does every internal team member really need to see every ledger? The answer is obvious, but the harder question — when accountability inside the company gets involved, who gets which view — is the next-level challenge.

External-to-internal permissions, user-facing-to-underlying isolation — those two axes braided together are the next management problem any company hits after AI adoption. STR has solved the entry-level version, and is now iterating the system itself, pushing back on the management framework as it grows.

3. Back-office Slack bot with RAG

This one had been deployed for one day before the interview.

Inside STR there's a Slack channel called #help-總務 ("back-office help") where people ask: what's the Wi-Fi password, what's the company shared login, how do I book a meeting room, which bus number gets to the office. The original bot was keyword matching written in Apps Script, with a Google Sheet for a backend. If the columns didn't line up, no answer; the same question would sometimes trigger two or three duplicate replies.

Feng moved the whole thing onto Zeabur: Gemini Embedding 2 API (released March 10, 2026) for semantic vectors, the PG Vector template (one-click on Zeabur) for vector storage, Python FastAPI as the backend. On timing, his explanation captures STR's engineering tempo:

"It has nothing to do with the model. The Gemini Embedding 2 API happened to drop on March 10, and this just sat on my to-do list. It already worked — it was just keyword-based originally, no LLM involved."

It's not "the model dropped, build it immediately." The need had been on the list. A new tool finally raised the priority enough to schedule it. On Zeabur's role, Feng put it simply: "Zeabur made deployment easy. We used to run it on Apps Script, which was kind of like the LINE backend. Now we wrap FastAPI and run it on Zeabur."

The RAG also has a self-iteration loop: when the system can't find an answer, it queries why it couldn't, runs a semantic check, and adds the case back to the database. Feng emphasized that this takes time to compound — it gets "smarter" over the long run.

V. How These Systems Run on Zeabur

Stack the needs of these systems together and Zeabur's role at STR comes into focus. Zeabur doesn't replace an ops team — it reimagines what "ship a system to production and keep it running" should look like, so an existing team member, with Zeabur Agent as backup, can do what previously took a whole ops team to carry.

That's the empowerment frame. At STR, the engineering team is Feng — one person. One person manages multiple production systems without having to know what kind of host each runs on, without hiring dedicated staff for "deploy to production," "make sure nothing breaks at 3 a.m.," and "keep database backups and performance healthy." The operations get handled through three Zeabur capabilities:

• One-click deployment templates. INVITI starts with Postgres. The back-office RAG bot starts with PG Vector. The custom web apps run on Postgres and Redis. Feng describes this as collapsing the cost gap between "local testing" and "cloud testing." For an engineer running the whole stack alone, that directly determines how fast he can iterate and test new ideas.
• Hybrid cloud management. Some core production runs on their own GCP servers; deployment, monitoring, and logs all go through Zeabur's interface, while other resources are deployed on hardware purchased through Zeabur itself. The server pool is mixed (STR even has on-prem Mac machines they're considering bringing under Zeabur), but the ops surface is one.
• Unified abstraction layer. The operations platform alone is six services (Django, Celery, Redis, Postgres, Nginx, django-celery-beat); add INVITI, the back-office RAG bot, and other core systems on GCP — every service's health shows up in the same Zeabur dashboard, visually managed in one place.

For teams that already have dedicated infra staff, Zeabur lets the same people do operations faster and with less effort — freeing up the time for the work that actually needs domain judgment: iterating the architecture, hitting security compliance, planning how the system grows next.

VI. Back to "AI Adoption Isn't a Tech Problem"

"AI adoption isn't a tech problem, it's a management problem" doesn't mean AI doesn't matter.

It means: before AI, you need a complete inventory of resources and processes (often years of accumulated internal data), a judgment framework that Sunny has passed through multiple times before it gets coded, and a precise accounting of the communication cost of every small change. That's how STR has handled the two hardest parts of AI adoption — management debt and tech debt:

The underlying management debt and the tech debt it spawns surface as what look like technical chaos — too much architecture, too many services, the faster you ship the faster it breaks. The root cause is always "the management system was never defined." STR solves the root with two things:

• The "Sunny brief × Jerry × Feng" three-person governance structure from Sections I and II, plus the ledger model and RBAC permissions — the organization has long since defined what gets managed, who manages it, and who sees what.
• Sunny's recent Dev Diagnosis Skill, which runs a diagnosis on every incoming request — catching the ones that look technical but are really undefined management, on the spot, to stop the "illegal structure" of duplicate-wheel building.

Once management debt is paid down and the request structure is clear, what's left is operations — getting the system running and keeping it stable. That layer is handled by Zeabur Agent — one-click Postgres, one-click FastAPI to production, scheduling services from one host to another, every service's status pulled into the same dashboard.

There's a next layer waiting underneath: once a system scales to multi-collaborator, multi-host, multi-environment, who can access which host, who can change which service, who can read which log — that's the management need that grows out of the technology itself, and the challenge STR is currently working through with Zeabur.

The tools keep changing in the AI era — Apps Script to FastAPI, keyword matching to RAG, shared cluster to BYOS — but the underlying audit logic hasn't.

"AI isn't a tech problem. It's a management problem." That's how Sunny put it.

References

• He Pei-Shan and Chen Ying-Ying (2025-06-26). "AI Pioneer STR Keeps Tearing It Down and Rebuilding — To Do AI, First Sort Out Your 'Management Debt.'" Business Weekly, issue 1963.
• Tseng Tzu-Hsuan (2025-02-27). "Behind The Night Night Show: How STR's Team-Wide AI Adoption Leveled Everyone Up." Global Views Monthly.
• Sunny (2026-04-02). "How to Read the Vibes." Public Facebook post + GitHub repository mseatingtpe/dev-diagnosis-skill.
• Yuanlin Lin (2026-02-23). "Phasing out the shared cluster for new projects." Zeabur Changelog.