What to Look for When Hiring a Freelance Web App Developer

Hiring a developer is one of the most expensive decisions a business owner makes, and one of the hardest to get right. Most of the advice online is written by developers, for developers. This article is different. It's a practical checklist written for the person writing the check. Use it even if you never hire me.

The Problem: You Can't Tell Good From Bad

Here's the uncomfortable truth about hiring a developer: if you're not technical, you have almost no way to evaluate whether someone is actually good at their job. And the entire freelance ecosystem makes it worse, not better.

Portfolio sites all look the same. Every developer has a clean website with a few screenshots and the words "modern," "scalable," and "user-friendly" sprinkled throughout. You can't tell from a portfolio page whether the person built something real or just designed a mockup in Figma and never wrote a line of code.

Upwork profiles are full of five-star reviews, on $200 projects. A developer with 47 glowing reviews for building WordPress landing pages and fixing CSS bugs is not the same as someone who has built and deployed a production web application that real users depend on. The skills don't transfer. A five-star review for "fixed my contact form" tells you nothing about whether that person can architect a database, build an authentication system, and deploy a full-stack application.

LinkedIn endorsements are meaningless. Certifications prove you passed a test, not that you can build software. GitHub profiles are written in code you can't read. The entire system is designed to make every developer look roughly equivalent, and they're not. Not even close.

So what do you actually look for? The rest of this article gives you concrete, specific things to check, no technical knowledge required.

Ask to See Deployed Projects, Not Screenshots

This is the single most important thing you can do, and it costs you nothing but five minutes of your time.

When a developer shows you their work, don't accept screenshots. Screenshots can be faked. Screenshots can come from templates. Screenshots can show a beautiful design that was never actually built, just a picture of what it was supposed to look like.

Instead, ask: "Can you send me a link to something you've built that's live right now?"

Then actually go to the URL and click around. Here's what you're looking for:

• Does it load fast? If the page takes more than 2-3 seconds to load, that's a quality issue. Modern web apps should feel instant. If their own showcase project is slow, imagine what yours will be like when they're under deadline pressure.
• Does it feel professional? You don't need to be a designer to sense quality. Does the spacing look intentional? Do the fonts feel chosen, not default? Does it look like a real product or a homework assignment?
• Do the features actually work? Click the buttons. Fill out a form. Navigate between pages. Try it on your phone. You're not doing a technical audit, you're doing what any user would do. If things feel broken or half-finished in their portfolio piece, that's a major red flag.
• Is it a real application or just a landing page? There's a massive difference between building a marketing site and building a web application with user accounts, data management, and business logic. Many developers pad their portfolio with static websites and call themselves "full-stack developers." Ask specifically: "Does this have user authentication? A database? An admin panel?"

If a developer can't show you a single live, working application, not a screenshot, not a video demo, not a "it's on my local machine" excuse, that tells you everything you need to know. Move on.

Look for Full-Stack, Not Just Frontend

This is where a lot of business owners get burned, and it's worth understanding even if you're not technical.

A web application has two halves. The frontend is what you see, the buttons, the layout, the colors, the forms. The backend is everything you don't see, the server that processes requests, the database that stores your data, the authentication system that verifies who's logged in, the API that connects everything together.

Many freelancers who call themselves "web developers" only build frontends. They can make something that looks great in a browser, but there's nothing behind it. No real database. No server logic. No authentication. When they need backend work done, they either outsource it to someone you've never met, try to hack it together with no-code tools, or just... skip it.

The result? You get a beautiful frontend connected to a fragile, poorly built backend, or no backend at all. The app looks done, but it doesn't actually work reliably. Data gets lost. Logins break. Features that seemed to work in the demo fail in production.

Ask this question directly: "Will you personally build the frontend AND the backend yourself?"

