Starting a project? Don’t forget these three things – or it will hurt

04 July 2025

When you jump into a new project, it’s tempting to “dive right in”: discuss features, estimate tasks, make a plan. But the truth is, most pitfalls aren’t in the code. They’re waiting at the very start – when you haven’t asked enough questions, haven’t learned all you need to, and haven’t put the important stuff on paper (or at least in Google Docs).

Let’s break down three things that can save your project from chaos.

1. NDA – it’s not bureaucracy, it’s peace of mind

When a client comes with an idea, they want to share as much as possible but are afraid. And they have every right to be.
Signing an NDA is your way of saying: “I won’t leak your idea to competitors tomorrow.” That’s it. No magic.

Real case: I was once invited to teach a course for a bank. Before the first session, they sent me an NDA for 30 years. THIRTY. I asked – what exactly can’t I talk about? Answer: “Absolutely nothing.” Well, we agreed on 7 years. But the point remains – no signature, no project.

Tip: have an NDA template ready. It’s a small thing that opens big doors.

2. Vision – otherwise, where are we even going?

Very often the client says: “I want something like this.” And when you ask: “But why?” – they freeze. Vision is about understanding why we’re doing all this, not a tech doc.

It doesn’t have to be pretty. It just has to exist.

What it might look like:

  • The client’s revenue has dropped, and they want to automate processes.
  • They already have an MVP but don’t know how to scale.
  • They want a product “like X” because it’s working in the market.

This is all vision. You just need to pull it out of the client. Often not even with words, but examples, analogies, stories.

My tip: pin the vision in the team chat or on the first slide of presentations. It’s not only for the client – it’s for the team. Because if a dev doesn’t understand what they’re building, they’ll just code whatever the PM says. And that usually leads nowhere.

3. Gap Analysis – because sometimes we’re going into battle unarmed

This is the thing most people either ignore or remember only when it already hurts. Gap Analysis is a list of what we’re missing to reach the goal.

Common gaps I’ve seen:

  • No analyst, but someone thinks the dev will figure it out.
  • Client has no access to data but wants reporting.
  • Everyone expects frontend to magically do UX because there’s no designer.

None of this is scary – as long as you know about these gaps and openly talk about them. What’s worse is assuming everything’s fine and then explaining why you missed the deadline.

Tip: at the very start, sit down and honestly list everything that might be needed but isn’t there yet. No illusions.

In short

Don’t jump straight into tasks and Figma. Start with these three basics:

  1. Sign an NDA so everyone feels safe.
  2. Formulate the vision, even if it’s just a voice message in Telegram.
  3. Assess the gaps: people, access, data, experience – everything.

Every project will have some uncertainty – and that’s normal. But the better you map out the picture at the start, the fewer emergencies later. Don’t look for perfect templates – look for dialogue with the team and client. And leave room for common sense. If something feels too obvious to discuss – that’s exactly what needs to be discussed.