How to choose a web developer for your business

Most bad hiring decisions in web development don't look bad going in. The developer had a nice-looking proposal, answered your emails fast, and quoted a fair price. The problems show up three weeks later, when the timeline has slipped twice and nobody can tell you why. Choosing well means catching the warning signs before you pay anything, not after.

Red flag: no real portfolio

A portfolio of screenshots proves someone can design a mockup. It does not prove they can ship a working site. Ask for live links to sites they built and actually click through them on your phone. Check whether forms submit, whether pages load quickly, whether the site looks right on a small screen. A developer with a strong portfolio will hand you links without hesitation, because they know the sites hold up under inspection.

Be specific about what you're asking: not "have you built sites like this before" but "send me three live examples I can test right now." Vague answers here ("I have plenty of work I can't share due to NDAs") are sometimes true and sometimes a way to avoid showing you something that doesn't hold up.

Red flag: vague timelines

"A few weeks" is not a timeline. Neither is "it depends" without a follow-up explaining what it depends on. A developer who has actually scoped work before can tell you: two days for a simple landing page, one to two weeks for a small business site with a handful of pages, longer for anything with custom booking or payment logic. If every answer is a shrug, that usually means they haven't built enough similar projects to know, or they're avoiding a number they'll be held to.

Ask for a written estimate with a delivery date attached, not a range that spans a month. If they can't commit to a date before you've paid anything, that's worth noting.

Red flag: 100% payment upfront

Some upfront payment is normal and reasonable, especially for smaller projects. All of it before any work starts is a different situation. It removes your only real leverage if the work turns out to be slow, low quality, or abandoned halfway. A standard structure is a deposit to begin, with the balance due on delivery or in milestones tied to actual progress you can see.

If someone insists on full payment before writing a line of code and won't discuss splitting it, treat that as a signal about how the rest of the relationship will go, not just a payment policy.

Red flag: no direct access to whoever writes the code

This one gets missed constantly. You might be talking to a sales rep, account manager, or project coordinator throughout the entire process, and never once speak to the person actually writing your site. That's fine when it's disclosed upfront and the process is clear. It's a problem when a technical question you ask gets relayed through two people and comes back vague or delayed, because nobody in the loop actually understands the code.

This is the core difference between hiring a solo developer and hiring an agency: with a solo developer, every question about how something works goes straight to the person who built it. There's no game of telephone. SolaLab is built entirely around this: one developer writes both the frontend and backend, so when a client asks why a page is slow or how a form connects to their email, the answer comes from the person who wrote that exact code, not a summary of it.

What to look for instead

Ask to see code, not just the finished visual. Even a non-technical business owner can ask a developer to walk through, on a screen share, how a page is built and what happens when a visitor submits a form. Someone who genuinely wrote the site can explain this in plain language in under two minutes. Someone reciting a template can't.

Check for basics that should already be in place by default, not added later as an afterthought: does the demo site use HTTPS, does it look right on a phone, does it load fast. These are baseline expectations in 2026, not premium add-ons, and a developer who treats them as optional extras is behind the standard.

Ask what happens after launch. Who fixes something if it breaks in month two? Is there a support arrangement, and what does it cost? A developer with a clear, direct answer to this has probably been through it before. One who seems surprised by the question probably hasn't.

The simplest filter

Before hiring anyone, ask one direct question: "If I have a problem with my site in three months, who do I contact, and will that be you personally?" The answer tells you almost everything about what you're buying, whether it's a relationship with an actual developer or a ticket queue with a rotating cast behind it.

If you want that kind of direct line from the start, describe your project and you'll be quoted and built by the same person who answers your questions later.

See SolaLab's services: what I build and what it costs