A website or web app is one of the larger checks a small business writes. And most buyers cannot judge the actual work. You can see a nice homepage. You cannot see whether the code underneath is sound, fast, or something you will ever be able to change.
That gap is the whole problem. A developer can look sharp in a sales call and still hand you something slow, brittle, and tied to their accounts. Undoing that costs more than getting it right the first time. Rebuilds are expensive. Lost search rankings are worse.
So this is a practical checklist. Seven things to check before you sign, and the exact questions to ask a prospective vendor. None of it requires you to read code. It requires you to ask the right questions and pay attention to how they answer.
Do they write real code, or assemble a page builder?
The first fork is technical, but the consequence is not. Some shops hand-write your site in code. Others assemble it inside a page builder like Wix, Squarespace, or a pile of WordPress plugins. Both can look fine on launch day. They come apart at different speeds.
Page builders carry weight. They ship code your site never uses, and that shows up as slow pages. Slow pages lose customers and rank worse on Google. Code written for your site stays lean. Our own site at devarko.com scores 97 to 99 on performance and 100 on SEO in Lighthouse, and that is a fair standard to hold any custom build to. A heavy template rarely gets close.
One honest point: WordPress is not automatically the problem. A hand-built theme is a different animal from thirty plugins stacked on a template. The question is not the brand name. It is whether real engineering went in, or whether someone dragged blocks around a screen and called it a build. We go deeper on that trade-off in custom website vs template.
Questions to ask: Is this custom code or a page builder? If a builder, which one, and what happens if I want to leave it later? Can you show me a Lighthouse score from a site you actually built?
Who actually does the work?
The person in the sales meeting is often not the person who writes your code. That is normal. What matters is who sits on the other end. Some agencies win the job with a polished senior lead, then hand the build to junior subcontractors you never meet, sometimes in another time zone with no shared context.
Junior work is not the problem by itself. Everyone starts somewhere. The problem is junior work with no senior review. That is where you get code that runs today and breaks the moment traffic grows or the requirements change.
Ask directly: who will write my code, are they employees or subcontractors, and who reviews their work. A senior team changes what you get. Fewer surprises. Decisions made once and made right. That is worth paying for, and worth asking about before you sign.
Questions to ask: Who is on my project, by name and role? Will the people I meet be the people who build it? Is there senior review on every change, or does the code ship straight from whoever wrote it?
Do you own the code and the accounts at the end?
Lock-in is the quiet trap. You pay for a site, and at the end you discover you do not really control it. The code lives in the agency's private repository. The domain is registered under their account. Hosting, analytics, the CDN, all under their login. Leave them and you start over.
A fair arrangement is simple. You own the code. You own the domain, the hosting, and every third-party account. The developer either builds inside your accounts or transfers everything to you at handover, cleanly. At Devarko, clients keep full ownership of their code and there is no lock-in, and you should expect the same from anyone you hire.
Questions to ask: Who owns the code when we are done? Whose name are the domain and hosting under? If we part ways, what exactly do I walk away with, and how does that handover happen?
Do they treat performance and SEO as the foundation, not a bolt-on?
Speed and search visibility are decided while the site is being built, not after. If a developer plans to do SEO later, treat that as a warning. Later usually means bolting plugins onto a slow site and hoping something moves.
The foundation is boring, and it is what matters. Clean HTML. Images sized correctly. Little unused JavaScript. Pages rendered on the server where that helps. Correct titles, metadata, and structured data from the first commit. Get that right and the site is fast and legible to Google without heroics.
Ask to see proof. A real developer can show you a Lighthouse report from something they shipped. Numbers in the 90s on performance and 100 on SEO are achievable for a custom build, not a fantasy. If they cannot point to a single fast site they made, that tells you something.
Questions to ask: How do you handle performance during the build itself? Can I see Lighthouse or Core Web Vitals numbers from real projects? Is SEO structure part of the build, or a separate cost you bring up later?
How do they scope and price the work?
Get the scope in writing before any money changes hands. A serious proposal lists what is being built, page by page and feature by feature, with what is included and what is not. Vague scope is exactly where surprise costs live.
Be careful with a quote that sits far below everyone else. It usually means one of two things. Either they misread the work and will come back for more once you are committed, or they plan to move fast and cut the corners you cannot see. The cheapest quote and the most expensive quote both deserve a second look.
Fixed scope with a fixed price protects both sides. You know the number. They know the boundaries. Changes happen, that is normal, but they should arrive as clear, priced change requests, not quiet additions to the final bill.
Questions to ask: Is the scope written down in detail? Is the price fixed or an estimate? What counts as out of scope, and how are changes priced? What could make the final cost higher than the quote?
How will they communicate while building?
You will be living with these people for weeks, sometimes months. How they communicate matters nearly as much as how they code. The pattern you want is plain: regular demos of working software, on a predictable cadence, in language you understand.
Weekly is a good rhythm. Every week you should see the real thing running, not a status line that says seventy percent done. Working software is the only honest progress report there is. If a developer goes quiet for three weeks and resurfaces with excuses, you already know how the rest will go.
Watch how they explain things during the sales stage. A good developer can describe a technical trade-off in plain words. One who hides behind jargon either does not understand it or does not respect your time. Neither is what you are looking for.
Questions to ask: How often will I see working software, not just updates? What does a normal week on this project look like? Who is my point of contact, and how quickly do they reply?
What happens after launch?
Launch is the middle of the story, not the end. Software needs maintenance. Dependencies get security updates. Browsers shift. Something will break at some point, and you want to know who fixes it and on what terms well before that day arrives.
Ask about the handover too. You should receive the code, access to every account, and documentation a new developer could pick up without a phone call. If the only person who understands your site is the one who built it, you are locked in by knowledge instead of by contract, which is just as expensive.
Settle the support arrangement up front. Some businesses want a monthly retainer. Others want to own everything and hire help only when they need it. Both are fine. What is not fine is finding out after launch that support was never discussed and now costs whatever they decide.
Questions to ask: What does support look like after launch, and what does it cost? What exactly do I receive at handover? Is there documentation, and could another developer maintain this without you?