Hiring a web developer is one of the highest-leverage decisions a business owner makes. Get it right and you have a partner who ships quality software on time and on budget. Get it wrong and you burn $5,000 to $50,000 on code that does not work, a timeline that slips by months, and a relationship that ends in frustration. The difference between those outcomes comes down to what you evaluate before you sign anything.
I have been on both sides of this. I have hired developers for projects and I have been the developer getting hired. Here is the 10-point checklist I would use if I were evaluating developers today, plus the red flags that should make you walk away.
The 10-Point Checklist
1. Portfolio with Shipped Projects
Not mockups. Not Dribbble concepts. Not personal projects that never launched. You want to see live, production websites and applications that real users are using right now. Ask for URLs. Visit them. Check if they load fast, work on mobile, and feel polished. A developer's portfolio is the single strongest predictor of what your project will look like when it ships.
What to look for: diversity of project types (marketing sites, dashboards, SaaS apps), consistent quality across projects, and evidence of recent work within the last 6 months. A portfolio with 12 projects from 2023 and nothing since is a warning sign.
2. Tech Stack Alignment
The developer's primary tech stack should match what your project needs. A React specialist is not the right hire for a WordPress site. A PHP developer is not the right hire for a real-time dashboard built on Next.js. Ask what frameworks, languages, and tools they use daily. Not what they could learn. What they ship with right now.
The MGT stack is Next.js, TypeScript, Tailwind CSS, Prisma, PostgreSQL, and Vercel. Every project I ship uses these tools because I have thousands of hours of production experience with them. A developer who can articulate their stack with that level of specificity knows what they are doing. A developer who says "I can work with anything" probably does not go deep enough in any one stack to be fast.
3. Communication Style
Before you evaluate their code, evaluate their communication. Do they respond within 24 hours? Do their messages make sense to someone who is not a developer? Do they ask clarifying questions or make assumptions? Do they push back when a request does not make sense, or do they just say yes to everything?
The best developers I have worked with communicate clearly, set expectations proactively, and flag problems before they become expensive. The worst developers I have worked with go silent for days, deliver surprises, and treat every question as an interruption. You can assess communication quality in the first 48 hours of any engagement. If it is bad at the start, it will not improve under project pressure.
4. Pricing Model
Understand exactly how you will be billed before any work starts. Hourly billing creates a conflict of interest where the developer earns more the longer the project takes. Fixed pricing aligns incentives because the developer is motivated to ship efficiently. The full breakdown of why fixed pricing beats hourly is in the fixed pricing post.
If the developer quotes hourly, ask for a cap. If they refuse to cap, ask what happens when the project takes twice as long as estimated. If the answer is "you pay for the additional hours," you are taking on all the project risk while the developer takes on none. That is not a partnership. That is a blank check.
5. Timeline with Milestones
A credible developer gives you a timeline broken into milestones, not a single delivery date weeks or months in the future. Milestones let you verify progress, catch scope drift early, and make informed decisions about changes. A timeline without milestones is a promise without accountability.
Ask for weekly or biweekly checkpoints where you can see working software, not just status updates. "Design phase complete" is not a milestone you can verify. "Homepage and services pages deployed to a staging URL" is. The difference matters because it determines whether you find out the project is off track at week 2 or at week 12.
6. References from Past Clients
Ask for 2 to 3 references from past clients, ideally from projects similar to yours. Call them. Ask: Was the project delivered on time? On budget? Would you hire this developer again? What went wrong? The last question is the most important one because every project has friction and how the developer handled it tells you more than how they handled the easy parts.
A developer who cannot provide references is either too new (risky for your budget), has only worked on internal projects (limited client management experience), or has burned bridges (obvious red flag).
7. Contract Terms
Read the contract. Every line. Key things to verify: payment schedule (milestone-based is ideal), what happens if either party wants to terminate, who owns the code at each stage of payment, what "completion" means (specific deliverables, not vague language), and what is included in the quoted price versus what costs extra.
The most common contract dispute is over scope. If the contract does not define scope precisely, any disagreement about what was included becomes a he-said-she-said argument. A good developer writes scope documents in plain language that a non-technical person can understand and verify.
8. IP Ownership
You should own the code when the project is paid for. Full stop. Some developers and agencies retain IP ownership and license it to you, which means they can revoke access, charge for future modifications, or reuse your custom work for other clients. Your contract should explicitly state that all intellectual property transfers to you upon final payment.
Also clarify: do you get the source code, the deployment configuration, the domain credentials, and the hosting account access? Owning "the code" is meaningless if the developer controls the deployment and you cannot move to another host without their cooperation.
9. Maintenance Plan
Software does not stop needing attention after launch. Security patches, dependency updates, hosting monitoring, SSL certificate renewals, CMS updates, and bug fixes are ongoing responsibilities. Ask the developer what post-launch support looks like. Is it included for a period? Is there a monthly retainer option? What is the response time for critical issues?
A developer who hands you the code and disappears is not a partner. A developer who offers a maintenance plan that covers the boring but essential work of keeping software running is thinking about your success beyond the initial invoice.
10. Cultural Fit
This one is subjective but real. Do you enjoy talking to this person? Do they understand your business or are they just nodding along? Do they challenge your assumptions in a way that makes the project better, or do they just build whatever you describe without questioning whether it is the right thing to build?
You are going to spend weeks or months in regular communication with this person. If every interaction feels like pulling teeth, the project will suffer regardless of technical skill. Trust your gut on this one. A slightly less experienced developer who communicates well and cares about your outcomes will outperform a technical genius who treats your project as just another ticket in the queue.
Red Flags to Walk Away From
- No portfolio or only mockups. If they cannot show you shipped production work, you are paying them to learn on your project.
- Vague pricing. "It depends" without a framework for what it depends on is a sign they have not scoped enough projects to estimate accurately.
- No contract. Any developer willing to start work on a handshake is either too inexperienced to know better or planning to use the lack of documentation to their advantage later.
- Guaranteed timelines for undefined scope. If they promise 4 weeks before understanding what you need, they are either going to miss the deadline or cut corners to hit it.
- Resistance to milestone-based payments. A developer who wants 100% upfront is asking you to assume all the financial risk. Milestone payments protect both sides.
- Bad-mouthing previous clients. Every developer has worked with difficult clients. How they talk about those experiences tells you how they will talk about you if things get hard.
- No questions asked. A developer who takes your brief and starts building without asking clarifying questions either does not understand the project or does not care about getting it right.
Questions to Ask Before Signing
Beyond the checklist items, ask these questions in your final evaluation call:
- "What is the most common reason projects go over budget, and how do you prevent it?" (Tests their self-awareness and process maturity.)
- "Walk me through how you handle a situation where a client requests something outside the original scope." (Tests their scope management approach.)
- "What does your testing process look like?" (A developer who does not test is a developer who ships bugs.)
- "What happens to my project if you get sick or have a personal emergency?" (Tests their contingency planning. For solo developers, this is especially important.)
- "Can I see the staging environment during development, or do I only see the final product?" (Transparency during development is non-negotiable.)
Why Fixed Price Changes the Hiring Equation
Half of the risks on this checklist disappear when you work with a fixed-price developer. Budget overruns are the developer's problem, not yours. Timeline incentives are aligned because the developer earns the same amount whether the project takes 3 weeks or 6. Scope is defined upfront because the developer cannot price it without understanding it.
The full case for fixed pricing is in the fixed pricing post. If you are ready to hire and want to skip the checklist because MGT already checks every box, the contact page is the next step.