Most of my work over the past few years has not been isolated module development. It has been about taking a business system from a vague idea to something that can run, be delivered, and keep evolving, often under limited resources and changing requirements.

That is why I like to use “system owner” to describe a way of working. It is not a title, and it is not just a project assignment. It is a sensitivity to the completeness of a system: being able to write code, change APIs, investigate performance issues, and deploy servers, while also understanding why the business needs the system, which requirements must come first, what risks may affect delivery, and how to make the system genuinely usable for customers or internal teams.

This article is closer to a record of how those projects shaped my engineering judgment and the working style I care about.

A System Owner Is Not Just “the Person Responsible for a System”

The word “responsible” is often used lightly. Being responsible for a system may only mean maintaining a repository or handling a few feature requests.

For me, a system owner needs to cover at least six things:

1. Translate business problems into system boundaries.
2. Make tradeoffs across time, budget, people, and technical stack.
3. Own the architecture, APIs, and code on the critical path.
4. Deploy the system into a real environment and handle issues after launch.
5. Communicate with business teams, customers, designers, modelers, operations, and other roles.
6. Take responsibility for outcomes, not only for individual features.

None of these things sound complicated in isolation. In real projects, the hard part is that they affect one another.

A CRM system, for example, is not just a customer table plus a follow-up record table. If the business depends on advertising traffic, then landing-page traffic spikes, lead ingestion speed, client-manager assignment rules, invalid-lead recycling, manager statistics, and future permission expansion all influence the system design. If the early version only optimizes for getting pages written quickly, the system will often pay for that later in data flow and permission boundaries.

Why I Use This Lens to Organize My Experience

During the internet finance stage at Ruida Futures, I worked on a business that needed systems from the early stage. The team grew from around 20 people to roughly 200 client managers, and the systems eventually processed 120,000+ sales leads and 970,000+ follow-up records.

The most valuable lesson was not how any one page was implemented. It was how business change and system evolution pushed each other forward.

The early goal was direct: receive leads from ad campaigns, let client managers follow up, and give managers visibility into the process. The first CRM and landing-page system was launched quickly with Laravel + Inertia.js + React, solving the immediate usability problem first. As the team, data volume, and management needs grew, the CRM later evolved into a React/UmiJS + Laravel architecture to improve maintainability across frontend and backend work.

In that process, the system owner has to keep judging when a simple solution is the right way to buy speed, when boundaries need to be refactored, which features are core to the business, which ones only make the system look complete, which technical debt can wait, and which debt will quickly affect growth.

A similar full loop appeared in the Zhurun Investment projects. That work was not just customizing a WordPress page or building an admin table. It covered server selection and purchase, environment setup, WordPress site customization, private-placement product display, consultation forms, backend product management, customer information management, WeCom touchpoint integration, and ongoing maintenance. Those projects were not all large, but they shared one trait: the business cared about whether the whole chain could run reliably.

“It Can Go Live” Is Only the Beginning

The biggest difference between ToB systems and personal projects is that a ToB system really starts being tested after launch.

The private live-streaming platform is a good example. The team wanted to use live streaming to serve investment customers, but external SaaS platforms usually charged by traffic and concurrency, making cost difficult to control. So the system was not just a web project. It included hardware selection and purchasing, director workflow design, staff training, cloud-service procurement, backend implementation, viewer pages, comments, online-user statistics, and long-term operations.

From an engineering perspective, the first version could use relatively direct implementation choices. From a system-owner perspective, the more important question was whether it could support the business reliably over time. The system ran from 2022 until the later rebuild, serving 70,000+ customer visits and 1,000+ live sessions. When it was time to rebuild, the old system’s real operating data and bottlenecks became the basis for judging the new solution.

Similar lessons came from BIM and digital delivery projects. A BIM resource collaboration platform is not just file management. It needs a reusable business structure around models, rendered images, panoramic photos, drawings, department and role permissions, and delivery materials. The Macau Electric substation digital O&M project was not just an admin panel either. It required a UE client, a web management backend, and a Laravel API to work together around equipment data, station layouts, panoramic photos, and maintenance records.

These projects made me more certain that the value of a system owner often appears in work that sits outside code but still depends on technical judgment.

How I Judge Whether a System Has Been Owned Well

I do not only look at whether the requirement list has been completed. I care more about a few questions:

• Did the system help the business do something that was previously impossible, inefficient, or too expensive?
• Is the core data flow clear enough for future troubleshooting?
• Do permissions, APIs, deployment, and operations leave room for future iteration?
• When requirements change, can the system still adapt at an acceptable cost?
• After delivery, can the next maintainer understand the system through its documents and structure?

If these questions have no answers, a system may go live in the short term but become a burden during the next phase of growth or delivery.

The Working Habits These Projects Left Behind

These projects made me less likely to judge work by whether a feature list has been completed, and more likely to look at the relationship between system design, business needs, and delivery conditions.

I care about the things that are hard to show in screenshots but decide how long a system can live: how to draw boundaries when requirements are still unclear, how to choose a stack that balances speed and maintainability, how to connect frontend, backend, deployment, APIs, permissions, and statistics, how business feedback enters the next iteration, and how edge cases after launch are recorded and handled.

I do not think a system owner has to do everything personally. But they need to know what must not be missed, which judgments should not be left to habit, and which technical choices will affect system quality months later.

Looking back, the most durable experience is not only familiarity with a framework. It is the ability to think through system boundaries, implementation paths, and future maintenance under incomplete requirements, limited resources, and real launch pressure.