Hiring someone to build technology for your business is one of the highest-stakes decisions you'll make. Get it right and you save thousands of hours. Get it wrong and you're stuck with something that doesn't work, built by someone who's already moved on to their next client.
Here are the questions that separate the good hires from the expensive lessons.
Can you show me something similar you've built?
Not a portfolio of unrelated work. Something similar to what you need. If you want an AI chatbot for your e-commerce store, ask to see an AI chatbot they've built for e-commerce. If they only have marketing websites in their portfolio, they're learning on your dime.
Bonus points if they can connect you with a past client you can talk to. Willingness to share references is a strong signal of quality.
What happens after you deliver?
This is the question most people forget. What if something breaks next month? What if you need changes? What does support look like? Some developers hand you the files and disappear. Others offer maintenance plans.
Get this in writing before the project starts. The cost of post-launch support should be part of your budget, not a surprise.
How do you handle scope changes?
Every project evolves. You'll realize mid-build that you need something different from what you originally described. A good developer expects this and has a clear process: change request, updated timeline, adjusted price. A bad one either says yes to everything (then misses deadlines) or charges you surprise fees.
Ask specifically: "If I need to change direction on a feature, what does that process look like?"
Will I own the code?
This seems obvious, but it's not always the case. Some developers retain ownership of the code and license it to you. Others use proprietary frameworks you can't take elsewhere. Make sure your contract specifies that you own the final product — code, designs, and all deliverables.
If they won't agree to that, walk away.
What's the realistic timeline?
Notice the word "realistic." Everyone gives optimistic timelines. Ask what the best case, likely case, and worst case scenarios look like. If they only give you the best case, add 50%. If they've built similar things before, they should be able to give you a confident range.
The biggest red flag? A timeline that sounds too good to be true. It always is.