Guide
What to ask before hiring someone to build your software
Hiring someone to build software is easy to get wrong — and expensive to get wrong. The difference between a good partner and a costly mistake usually shows up in a few questions most people forget to ask up front. Here's the checklist, and what a good answer sounds like.
By Miguel Alejandro Hayes· Founder, Hayes Projects
Who owns the code, data and accounts?
This is the question that protects you most, and the one people skip. Ask plainly: when this is built, do I own the code, the data, and the accounts it runs on? The right answer is yes — you own all of it, with the repository and access in your name. If ownership is vague, or everything lives in the developer's accounts, you don't have an asset, you have a dependency.
Follow it with: what happens if we stop working together? A good partner has a clean answer — you keep everything, and anyone competent can pick it up. If the honest answer is "it only works while you pay us," that's lock-in, and it's a reason to walk.
How do you scope, price and show progress?
Ask how they figure out cost before you commit real money. A serious answer is a short, paid validation or discovery that defines scope and a real number first — not a big quote pulled from thin air, and not "we'll figure it out as we go." You should be buying a plan, not a hope.
Then ask how you'll see progress. You want to see something working in phases, not disappear for three months and pray. "Something usable at the end of each phase" is a healthy answer; "it'll all come together at the end" is a risk. And ask what happens after launch — support should be optional, not a mandatory retainer that traps you.
Can they say no — and explain why?
The most useful signal is whether they'll tell you when something is a bad idea. A partner who says "you don't need custom software for that, a $30 tool does it" is worth more than one who says yes to everything. If every answer is enthusiastic and nothing is ever a bad fit, be careful — you want honesty, not a salesperson.
Finally, for Miami, ask if they build bilingual by default and understand the local market. And ask for how they think, not just what they've shipped: a good partner can explain the trade-offs of your project in plain language. If they can't explain it simply, they may not understand it deeply. Those questions, up front, save you the expensive mistake.
Frequently asked
What should I ask before hiring a software developer?
+
Start with ownership — do you keep the code, data and accounts, and what happens if you part ways (you should keep everything, no lock-in). Then how they scope and price (a short paid validation, not a guess), how you'll see progress (working software in phases), and whether support is optional. Finally, whether they'll tell you when something is a bad idea.
How do I avoid getting locked in by a developer?
+
Ask up front who owns the code, data and accounts, and insist the answer is you, in your name. Confirm that if you stop working together you keep everything and anyone competent can take over. If it "only works while you pay them," that's lock-in — walk.
What is a healthy way to price a software project?
+
A short, paid validation or discovery that defines the exact scope and cost before you commit to the full build, then shipping the highest-return part first. You pay for a clear plan, not an open-ended promise.
About the author
Miguel Alejandro Hayes — Founder, Hayes Projects
Economist and essayist turned developer. He founded Hayes Projects, a Miami venture studio and custom software lab, to build software that ships, scales and solves real problems.
Meet the founder→Want straight answers to all of these for your project? Book 20 minutes — no pitch — and ask us anything.
Book 20 min — no pitch →