Before you hire a web developer, ask how you'll see progress between the kickoff call and the delivery date — the answer predicts how the project will actually feel far better than a portfolio does. A typical build runs four to six weeks, which is roughly twenty to thirty working days. If the only two checkpoints you're offered are the first call and the final delivery, nearly every one of those days is a black box you're simply trusting will go well.
Most people evaluating a developer spend their attention on the wrong end of the relationship. They study the portfolio, compare quotes, read a few reviews — all reasonable, and all about work that's already finished. None of it tells you what happens on day twelve, when the project is half-built and something's inevitably slower or trickier than expected. That's the part a good question can actually surface before you've signed anything.
Why the middle of the project is the part nobody asks about
A sales conversation is naturally weighted toward the start (what you'll get) and the end (what it'll look like). It's rarely weighted toward the middle, because the middle is unglamorous — it's status updates, small decisions, the occasional "we hit a snag." But the middle is also where most client frustration actually happens: not because the final site was bad, but because three weeks went past with no word, and by the time an update finally arrived, the client had already started assuming the worst.
This is exactly why our own build process runs through the client portal rather than an inbox — a client can see what stage a request is at, what's been done and what's still open, without writing an email and waiting a day for a reply. It's the same operating stance we bring to ongoing maintenance after launch: visibility isn't a nice-to-have added on top of the build, it's the thing that makes the rest of the relationship trustworthy.
The three questions worth asking, and what a bad answer sounds like
You don't need a long list here — three questions cover most of what actually goes wrong on a project:
- "How will I see progress before the site is done?" A bad answer is vague reassurance ("I'll keep you posted"). A good one names something concrete — a status page, a weekly build link, a recurring call on the calendar.
- "What happens if something outside the original scope comes up?" A bad answer is "we'll sort it out." A good one describes a real process — the extra work gets scoped and quoted before it happens, not folded silently into a bigger invoice at the end.
- "Who's actually doing the build?" A bad answer dodges or gets vague about the team. A good one is straightforward about whether it's the person you're talking to, a named colleague, or a subcontractor — any of those can be fine, but you should know which one you're getting.
None of these questions are confrontational, and a developer worth hiring won't treat them that way. If you want the other half of this — what a developer needs from you, not what to ask them — our guide on briefing a developer covers that side. Our services page has the full range of what we build, and if you'd rather just ask us these questions directly, get in touch.
Frequently asked questions
What's the single most useful question to ask before hiring a web developer?
Ask how you'll see progress between the kickoff call and the delivery date. The answer tells you more about how the project will actually feel than a portfolio does — a vague answer ("I'll keep you posted") usually means email chases and radio silence; a specific one ("you get a status page, or a weekly build") means someone has actually thought about the middle of the project, not just the start and the end.
Is it reasonable to ask for a written scope before a project starts?
Yes, and a developer who hesitates on it is telling you something. A written scope doesn't need to be a twenty-page document — a page listing what's included, what happens if something outside that scope comes up mid-build, and how that gets priced is enough to stop "can you also just add" requests from quietly turning into a disputed final invoice.
Should I ask who will actually be doing the work, not just who I'm talking to?
Yes. The person pitching a project and the person building it aren't always the same person, especially once work is subcontracted or handed to a junior team partway through. It's a reasonable, non-confrontational question, and a studio that's upfront about how the team is structured is a better sign than one that dodges it.
What should I ask about what happens after the site goes live?
Ask what breaks the relationship, not just what it includes. Every developer will describe support in glowing terms during a sales call — the useful question is what happens if a plugin update breaks the checkout six months from now: is that covered, billed separately, or is the developer simply unreachable by then. See our guide on website maintenance in Malaysia for what a real ongoing plan should cover.
Do I still need a detailed brief if I'm asking good questions during the pitch?
Yes — they solve different problems. Good questions during hiring tell you whether a developer will run the project well. A clear brief tells the developer what you actually need. Skipping the brief because the vendor conversation went well is a common way good hires still end up with the wrong website. See our guide on how to brief a developer for what to include.