Your developer is not your vendor.

Process · 6 min read

I tell every client the same thing before they start looking for a developer. Think of this person as your business partner. Not your contractor. Not your supplier. Your partner. Because for the next three to six months, this is the closest working relationship you'll have. Closer than your accountant. Closer than your designer. They're going to be inside your idea every day, making decisions that affect how it works, how it feels, and whether it holds together under pressure.

Most first-time founders don't think about it that way. They think about it like getting the bathroom tiled. Get three quotes. Pick the one that fits the budget. Wait for the job to be done. And then they're surprised when it doesn't go well.

Why the vendor mindset fails

When you hire a tiler, the job is defined. Lay tiles in this room, this pattern, this grout colour. Done. App development isn't like that. Even with a thorough design spec, there are hundreds of decisions the developer will make during the build. How to handle edge cases you didn't think of. How to structure the data so it scales. What to do when the API you planned to use doesn't work the way the documentation promised.

Those decisions happen every day. And if the developer doesn't understand your product, your users, and what you're actually trying to achieve, they'll make those decisions based on what's easiest to code. Not what's best for the person using the app.

I've seen it happen. A client comes to me after working with a developer who built exactly what the spec said. Every feature was there. Every screen matched the design. But it felt wrong. The flow was clunky. Transitions were missing. Loading states were ignored. The developer wasn't bad. They just didn't care about the product the way the founder did. And why would they? They were treated like a vendor. They acted like one.

What the right relationship looks like

The best developer relationships I've seen work like co-creation. The developer pushes back on features that will bloat the build. They suggest alternatives you hadn't considered. They tell you when something in the design doesn't translate well to code and propose a solution that keeps the user experience intact. That only happens when they understand the product well enough to make judgment calls.

That means regular check-ins. Not just milestone reviews. Weekly conversations where you talk through what's being built, what's coming up, and what decisions need to be made together. It means sharing the context behind the design, not just the design files. Why does this screen exist? Who is the user at this point? What's the worst thing that could happen if this feature breaks?

It also means respecting their expertise the same way they respect yours. You know your industry. They know their craft. When they tell you something will take three times longer than you expected, listen. When they suggest a simpler approach, consider it seriously. The tension between your vision and their pragmatism is where the best products get built.

How to choose well

Don't pick a developer based on price alone. That's the vendor mindset talking. Pick them based on communication. Do they ask good questions during the quote process? Do they push back on anything in the spec, or do they just nod and give you a number? A developer who accepts everything without question either doesn't understand the brief or doesn't care enough to challenge it. Neither is good.

Ask about their process. How do they handle change requests? How often will you hear from them? What happens when they hit a problem they didn't anticipate? The answers to these questions tell you more about the working relationship than any portfolio ever will.

And if you can, talk to someone they've worked with before. Not to check their code quality. To find out what they're like to work with when things get complicated. Because things always get complicated. The question is whether your developer handles it like a partner or like someone waiting for instructions.

Sources
Developer-Designer Collaboration (Nielsen Norman Group) - Research on effective collaboration between design and engineering teams.
Getting the Most from Your Tech Partnerships (Harvard Business Review) - Why vendor relationships fail and partnership models succeed.

Related blog posts:

What to look for when hiring an app designer →

Why fixed pricing beats hourly rates →

The real cost of designing and building an app →