Why Planning Is More Important Than Building: A Hard Lesson From Real Projects

One of the most important lessons I learned about software projects didn’t come from a successful delivery.
It came from my first freelance project and from a situation where lack of planning caused confusion, frustration, and real loss of time for everyone involved.

How It Started: A First Freelance Project

At the time, this was my first experience working as a freelance frontend developer.
A more experienced developer I had recently met told me she was involved in an early-stage startup and that they were looking for someone to help with the frontend. I joined the project feeling reassured by her presence and experience, assuming she would guide the technical direction.
The client was an entrepreneur from London.
We were all based in Berlin.
He didn’t have technical knowledge himself, but he had experience working with tech teams and startups. He understood roles at a high level, just not the technical details behind them.
From the very beginning, however, something critical was missing: clear communication about roles, responsibilities, and expectations.

Hidden Expectations from Day One

The client had several conversations with the more experienced developer and assumed that by doing so, he was handing over full responsibility for the technical side of the project.
In reality, she was focused primarily on writing code not on leading the project, defining structure, or coordinating the team.
This mismatch was never explicitly discussed.
At some point, the client asked for my opinion on how to approach the frontend. For him, that question meant: “You are in charge of this.”
For me, it was simply a request for input and I assumed I was being asked to complete a task, not to take ownership.
Neither of us was wrong. But nothing was clarified and the communication was already carrying hidden assumptions on both sides.

When the Structure Disappeared

Things became more complicated when the more experienced developer had to step away from the project due to personal reasons.
Suddenly, the already fragile structure disappeared entirely.
The client asked me to help find another backend developer. I reached out to my network and suggested someone. The client had a conversation with him and decided to bring him on board.
One other problem was that neither the client nor I had enough backend knowledge to properly assess whether this person was capable of delivering what the project required.

There was still:

• no clear technical lead
• no shared plan
• no milestones
• no definition of what “progress” or “done” meant

Remote Work Without Visibility

We were a remote team but we nevver act like one. Communication was informal and unorganize.
We had a group chat where we occasionally exchanged messages. When the client visited Berlin, we would meet for lunch but we had no fix meetings to sync work or to demo what has been done.
After some time, I noticed that the backend developer wasn’t pushing code to the main repository. During syncs, he spoke in very general terms about what he was doing. There was always a reason why nothing concrete could be shown yet.
At the time, I didn’t immediately see this as a red flag. I was inexperienced, and I simply didn’t imagine that someone could pretend to work without actually delivering.

The Point of No Return

After two or three months, the situation became clear: The frontend was essentially finished. The backend was not.
Shortly after, the backend developer stopped replying altogether. No explanation. No handover. No way to reach him.
The client was understandably angry. He had lost time: the most valuable resource in an early-stage startup. And he was facing a project that could not move forward.
At that point, expectations shifted suddenly: I went from being “the frontend developer helping out” to being treated as the person responsible for fixing the situation and moving the project forward.
It was a shock and a very painful learning experience.

What Actually Went Wrong

The failure wasn’t just about one developer disappearing.
The real issue was the absence of planning, explicit ownership and clear communication from the very start.

There was:

• no shared understanding of who was responsible for what
• no agreed structure for collaboration
• no checkpoints to make progress visible
• no system to detect problems early

The project relied entirely on trust in the flow and in “they are developer, they know what they are doing”. Wrong, even a 20+ years experience developer can make a project go bad. Good in coding or software development doesn't automatically means good in managing a project.

Why “Let’s Just Start Building” Is Risky

In previous company roles, Agile practices had always been present: planning, clear roles, regular reviews, shared visibility. I often felt it was “too much”, “overdoing with planning” but this was the first time I experienced the cost of not applying it. And let me tell you, I have heard many other freelancer telling similar stories. Is easier then it seems to end up in such a situation, you just want your product done fast and someone is there for you smiling, telling they can do “let’s just start!”.

The outcome is rarely dramatic at first but almost always expensive in the end:

• misaligned expectations
• delayed delivery
• wasted effort
• stress and frustration

How You Can Avoid This Happening to You

If you are working with freelancers or agencies, these practices can drastically reduce risk:

• Make roles explicit: Who is responsible for decisions, coordination, and delivery?
• Define what progress looks like: How do you know work is actually moving forward?
• Avoid isolated work: No one should work for weeks without showing results.
• Write expectations down: Even a simple document can prevent major misunderstandings.

Even minimal planning would have revealed the issues in my first freelance project within weeks.

Final Thought

Building feels productive. Planning often feels like a delay.
But without planning, development can easily become an illusion of progress. Of’course is important to be aware of over planning and that planning doesn’t remove all risk. Is not possible to plan everything! But planning does makes risk visible early, when it can still be managed.