Ending a 6-Year Marathon: A Full-Stack Engineer's Reflections on "Vanity Projects"
On June 30, 2026, a 6-year project journey concluded as the client brought operations back in-house. This reflection explores the non-technical variables that dictate project survival, including the pitfalls of "vanity projects," the consequences of lenient management, and the challenges of being a full-stack resource. I share lessons on establishing rigorous evaluation systems, the necessity of mutual respect in client relationships, and the shift toward more sustainable, institutionalized business models.
The Finish Line of a Six-Year Marathon: When a Full-Stack Engineer Encounters "Vanity Projects"
On June 30, 2026, following the client's decision to bring the project in-house, I concluded a six-year project journey. This was not just the end of a project cycle, but a "cultivation" process spanning over two thousand days. As an engineer, during this experience from 2020 to 2026, I witnessed how interpersonal gaming and management decisions—beyond the technology itself—reshaped the trajectory of the business.
Today, I would like to take this opportunity to review and discuss the "non-technical" variables that truly determined the life and death of the project beyond lines of code.
1. The "Opening Crit" of Blind Expansion
Looking back at the project's inception, that decision could be considered a classic textbook example of what not to do. The decision at the time was not based on business logic or profit margins, but on management's desire for "face" and "big-company reputation," leading to a stance of forcing the project acceptance through what was essentially "shameless" persistence.
- The bitter fruit of low-price strategies: Attempting to exchange "cheap selling" for an entry ticket often leads to a total loss of dignity. A partnership lacking mutual respect and reasonable pricing is destined for passivity and unreasonable demands in communication from the very first line of code.
- Lessons for engineers: Regardless of technical strength, if a project lacks rationality at the source, no sophisticated architecture can save the "foundation" of the business.
2. The "Happy Trouble" of a Full-Stack Engineer
During the project, I demonstrated full-stack capabilities—from frontend, backend, and server architecture to AI and AR/VR. This ability to "one person covers a whole team" was a lifesaver at the start, but it became a trap later on.
"With great power comes great responsibility, but if you don't manage the boundaries well, your ability will become 'taken for granted' in the eyes of the client."
This comprehensive technical coverage led the client to falsely assume the company possessed equivalent overall delivery capacity, which led to unrealistic staffing requirements that completely ignored the chasm between an individual and a team.
3. Management's "Saintly Heart" and Team Growing Pains
This is perhaps the part I reflected on most during these six years. In an environment lacking an objective evaluation system, the "saintly heart" shown by management—excessive tolerance and unprincipled compromises—severely damaged the project quality.
- Excuses for "workplace bullying": When the team encountered code quality issues or procedural violations, some members would refuse to improve by citing "mental and physical distress," even characterizing the management's corrections as "Power Harassment."
- Polarization of talent: The team included "potential stocks" like the person who switched from medicine to IT and became a Team Leader capable of handling tasks independently within a year and a half; but there were also members who had mental breakdowns at every turn due to a lack of responsibility. This phenomenon reflects both the lack of mental resilience among some young people in certain environments and the collapse of team combat effectiveness due to the absence of institutional guarantees.
4. The "Schrödinger's State" of Client Relationships
The progress of the project largely depended on who the specific "person in charge" was.
- Excellent contact persons: Possess professionalism, can effectively coordinate conflicts between the two sides, and act as a force multiplier for the project.
- Incompetent contact persons: Only know how to blindly "read the room," and instead of providing substantial support, they drag the project into endless ineffective communication and resource attrition.
5. Reflections After the End
Although the process was full of twists and turns, this review has made me more firm in several principles, which may provide some reference for peers struggling in the "sea of bitterness":
- Screening clients is the number one productivity factor: Never take on projects for the sake of "face" or so-called relationships. Reasonable value exchange and mutual respect are the foundations of project survival.
- Systems are superior to sentimentality: Corporate management cannot be maintained by a "saintly heart." A rigorous assessment system must be established to let processes, rather than emotions, manage issues to ensure an objective and fair progress.
- Core control: Key aspects must be handled personally. This is not a lack of trust in the team, but a necessary tactic in game theory—you must master core resources to occupy the initiative in a complex environment.
These six years of "tossing and turning" are extremely valuable from the perspective of technical accumulation and management review. In the future, I will bid farewell to this mode of bottomless expansion and pursue a more stable, institutionalized, and high-quality business model.
