Ask Your Dev Team about their onboarding process

The way a developer starts a project tells you a lot about how they’ll run it. And onboarding isn’t one-sided. There are two processes you should understand.

How they onboard you as a client

This is the kickoff: the transition from “we signed a contract” to “we’re building your software.” A good onboarding process should include:

• Stakeholder interviews: Your developer should sit down with the key people on your side, not just the decision-maker, but anyone who will use, manage, or be affected by the software.
• Requirements gathering: They should have a structured way to capture what you need, what your users need, and what success looks like. This isn’t a casual conversation. It’s a deliberate process.
• Timeline alignment: Before anyone writes a line of code, you should agree on milestones, deliverables, and a realistic schedule.
• Access setup: Shared tools, communication channels, project boards, repositories. The logistics should be handled early so they don’t slow things down later.

You should meet some of the people you’ll be working directly with. Not just the sales team or the account manager, but the developers and designers who will be doing the actual work. If you’re only ever talking to a middleman, that’s worth noting.

Most importantly, the process should feel natural. It should feel like the developer has done this before, because they should have. You should never be in the guessing seat or leading the process. They should be guiding you. If you find yourself asking “so what’s next?” more than once, something is off.

How they onboard new developers onto your project

What happens when a new developer joins your project mid-stream? Maybe someone leaves the team, or they’re scaling up to meet a deadline. Either way, there should be a process for getting a new person up to speed without losing momentum.

Ask your developer:

1. “How do you bring a new developer onto an existing project?” Listen for documentation, knowledge transfer sessions, pairing with an existing team member, and ramp-up timelines.
2. “How do you minimize disruption when the team changes?” Good teams have enough documentation and process that one person leaving doesn’t create a crisis.
3. “How long does it typically take for a new developer to be productive on a project like mine?” An honest answer here builds trust. If they say “day one,” be skeptical.

Red flags

• They skip discovery and jump straight to coding. If your developer doesn’t invest time in understanding your business, your users, and your goals before writing code, they’re building on assumptions. That’s expensive to fix later.
• There’s no established process. If the kickoff feels improvised, if they’re figuring out the logistics as they go, that’s a sign of inexperience.
• You’re left figuring out next steps. A developer who can’t lead a kickoff will struggle to lead a project. If you’re the one driving the process, you’re doing their job for them.

---

Expect better. Build better.