Most people hire a web developer the way they hire a roofer they found in a panic: they get a couple of quotes, pick a number that doesn't hurt too much, and hope. Then a year later they're paying a monthly bill they don't understand for a site they can't edit, built on a platform they don't control, by someone who stopped answering email.
That outcome is avoidable, and it's almost always avoidable at the questions stage — before any money changes hands. I'm Matt Ebersole, a web developer in Greer, South Carolina, working across Greenville, Spartanburg, and the Upstate. Below are the questions I'd want a business owner to ask me. I'm putting them in writing because the developers who'd struggle to answer them are exactly the ones you want to screen out, and that's true whether or not you ever hire me.
1. "When this is done, who owns it?"
This is the question that decides everything else, so ask it first and listen carefully to the dodge.
There's a real difference between paying someone to build you something you own and renting access to something they keep control of. A lot of web work today is quietly the second one — your site lives on a platform, your data sits in their database, and the day you stop paying, it all goes dark. You never owned anything. You were leasing.
When I finish a build, you own it outright — the code, the data, the whole system. Landmark Baptist runs a site they fully own, hosted on infrastructure they control, at $0 a month. Upstate Structural Repair owns their entire inventory system the same way. No subscription to me. No platform that can hold the work hostage.
If a developer can't give you a clean, plain answer to "who owns it," assume the answer is "not you."
2. "What happens if I want to leave you later?"
The honest version of the ownership question. Every relationship ends eventually — you sell the business, you hire someone in-house, you just want a change. A good build assumes that day will come and makes it painless.
I built USR's system specifically because their last situation went the other way. Their previous developer left them locked out of their own data — a real operations crisis they didn't choose. So when I rebuilt it, I built it to outlive me: it runs on hardware they already owned, with no dependency on my staying in the picture. If they never call me again, it keeps working.
Ask the developer to describe your exit. If the exit is ugly or vague, the relationship is a trap with a nice front-end.
3. "What will I be paying every month, and for what?"
Not "what does it cost to build" — what does it cost to keep. The build price is the part everyone shows you. The recurring bill is the part that quietly defines what you actually pay over five years.
Run the math out loud. A $200-a-month tool is $12,000 over five years — and at the end of those five years, you own nothing. That's not automatically a bad deal; sometimes renting genuinely is the right call. But you should be the one deciding that with the real number in front of you, not discovering it on year three.
A developer who can't itemize your monthly cost — hosting, licenses, "platform fees," their own retainer — either hasn't thought it through or doesn't want you doing the multiplication.
4. "What's your rate, and does it change depending on who's asking?"
Pricing tells you about character before the work ever starts. Ask the rate directly and watch whether you get a number or a sales process.
Mine is public and flat: $300 an hour, one rate, no tiers, no negotiation. Half up front, payment before work, and you own everything when it's done. I keep it transparent for the same reason I tell clients to own their systems — a builder who's selling you control shouldn't be hiding his own numbers. If a quote shifts around based on how much you seem to have, that's not a price, that's a read on your wallet.
5. "Have you ever actually run a business, or only built websites for them?"
This one matters more than the portfolio screenshots. Plenty of developers can make something look finished. Far fewer have stood in the spot you're standing in.
I spent 14 years at a single Upstate company, climbing from Bench Technician to Operations Director. That company ran a 100,000-square-foot warehouse and managed over 900,000 devices across its life, with a crew of 35 to 50 people. I've watched a system go down with people waiting on it. I've inherited processes nobody designed and had to figure out why they existed before touching them.
That background is why I'll sometimes tell you not to build. The most common mistake I see is a business paying to automate a process that should've just been fixed first. A developer who's only ever built websites will build you exactly what you asked for. An operator who can build will ask whether what you asked for is the thing you actually need.
6. "Can you show me real numbers from a real project — not just a pretty picture?"
Anyone can show you a screenshot. Ask what the work actually did.
When I rebuilt USR's inventory system, the real outcome wasn't "a nicer screen." It was 3 enforced access roles so field techs see zero pricing, across 137 line items and 8 trucks, running on Zebra and WASP scanners they already owned, demoed in 48 hours, live in about three weeks, at $0 a month and fully theirs. Landmark Baptist's site carries 14 pages, 12 sermon recordings, and 61 prayer entries, also at $0 a month.
Numbers like that are checkable and specific. "We delivered an amazing modern experience" is neither. Ask for the first kind.
7. "Will you tell me if I don't need you?"
The last question, and the one that reveals the most. A builder you can trust with a $5,000 project is one who'll talk you out of a $5,000 project when it's wrong.
I turn down work when the honest answer is a process change and a tool you already own. I'd rather keep a relationship straight than sell a build nobody needed — and I'll tell you that to your face during the first conversation, for free. If a developer can't imagine a scenario where they'd tell you no, you're not hiring a craftsman. You're hiring a salesman.
How to use this list
You don't need to ask all seven like an interrogation. Ask the first one — who owns it — and the rest of the conversation will usually tell you everything. The people who build things you own answer plainly. The people who build things you rent get evasive right about the time you ask what happens when you leave.
If you've got a project in the Upstate and you want straight answers to every one of these, that's the conversation I have at MattCreates. Bring the questions. You'll get a real number, a real owner-from-day-one plan, and an honest "you don't need this" if that's the truth.
Truth before tools. Order before growth. People before platforms.
→ Start the conversation at MattCreates.com.
Matt Ebersole is an operations specialist and web developer in Greer, South Carolina, serving Greenville, Spartanburg, and the Upstate. He spent 14 years in operations — Bench Technician to Operations Director — before building custom systems clients own outright. Flat $300/hr, no subscriptions.