What went wrong on my last project?

The past year and a half has been an intense and hard-working time for me. For the first time, I was one of the key engineers on a high-load distributed system - an experience that taught me a lot of new hard and soft skills. Unfortunately, the project was shut down a few weeks ago on the customer’s side due to budget issues. Now I finally have a moment to look back and think: what went wrong?
Believe me - a lot of things did. In a few articles I want to observe my experience, highlight issues and what I’ve learnt.

How do you usually decide whether a project is difficult or not? For me, it comes down to a few criteria: technical challenges, customer-related issues, team miscommunication, unclear management, and a lack of solid requirements.
This project? Total bingo.
The only exception was probably the team - I was lucky to work with talented and genuinely nice people. But even that didn’t save us from exhaustion and, eventually, some internal conflicts.

Some words about the system itself: our main task was to rebuild and significantly improve an already existing solution. You’d think that if something already exists, the customer would have a clear understanding of how it works and what they want from the new version. But that turned out to be far from true - the system was huge, chaotic, and full of legacy components. Even on the client’s side, knowledge was fragmented - nobody had the full picture of how the legacy system worked.

And yes, there was almost no documentation. But if you’ve worked in software long enough, you know: good documentation is more of a luxury than a standard.

One of the biggest issues I’ll talk a lot about later is requirements - or more precisely, their complete absence. In our case, we were like blind kittens. We were just handed a task that said something like: “Build a gateway to support a custom payment integration with an external provider.”
Do you know what this protocol looks like?
Do you know the third-party provider's API?
Do you know the actual payment flow - pre-checks, validations, business rules?
The answer to all of these questions was no. That’s only the most high level question you can hear. Imagine being asked to build something you have absolutely no idea about.

Now, to be fair - it's pretty common to feel a bit lost at the beginning of any project. Nobody expects you to understand everything in five seconds. That’s normal. But what if I tell you that this “first week confusion” feeling never went away? That we spent the entire project trying to guess what we were actually building?

That said, building a distributed, event-driven architecture was genuinely fun. I’ve always had this feeling that architecture might be something I want to focus on in the future - and this project confirmed it. I loved creating things from scratch, shaping systems, breaking down complex ideas into smaller, manageable parts until they finally made sense.

I guess I also need to explain what my role in all of this was.
I joined the project as a regular software engineer, together with a new team. Initially, I expected there would be a proper team lead guiding us - spoiler: I became that team lead myself. I gradually took on that team lead role myself. That probably tells you something about how loosely structured the responsibilities were in the beginning.

I had never developed such complex systems before, but I had solid engineering and analytical skills, so joining wasn't particularly painful for me. I saw it as a great opportunity to grow and learn something new.

As time went on, I started onboarding and later even managing new team members. That was never part of my formal responsibilities - but as you’ll see, someone had to bring at least some structure into the chaos. I’m actually proud of the people I worked with: they grew fast, developed strong systems thinking, and really stepped up.

Aside from me, the only other leadership figure was our tech lead. He helped me make decisions in areas I had less experience in, especially the core technical parts. But he wasn’t really focused on team management or the business picture of system development. So my role gradually evolved into designing and driving large parts of the system, helping others implement them, and supporting the team in growing their analytical and architectural skills as well.

I'll let you be the judge of what ultimately caused this project to stop - for me and many of my teammates.
But in the next articles, I want to explore the key themes that defined our experience:

• The Invisible System - how we built a working system out of scattered, half-forgotten legacy artifacts.

• Fighting the Fog - why system analysis matters, and what happens when nobody has a clear picture.

• Business Communication - how a lack of proper management can damage morale and kill momentum.

• Team Conflicts - why conflict is so hard to deal with, especially under pressure.

• The Good Parts - because despite everything, there were bright moments and valuable lessons.

This series is not meant to offend or blame anyone. It’s just my personal reflection - an attempt to make sense of a complex and often chaotic experience. The opinions expressed here are entirely my own, shaped by what I saw, felt, and learned. Any resemblance to real people, projects, or decisions is purely coincidental… or at least unintentionally accurate :)