You found someone with a great portfolio, reasonable rates, and fast replies. You’re ready to hire. Then three months later you’re sitting on broken code you don’t own, a project that’s 40% done, and a developer who’s gone quiet. It happens more than most people admit — and it’s almost always preventable.
These five questions will tell you everything you need to know before signing anything.
1. Can You Show Me Something You Built That’s Live?
Not a mockup. Not a case study with screenshots. A URL that works, right now, that real users are using. Any developer worth hiring has at least one live project they can point to.
If every example is under NDA or “in progress,” that’s a red flag. If they can show you live work, ask how long it’s been running and whether they handled the deployment. Shipping code and maintaining it are very different skills.
2. Who Owns the Code When We’re Done?
The correct answer is: you do, fully, from day one or upon final payment. Any other answer — licensing arrangements, retaining “framework” rights, keeping the repository — is a problem.
Get this in writing before work starts. Some developers, especially agencies, build on proprietary internal frameworks that leave you dependent on them forever. You want clean ownership of everything: source code, repositories, credentials, infrastructure.
3. How Do You Handle Scope Changes?
Every project has them. What matters is the process. A professional developer will tell you how change requests are scoped, quoted, and approved — before they happen, not after.
Watch out for two extremes: “we handle small changes for free” with no definition of small, and rigid refusal to accommodate any change without a formal contract amendment. Both create problems. You want a developer who has a clear, fair process and can explain it without hesitation.
4. What Does Handoff Look Like?
This question alone separates professionals from everyone else. At the end of the project, you should receive: access to all repositories, documentation for how the system works, deployment instructions, and credentials for every service.
If a developer looks confused by this question, or tells you “you can just call me if anything breaks,” walk away. You need to be able to hand this codebase to any other developer in the future without being held hostage.
5. How Do You Communicate During the Project?
Frequency, format, and response time. A good developer will tell you exactly how they work: weekly updates, a shared project board, response within 24 hours during business days. Vague answers here — “I’ll keep you posted” — predict a vague working relationship.
For AI or complex technical projects, also ask how they handle blockers. The best developers surface problems early and come with proposed solutions, not just status updates.
Red Flags at a Glance
| Signal | What It Usually Means |
|---|---|
| No live work to show | Limited real-world shipping experience |
| Unclear code ownership terms | Potential lock-in or IP disputes later |
| Quote with no written scope | Budget will grow, expectations won’t match |
| No documentation at handoff | You’re dependent on them indefinitely |
| Slow or inconsistent communication pre-hire | It gets worse once they have your money |
| Significantly cheaper than everyone else | Cutting corners somewhere — find out where |
The cheapest quote is rarely the best value. A $5,000 project that leaves you with unmaintainable code will cost $15,000 to fix. Every time.
What Good Looks Like
A developer who answers all five questions clearly, without hesitation, and backs it up with real examples is worth paying for. They’ve done this before, they know what handoff looks like, and they respect your ownership of the work.
That’s the baseline — not a luxury, not a premium service. Just professional.
If you want to work with someone who can answer every one of these questions before you even ask — let’s talk. I’ll walk you through how I work, what you’ll own, and what the project will actually take.