If the answer involves phrases like "I work with a team" or "I have a backend partner" or "we'll use Firebase for that", you need to understand what you're getting. "I work with a team" might mean they're outsourcing to someone in another country who you'll never communicate with. "I have a backend partner" means two people need to coordinate, which doubles the communication overhead and the chance of things falling through the cracks. "We'll use Firebase for that" might be fine, but you should know if the developer actually has experience building server-side logic or if they're relying entirely on a third-party platform.

The ideal answer is simple: "Yes. I build the whole thing."

Fixed Price vs. Hourly Billing

This is one of the most important conversations you'll have with any developer, and most business owners don't realize how much it matters until they're already locked into the wrong arrangement.

Hourly billing creates a fundamental misalignment of incentives. When a developer bills by the hour, they make more money when the project takes longer. They have no financial incentive to be efficient, to avoid scope creep, or to find the simplest solution to your problem. Every extra meeting, every "let me research that," every detour into unnecessary complexity, it all adds to the bill.

I'm not saying hourly developers are deliberately dragging projects out. Most aren't. But the incentive structure is working against you regardless of the developer's intentions. A task that could take 4 hours gets done in 6 because there's no pressure to be efficient. A feature that could be simple gets overengineered because more complexity means more billable hours. A two-week project drifts into six weeks, and you're paying for every day of that drift.

Hourly billing also makes it impossible to budget accurately. "I estimate 200-400 hours at $150/hour" means your project could cost anywhere from $30,000 to $60,000, and most hourly estimates come in at the high end or beyond. You're essentially signing a blank check.

Fixed price flips the incentive. When a developer commits to a fixed price, they make more money by being efficient. They're motivated to find the simplest, most reliable solution, because unnecessary complexity eats into their margin, not yours. They're motivated to stay on schedule, because delays cost them, not you. And you know exactly what you're paying before the first line of code is written.

The question to ask is straightforward: "Is this a fixed price, or will I be billed hourly?"

If the answer is hourly, ask: "What's the maximum this could cost me?" If they can't give you a ceiling, that's a problem. If the ceiling is significantly higher than the estimate, that's also a problem. You deserve to know the cost before you commit.

Communication Style Matters More Than You Think

Ask any business owner who's hired a developer about their biggest complaint. It won't be about the code. It will be about communication.

The developer who disappears for two weeks. The one who sends cryptic one-line updates that don't actually tell you anything. The one who says "almost done" for three consecutive weeks. The one who never pushes back on anything you say and then delivers something completely different from what you discussed.

Bad communication isn't a minor annoyance, it's the number one reason freelance projects fail. A mediocre developer with great communication will deliver a better outcome than a brilliant developer you can't reach.

Here's what to look for, and you can evaluate most of this during your initial conversations before you've hired anyone:

• Response time. How long did it take them to reply to your initial inquiry? If it took three days to get back to you when they're trying to win your business, imagine how responsive they'll be once they have your money. Good developers reply within hours, not days.
• Clarity without jargon. When they explain something, do you actually understand it? Or do they hide behind technical terminology that makes you feel stupid for asking? A developer who can't explain their work in plain English either doesn't understand it well enough themselves or doesn't respect your time. Either way, it's a problem.
• Proactive updates. During the project, will they send you progress updates without you having to ask? Or will you spend your weeks wondering what's happening and sending "just checking in" messages? Ask them: "How will you keep me updated during the build?" Their answer, and how specific it is, tells you a lot.
• Willingness to push back. This one is counterintuitive. You actually want a developer who will tell you when an idea won't work. If you suggest something that's technically problematic or unnecessarily complex, a good developer will say so, respectfully, clearly, and with an alternative suggestion. A developer who just says "yes" to everything isn't agreeable, they're passive. And passivity leads to missed expectations.

The initial conversation is your audition window. Pay attention to how it feels. If communication is smooth, clear, and responsive now, it will probably stay that way. If it's already rocky, it will only get worse once the project starts.

Red Flags to Watch For

After enough conversations with business owners who've been burned, a clear pattern emerges. These are the warning signs that show up again and again in projects that go wrong:

