Most people start vetting a web development company by asking for a quote. That is backwards. A quote without a scoped requirement is just a guess in both directions, and it tells you almost nothing about whether the company will actually deliver. Here is the checklist we would want a client to run on us, and on anyone else, before signing anything.
Ask Who Owns the Code and the Domain
This is the single most common source of regret after launch. Confirm, in writing, that you receive full ownership of the source code, the domain registration, and any third-party accounts (hosting, analytics, payment gateway) set up on your behalf. Agencies that quietly retain control, by keeping the domain in their own account or withholding the repository, can hold a business hostage later for "maintenance" fees. A company confident in its work hands over the keys without hesitation.
Get the Pricing Structure Clear Before Scope, Not After
"Get a free quote" is the wrong first step if nobody has scoped the actual requirement yet. A number produced before scoping is not a quote, it is a guess that will move once real requirements surface. Ask instead: fixed-price or hourly, what happens when requirements change mid-project, and what is explicitly out of scope. A company that can answer this clearly, before you have even described your full requirement, is one that has done this enough times to know where the costs actually live.
Check Their Portfolio for Live, Working Links
A portfolio slide with screenshots proves nothing. Ask for live links to sites they built, ideally ones still running in production, and actually click around. Look for: does the site still work, is it reasonably fast, does it look like a custom build or a templated one. If a company is reluctant to share live links to past work, that reluctance is itself the answer.
Confirm What Happens After Launch
Launch day is not the finish line, it is the start of the part where bugs surface under real traffic. Ask explicitly: how long is the post-launch support window, what counts as a "bug" versus a billable change request, and who do you contact when something breaks at 11pm. Get this in writing before the project starts, not after something goes wrong.
Red Flags Worth Walking Away From
- No milestone structure. A project with no defined checkpoints before final delivery gives you no chance to course-correct early.
- Vague answers about technology choices. If nobody can explain why they are using a particular stack for your specific case, the choice was probably made for their convenience, not your requirement.
- Pressure to sign before scoping is finished. A rushed contract usually means a rushed, under-scoped project.
What We Do Differently
We scope the actual requirement before quoting, hand over full code and domain ownership on every project, and agree on a concrete post-launch support window in writing. If you are comparing us against other options, ask us the same questions above, we would rather earn the project on a clear answer than a vague one. Get in touch or see how we approach builds on the web development page.