How I Delivered a Sub‑Brand in Three Weeks Amid the Pandemic

The company was expanding rapidly and the CEO wanted to launch a sub‑brand to test the lower‑tier market; offline stores were ready, but the CTO insisted that the online systems be finished within three weeks, just as the pandemic began.

Instead of holding an immediate planning meeting, the author first asked the CTO which of the three project‑management elements—time, scope, quality—was most critical. The CTO replied that speed was paramount and that the main flow only needed to work, allowing the offline and online parts to operate together.

Based on this answer, the author decided on the largest architectural move: copy all code from the main brand and adapt it for the sub‑brand. He chose this because the organization lacked a middle‑platform, modifying the main brand would be risky, and the sub‑brand was a trial that could be discarded without harming the core system.

"You are the technical and project lead; decide the solution."

The CTO gave full authority, confirming the plan and stating that the author could seek his help if any issues arose.

With the priority clarified, the author set immutable weekly milestones:

Week 1: deploy all micro‑services for the sub‑brand (both front‑end and back‑end), configure them, and enable testing.

Week 2: testing team reports bugs, developers fix them.

Week 3: launch, online verification, and product‑owner acceptance.

No negotiation was allowed; the schedule was communicated in the leader chat with a note that the CTO had approved it.

During the first week, each technical manager identified required services, data, and configuration, replaced brand‑specific messages, and coordinated with operations to deploy everything. Developers performed self‑testing of the main flow in the test environment, together with a product manager. P0 and P1 issues had to be resolved the same day; remaining lower‑priority bugs could be addressed later. The team worked overtime on Saturday, and the author reported progress to the CTO on Sunday.

In the second week the system was handed over to QA. Because the most familiar testers were assigned, bugs were fixed quickly, no overtime was needed, and the QA lead expressed strong satisfaction with the quality.

When HR announced that Shenzhen staff would work from home the following week, the author switched to daily plans posted in the leader chat, specifying what each person must finish that day and what the next day’s tasks would be. This kept remote work disciplined and allowed the offline store opening to stay on schedule.

The project was delivered on time, earning praise from the product lead and the CTO, as well as a salary increase for the author. Although the sub‑brand was later closed, the main brand’s code remained untouched, validating the low‑risk copy‑and‑adapt strategy.

Key takeaways include: always clarify the boss’s top priority among time, scope, and quality; create a concrete, immutable plan that gives the team clear direction; avoid unnecessary alignment meetings; use daily or weekly checkpoints to maintain rhythm in remote settings; ensure early self‑testing and involve knowledgeable testers to guarantee quality; and choose a simple architectural solution for trial projects to keep risk low.