1. They can't show you live projects

Every developer should have at least one deployed, working application they can point you to. "I can't share that because of NDAs" might be legitimate once, but if they can't show you anything live, that's a problem. Even NDA projects can usually have a general description and confirmation that something was built and shipped.

2. They won't commit to a timeline

"It depends on the scope" is fine as an initial response. But once the scope has been discussed, a good developer should be able to tell you when it will be done. If they refuse to commit to any timeline, they either don't have enough experience to estimate accurately or they're leaving themselves an open-ended runway to bill against.

3. They give you a low estimate then charge overages

This is the classic bait and switch. The initial quote is attractively low to win the deal. Then the "unexpected complexities" start appearing. The database "turned out to be more complicated than expected." The integration "required additional work." The final bill is 2-3x the original estimate. If a developer's initial estimate feels too good to be true, it probably is.

4. They disappear for days between responses

During the sales process, disappearing for days is inexcusable. This is when they're supposed to be making their best impression. If they go dark for 72 hours before the project even starts, imagine what happens in week three of the build when something hard comes up.

5. They use a lot of jargon without explaining things clearly

Some developers use technical language to create an information asymmetry, they know things you don't, and they want to keep it that way. It makes them feel indispensable and makes it harder for you to hold them accountable. A good developer makes you feel smarter after talking to them, not dumber.

6. They want you to sign a long-term contract before starting

A six-month retainer. A multi-phase agreement where you're committed to phases 2 and 3 before phase 1 is delivered. A contract that locks you in regardless of quality. These structures protect the developer, not you. You should be able to evaluate the work before committing to more of it.

7. They can't explain their tech stack choices

If you ask "Why did you choose this technology?" and the answer is "it's what I know" or "it's industry standard" with no further explanation, that's a developer making decisions based on their own convenience, not your project's needs. A good developer should be able to explain, in plain English, why each major technology choice is the right fit for what you're building.

One red flag might be a coincidence. Two is a pattern. Three means you should walk away.

Green Flags

Red flags tell you who to avoid. Green flags tell you who to take seriously. Here's what the good ones look like:

1. They show you live, deployed work

Not mockups. Not screenshots. Not "here's a video walkthrough of what I built." They send you a URL, you open it in your browser, and it works. The application loads fast, looks professional, and does what it's supposed to do. This is the baseline.

2. They commit to a fixed price and a timeline

They tell you what it will cost and when it will be done, in writing, before the project starts. Not a range. Not "approximately." A number and a date. If things change because you change the requirements, they communicate that clearly and you agree to any adjustments before they happen.

3. They respond within hours, not days

During the initial conversation and throughout the project. You text a question, you get an answer the same day. You don't spend your evenings wondering if your developer fell off the face of the earth.

4. They explain things in plain English

They talk to you like a person, not like a fellow engineer. When they need to explain a technical decision, they use analogies and clear language instead of acronyms and jargon. You leave conversations feeling informed, not confused.

5. They give you the source code

When the project is done, you own everything, the code, the database, the deployment configuration. It's yours. You can take it to any other developer in the world if you want. This is non-negotiable. If a developer wants to retain ownership of the code they built with your money, that's a huge red flag disguised as standard practice.

6. They have a clear process

They can tell you what happens in week one, what happens in week two, what you'll see and when. The process isn't "we'll figure it out as we go." It's structured, it's predictable, and it gives you visibility into what's happening at every stage.

7. They tell you honestly when something isn't a fit

A developer who turns down work because a project is too big, too small, or outside their expertise is a developer you can trust. It means they care more about doing good work than about collecting fees. If a developer says "yes" to literally everything you ask, they're either overcommitting or they don't understand what you're asking for.

You don't need all seven on the first call. But by the time you're ready to sign, you should have evidence of most of them.

Questions to Ask Before You Hire

Here are ten specific questions to ask any developer before you commit. You don't need to memorize them, just copy this list and work through it during your initial conversations. The answers will tell you almost everything you need to know.

