What Went Wrong? A Tech Director’s Post‑Mortem on a Failed E‑Commerce Project

Project and Team Background

The project was a second‑development of a mall system that required distribution functionality and integration with internal product/customer data APIs. Requirements changed frequently, with more than three major workflow changes within a month. The team consisted of about eight people (four developers, three designers, one product manager). Development was split into front‑end and back‑end streams, but the director’s attention was overly focused on the front‑end. The planned development cycle was roughly 20 days, while the director was simultaneously overseeing four other projects, limiting hands‑on involvement. Two members had prior experience with similar projects, and testing was mainly performed by two engineers.

What I Did Wrong

The director admits several critical errors:

Prioritising progress tracking over quality management.

Neglecting thorough code reviews and quality checks.

Allowing major functional bugs to reach production, such as a primary workflow that could not complete, a distribution feature that reported success without actual data settlement, printing data errors, synchronization failures, and database disconnections caused by long‑running functions.

Reflections

Speed cannot replace quality; sacrificing one for the other improves neither.

Even under tight schedules, basic testing is essential.

Trust must be balanced with vigilance; experienced developers still need guidance.

When unable to oversee everything, assign a dedicated person to manage the project.

Control requirement changes and reject unreasonable requests.

Implement lightweight, continuous code reviews to catch issues early.

How I Fixed the Issues

Thoroughly reviewed all main workflow requirements with the developers.

Spent three days analysing the code, adding necessary comments, and deploying fixes to the production environment.

Dedicated over half of each workday to code review and bug fixing, often working late into the night.

Collaborated side‑by‑side with developers during fixes to ensure correctness.

Optimised problematic features and improved user experience to regain customer trust.

Added comprehensive code comments and documentation for future maintenance.

Lessons Learned

Design (requirements) must precede development.

Delegate management authority to a responsible lead.

Code review is non‑negotiable, regardless of circumstances.

Compromising code quality for speed jeopardises project timelines and client satisfaction.