Most advice on this reduces to a list of questions. Useful, but incomplete — because the answers matter less than whether they’re specific, and because the questions they ask you are often more revealing than anything on your list.
Here’s what’s actually worth asking, including the parts that feel awkward.
About the work itself
“What exactly is included, and what isn’t?”
The best answers volunteer the exclusions before you ask. Someone who’s run enough projects knows precisely where scope disagreements happen and heads them off. Vagueness here isn’t laziness — it’s a preview of how the conversation goes in month two when you want something that wasn’t discussed.
“Can I see work you’ve done recently?”
Recent matters more than plentiful. A portfolio of work from four years ago tells you what someone used to be able to do. Ask for something live you can actually open and click around in — a real site serving a real business beats a polished case-study image every time, because you can inspect it yourself.
“What do you need from me, and when?”
Projects stall on client-side content far more often than on developer capacity. Someone who can answer this crisply — content, photos, business details, in this order, by this point — has done this before. Someone who hasn’t thought about it will discover the bottleneck at the same time you do.
“How many rounds of changes are included?”
Not because you’ll use them all, but because the answer reveals how the scope is structured. “Unlimited” usually means the price already assumes a lot of them.
About what happens after
“Do I own the domain, the content, and the site?”
Ask about all three separately — they can be held by different people. What you actually own goes into why this matters more than it sounds like it does.
“What happens if something breaks?”
Get specifics: what counts as a defect versus a change, how long defects are covered, and what changes cost afterward. “We’ll take care of you” is warm and unenforceable.
“Can someone else work on this later?”
You’re asking whether the site is built on something standard or on a proprietary system only they can maintain. This is the difference between hiring someone and marrying them.
The uncomfortable ones
These feel rude. Ask them anyway — a professional won’t be offended, and the reaction itself is informative.
“Who is actually building this?”
At agencies, the person selling the project frequently isn’t the person doing the work. That’s not inherently bad, but you should know it, because what you saw in the pitch and what you get can drift. With a solo builder the answer is obvious, which is one of the genuine advantages of hiring one.
“What happens if you become unavailable partway through?”
A meaningful share of solo web projects stall out — the builder gets sick, overwhelmed, takes a bigger contract, or simply goes quiet. It’s common enough that it’s worth a direct question. Good answers are concrete: staged payments tied to progress, work you can retrieve mid-project, code stored somewhere you can access. “That won’t happen” is not an answer.
“What would make you turn this project down?”
Someone who says yes to everything either has no standards or no work. A designer who can describe the projects they’d decline is telling you they have a wheelhouse — and that they’d tell you if you fell outside it, rather than taking the money and improvising.
What their questions tell you
This one gets overlooked. Pay attention to what they ask you before quoting.
A designer who asks what the site is supposed to do — bring in leads, replace phone calls, look credible to a specific kind of customer — is going to build something aimed at that. One who only asks how many pages you want is going to build you however many pages you asked for, and whether it works is your problem.
Someone who asks about your customers, your competitors, and what happens after a visitor lands on the page is doing the actual job. Someone who leads with platform preferences is selling you what they already know how to make.
If a quote arrives without any questions being asked, you’re being sold a template.
Signals worth weighting
Response speed during the sales conversation. Not because urgency is a virtue, but because it’s the best available predictor. Slow pre-sale communication reliably becomes slow project communication.
A plain-English written agreement. Scope defined, ownership defined, timeline defined, what happens if things end. This protects both sides, and someone who resists putting it in writing is telling you something.
Willingness to say the unhelpful thing. A designer who tells you that you don’t need what you’re asking for — or that a site builder would serve you better right now — is demonstrating that their advice isn’t purely a function of what they’d get paid.
Where TruePoint sits
The person you talk to is the person who builds it. There’s no handoff and no account manager, which means there’s also no gap between what gets discussed and what gets made.
Pricing is published rather than quoted case by case, and scope is agreed in writing before anything starts, so “what’s included” is settled before money moves. Our work is live and inspectable — you can open the Appalachian Home Worx site and click through the real thing rather than looking at a screenshot of it.
Defects in the agreed scope are fixed free for 30 days after launch; changes are quoted per job, with no retainer. Sites are built on a standard foundation, so another developer could take one over.
And to the last signal above: if a project isn’t a fit — you need frequent self-editing, or you’re early enough that a site builder genuinely serves you better — we’ll say so. What a small business website actually costs includes the cases where hiring anyone is the wrong move.