We often get calls from founders or managers who've already worked with a developer or agency, and it went badly. Missed deadlines, exploding costs, code that can't evolve. It doesn't have to be that way.
Choosing the right tech partner is a skill. Here's what we look at when we evaluate our own practices, and what you should look at when shopping around.
The first meeting tells you a lot
Before even talking about technology or price, watch how the developer or agency reacts to your first description of the project.
Do they ask about your customers, your goals, your constraints? Or do they jump straight into frameworks and architectures?
A good partner first seeks to understand the problem. They restate your vision to show they've grasped the essentials. If you leave the first call feeling like the other side understood what you want to build, that's a good sign.
💬 What we want to hear on the first call
"Tell me about your users. What problem are you trying to solve for them? What happens today if that problem isn't solved?" A developer who starts with these questions thinks like a partner, not a subcontractor.
Freelancer, small agency, or big firm?
It's not a question of prestige or budget. It's a question of risk and need. Here's how we see the three options:
| Freelancer | Small agency | Big firm | |
|---|---|---|---|
| Cost | Lowest | Medium | High |
| Expertise | Often one specialty | Multidisciplinary | Broad but fragmented |
| Availability | Variable | Dedicated | Shared across projects |
| Departure risk | High | Low | Low |
| Best for | Simple, short-term MVP | Evolving projects, SMBs | Large accounts, big budgets |
No option is universally better. It all depends on your project's complexity and the level of risk you're willing to absorb.
Ask to see real work, not just client logos
Everyone has a nice client page on their site. What matters is seeing how that work was actually done.
Ask for examples of features similar to what you want to build. Ask if you can talk to a past client. Check whether the projects shown resemble your context (size, industry, complexity).
- ✓"Can you show me a feature similar to what I want to build?"
- ✓"Can I talk to one of your past clients?"
- ✓"Have you worked in my industry or on projects this size?"
- ✓"How do you handle scope changes mid-project?"
- ✓"Who will be my main point of contact day to day?"
Process matters as much as technical skill
A good developer can still produce bad work if the process is chaotic. Here are the indicators we consider non-negotiable:
- ✓Regular deliverables. Something functional every two weeks, not just a verbal status report.
- ✓Transparent priority management. You should be the first to know when a deadline shifts or a problem comes up.
- ✓Accessible tracking tools. Jira, ClickUp, Notion, doesn't matter which, as long as you can see the project status at any time.
- ✓Regular code reviews. The code gets reviewed by someone other than the person who wrote it.
Red flags to watch for
Certain behaviors are clear warning signs. If you spot more than one, take the time to think before signing anything.
- ✕They say yes to everything, with no questions and no reservations.
- ✕The quote arrives in a few hours, with no real analysis of the project.
- ✕No clear contract on code ownership after delivery.
- ✕They can't explain their technical choices in simple terms.
- ✕Client references are vague or impossible to find.
- ✕They refuse to run a discovery phase before coding.
Security isn't optional
We still see a lot of projects delivered without tests, without code review, with passwords stored in plain text or dependencies that are never updated.
Ask how your users' data is protected. How access is managed. If the developer doesn't have a clear answer, that's an answer in itself.
⚠️ Don't neglect security
A data breach can cost far more than the initial development. Make sure your partner talks about security from the design phase, not just at the end.
And after launch?
Software isn't a project with an end date. It's an asset that needs to be maintained, improved, updated.
If your partner doesn't talk about post-launch support, ask directly. And if the answer is vague, take note.
- ✓Who handles bugs after launch?
- ✓Who manages security updates?
- ✓What's the response time if something breaks?
- ✓How does adding a new feature in six months work?
What we rarely tell you
Human fit matters. You'll be working with this team for months. If communication is hard from the start, it doesn't get better over time.
💡 A good partner tells you no
Choose someone you can have an honest conversation with. A partner who says "there's a problem with your idea here" is far more valuable than one who says yes to everything. The easy yes always costs more later.
