We have been on both sides of this conversation. Founders come to us after a freelancer disappeared halfway through a build, after a site broke two weeks after launch and no one returned their calls, or after a quote that seemed reasonable turned into a series of unexpected invoices. The anxiety is real. We do not dismiss it — we work around it by making our process visible.
This guide is for the small-business or startup founder in the US, UK, or EU who needs to hire a developer and does not know exactly what to ask. It is a buyer's checklist. We have written it in plain English because the jargon is part of the problem. If a developer cannot explain their process clearly, they probably do not have one.
Why this feels risky
Most people asking for this guide have already been burned. A common pattern looks like this: you find someone through a marketplace or a referral. They quote a price that seems fair. They ask for half up front. Work starts slowly, then stops. Emails go unanswered. The site launches with broken links and missing images, and when you ask for the source files, you discover they were never backed up properly. You are left with a broken site, no way to make a simple text edit, and no documentation explaining how anything works.
We have cleaned up that exact situation. A client came to us with a marketing site built six months earlier by a contractor who had vanished. There was no Git repository, no staging site, and no handover notes. When a plugin update broke the contact form, nobody knew which version was safe to roll back to. The fix took us two days of detective work before we could even start repairing. That is the cost of hiring without vetting the process, not just the price.
Another pattern we see is the hidden-cost quote. A developer offers a low fixed price but excludes content migration, CMS training, performance testing, or post-launch fixes. Once the project is underway, every small addition becomes a new line item. By the end, the total is double the original quote. We avoid this by writing scope clearly and including a two-week warranty period in every engagement. You can see how we structure work on our services page.
What good vetting looks like
When you are comparing developers, you are comparing processes. Price matters, but it is not the first filter. Below are the criteria we recommend you check before signing anything.
Portfolio review process
A portfolio is not a gallery. It is evidence. We ask founders to look past the visual design and ask specific questions: Does this site load quickly? Can you navigate it without confusion? Is there a working contact form? Then ask the developer to explain their role — did they design it, build it, maintain it? If they only designed it, they are not the right hire for development.
We also recommend checking whether the sites in the portfolio are still live and functioning. A portfolio full of dead links tells you more about maintenance practices than design taste. You can review our completed builds on our work portfolio, where we include notes on the scope and timeline for each project.
Communication patterns
Good developers set expectations before problems arise. In our first conversation with a new client, we establish a response-time commitment: we reply within one business day, and we provide weekly progress updates during active development. We use a shared project board so you can see exactly what is in progress, what is blocked, and what is complete.
Ask any developer you are considering: How often will we meet? What tool will we use to track work? What happens if a milestone is missed? If the answer is vague — "We will figure it out as we go" — treat that as a red flag. We structure our timelines with clear milestones, and you can read more about how we handle transparency in our insights section.
Code review practices
You may not read code, but you can ask whether code is reviewed before it is deployed. We use a simple rule: no code goes to the live site without a second pair of eyes reviewing it. This catches errors, improves consistency, and reduces the risk of a broken launch. If a developer works entirely alone and deploys directly without review, that is a risk you are taking on.
You should also ask: Is the code in a Git repository? Can you access it? A Git repository is the version-controlled record of every change made to the site. Without it, fixing a bug is guesswork. With it, we can roll back to any previous version in minutes. We provide repository access to every client before launch.
Testing and QA
Every site we build goes through a structured QA process before launch. This includes testing across browsers, checking mobile responsiveness, verifying form submissions, and running performance audits. We also check accessibility basics: are headings structured correctly? Do images have alt text? Is the color contrast sufficient?
Ask your developer: What does your QA process include? Does it cover mobile devices? Does someone other than the builder test the site? If the answer is "I test it myself," that is not a process — that is hope.
Documentation and handover
We include a short handover document with every project. It covers how the CMS works, how to update content, where the source code lives, and how to reach us for support. We also include a brief guide to the hosting setup and any third-party integrations.
We have seen too many clients receive a finished site with no documentation and no CMS access. They could not change a phone number or update a headline without calling the original developer. That is not a handover — that is a trap. Before you sign, ask: Will I receive a handover document? Will I have admin access to the CMS? Will I own the source code?
Source code ownership
This is non-negotiable. Your contract should specify that you own the source code upon final payment. We include this by default. Without it, you are renting your own site.
We also recommend asking whether the code relies on proprietary frameworks or locked plugins that only the developer understands. The best code is readable by any qualified developer. If the code is written in an obscure framework with no community support, you are creating future dependency, not solving it.
Response-time expectations
We commit to responding within one business day and resolving critical issues — anything that breaks the site — within 48 hours during the warranty period. After the warranty period, we offer maintenance plans or hourly support. Either way, the timeline is clear.
Ask any developer you consider: What is your response time for urgent issues? What counts as urgent? Is there a warranty period? If the answer is "I will get back to you when I can," you have no plan for the moment something breaks.
Timeline transparency
We publish estimated timelines for each project type and update them as work progresses. We do not promise unrealistic deadlines. A marketing site takes four to eight weeks; a custom web app takes longer. We say no when a timeline is not possible, rather than committing to something we cannot deliver.
If a developer promises a complex site in two weeks with no discovery phase, no design rounds, and no QA window, ask what is being skipped. Usually it is everything that makes the site reliable.
Contract and payment terms
A good contract protects both sides. It should include:
- Scope definition: Exactly what is included — pages, features, integrations, content migration, CMS training.
- Milestone structure: Payment split by milestone, not calendar month. We use a 40/30/20/10 split.
- Change process: How new requests are handled — in writing, with a revised quote.
- Source code ownership: Explicit statement that you own the code upon final payment.
- Warranty period: What is covered after launch and for how long. We include two weeks.
- Termination clause: What happens if either side needs to exit the agreement.
We review contracts openly with clients. If a developer resists putting terms in writing, that is a signal. The contract is not bureaucracy — it is the plan you both agree to follow.
A practical checklist
Before you hire a developer, confirm these items:
- Does the developer show you a working staging site before launch?
- Is the code in a Git repository you can access?
- Does the contract specify source code ownership?
- Is there a written milestone and payment structure?
- Does the quote include CMS training and a handover document?
- Is there a QA process that includes mobile and accessibility checks?
- Is there a warranty period after launch?
- Does the developer set clear response-time expectations?
- Can the developer explain their process without relying on jargon?
If you can answer yes to all of these, you are working with a professional. If several are missing, you are taking on risk that will likely cost more than the initial quote saved.
We meet these criteria because we have been the cleanup crew for projects that did not. We believe a trustworthy developer does not need to compare themselves to competitors by name — the process speaks for itself. If you want to see how we apply this in practice, explore our work portfolio or reach out through our contact page.