1. "Can you send me a link to a live application you've built?", Not a screenshot. Not a video. A URL you can visit right now. If they can't produce one, the conversation is over.
2. "Will you build the frontend and the backend yourself?", You want to know if you're hiring one person or unknowingly hiring a team you'll never talk to. Either can work, but you deserve to know which one it is.
3. "Is this a fixed price or hourly?", And if it's hourly: "What's the absolute maximum this could cost?" Don't accept vague ranges. Get a ceiling in writing.
4. "What's included in the price, and what's NOT included?", This is where hidden costs live. Hosting, domain setup, third-party API costs, post-launch changes, bug fixes, get all of it on the table now. "What happens if I need changes after launch?" should have a clear answer.
5. "Who owns the source code when the project is done?", The only acceptable answer is "you do." If the developer retains ownership, you're renting the code, not buying it. That means you're dependent on them forever.
6. "What happens if the project takes longer than expected?", A good answer involves the developer absorbing the extra time at no additional cost (assuming you haven't changed the scope). A bad answer involves charging you more. The best answer is a fixed timeline with a clear scope agreement.
7. "What's your process? Walk me through what the first two weeks look like.", Vague answers like "we'll start by discussing requirements" aren't good enough. You want to hear something specific: "Week one I map out every feature, build the database schema, and set up authentication. You'll see a working prototype by Friday. Week two..."
8. "How will you keep me updated during the build?", You're looking for a specific cadence. Daily updates? Weekly demos? A shared channel where you can see progress? The format matters less than the commitment to doing it consistently.
9. "Can I talk to a past client?", This isn't always possible, especially for developers who work with businesses under NDAs. But the willingness to offer a reference says a lot. A flat "no" with no explanation is concerning.
10. "What tech stack will you use, and why?", You don't need to understand the technology. You need to understand the reasoning. "I'm using Next.js because it gives you fast page loads and good SEO out of the box, and Neon Postgres because it's a reliable database that scales well and keeps hosting costs low" is a good answer. "It's what I always use" is not.

Print this list. Bring it to every conversation. The developers who welcome these questions are the ones worth hiring. The ones who get defensive or evasive are telling you something important.

How Mike Stacks Up

I'll be straight with you, this is the part where I tell you how my own service lines up with the checklist above. I'm including it not as a pitch, but because I wrote the green flags list based on how I actually work, and it'd be dishonest to pretend otherwise.

Here's the short version:

• Live deployed work. I'll send you links to applications I've built. You can click around, try them, and see the quality for yourself.
• One developer, full-stack. I build the frontend and the backend myself. No outsourcing, no unnamed team members, no handoffs to people you've never spoken to. When you text me a question, I'm the person who answers, and I'm the person who built the thing you're asking about.
• Fixed price. Not a range, not an estimate, not "starting at." It covers design, development, authentication, deployment, and two weeks of post-launch support. If the project takes me longer than planned because I underestimated something, that's on me. The price doesn't change.
• Fixed timeline: 3 weeks. Week one is scoping and architecture. Weeks two and three are design and full-stack development. At the end of week three, your application is deployed and live.
• You own everything. The source code, the database, the deployment configuration, all of it is yours. You can take it to any developer in the world. You're not locked in to me for maintenance or updates.
• Direct communication. You text me. I text back. No project managers, no ticketing systems, no "I'll loop in the team." Just one person who knows your project inside and out because they're the one building it.
• I'll tell you if it's not a fit. If your project is too big for three weeks or better served by an off-the-shelf tool, I'll tell you that. (Not sure whether you need custom software or a platform like Salesforce? The Custom vs. Salesforce comparison can help you decide.) I'd rather give you honest advice and lose the sale than take your money and deliver something that doesn't meet your needs.

That's it. No hard sell. You've got the checklist, use it on me, use it on anyone else you're talking to, and go with whoever checks the most boxes.