How to Choose a Web Developer for Your Small Business (Without Getting Locked In)

Most of the money I've seen small businesses waste on web development didn't go to bad design. It went to websites that looked fine but locked the owner out — hosted on the developer's account, built on a system only they could access, with no documentation and no exit plan. When the relationship went sideways, so did the website.

I run a digital marketing agency. I've inherited enough of these situations to know that the real mistake isn't hiring someone with a thin portfolio. It's hiring someone without asking the questions that don't appear on any quote page.

Here's how to avoid that outcome.

The ownership question most guides skip

Before you look at a single mockup, ask this: "Who holds the hosting account, the domain registration, and the CMS login — and what happens to access when the project ends?"

This is the most consequential question in the entire hiring process, and it's almost never raised until something goes wrong. When a developer owns your hosting account, you're not a client — you're a tenant. Every future change, every security update, every urgent fix at 11pm goes through them. If they raise their rates, get busy, or go quiet, your options are limited.

Your domain should be registered in your name on a registrar you control (GoDaddy, Namecheap, Google Domains — any of them). Your hosting account should be in your name with the developer added as an administrator during the project. Your CMS — whether that's WordPress, Webflow, or something else — should be set up so you can log in and make basic updates independently after launch.

Ask for this in writing before signing. A developer who pushes back on transfer of access is telling you something important about how they intend to keep you as a client.

Freelancer, agency, or template shop — which is actually right for you

None of the three is wrong by default. The right choice depends on scope, budget, and how much ongoing support you'll realistically need.

A freelance developer makes sense for a well-scoped site with a budget between $2,000 and $6,000 — service pages, a contact form, maybe a blog, nothing requiring custom integrations. The risk is capacity: a solo developer who takes on too much or goes quiet mid-project has no backup. Ask early how many active projects they're running.

A web development agency makes sense when the budget is $7,000 or above, the scope is complex (e-commerce, booking systems, custom functionality), or you need ongoing support baked into the relationship. You're paying for process accountability and redundancy — if the lead developer is unavailable, someone else picks it up. For small businesses building something they plan to grow, this predictability has real value.

A template-based service — someone building on Wix, Squarespace, or a pre-built WordPress theme — is legitimate for businesses in year one that need something professional online quickly for under $2,000. The limitation isn't the tool; it's that you'll hit a ceiling as your needs grow. Migration later often costs more than building on a scalable foundation the first time.

The hybrid tier — agencies that operate between freelancer pricing and full US agency rates, typically in the $500–$1,500/month range for ongoing retainer work — exists because most small businesses don't need a $20,000 custom build to have a site that actually converts. Sun BPO operates in this range specifically because the overhead of a US agency rarely translates to better results for an SMB with a standard marketing site.

Red flags that appear before a single line of code is written

You don't need to be technical to spot a developer who's going to cause problems. These signals show up in the pitch phase, well before any work begins.

They send a detailed proposal without a discovery call. If you email on Monday and receive a full quote by Tuesday morning, that quote was written before anyone understood your business. Real scoping takes a conversation: How many pages? What does the user journey look like? What existing systems need to connect? What's the post-launch maintenance plan? If those questions weren't asked, the proposal doesn't account for the answers.

The timeline is suspiciously fast. A complete small business website — properly designed, written, and tested across devices — takes four to eight weeks minimum. A developer quoting two weeks for a full build is either planning to use a template they won't tell you about, or skipping testing. Either way, ask specifically what the timeline includes.

They can't explain what CMS you'll be on and why. WordPress, Webflow, Shopify, and custom builds each have real use cases. A developer who recommends whatever they're most comfortable with, without explaining the tradeoffs for your specific situation, is optimizing for their workflow. Ask why that platform and not an alternative — the quality of the answer tells you a lot.

The contract doesn't address IP ownership. Your scope-of-work document should state clearly that the code, design assets, and content created for your project belong to you. If the contract is vague on this, the default often favors the developer. Don't assume — ask for it explicitly.

Questions to ask before you sign anything

Use these in your first meeting or over email. The answers matter, but how they respond matters more. A developer who gets defensive or vague on basic pre-project questions is showing you exactly how the project will go.

"Can I contact two or three recent clients directly?" Portfolio pages show what the developer wants you to see. Reference calls show you what working with them is actually like — timelines kept, communication quality, what happened when something went wrong.

"Who will own the hosting account and domain, and how does access transfer at the end of the project?" Already covered — but get the answer explicitly and in writing, not just verbally.

"What CMS will you build on, and will I be able to make basic edits myself without hiring you?" After launch, you should be able to update a blog post, change hours, or swap a photo without sending an email. If the answer is no, ask why the system doesn't support that — and whether a different platform would.

"What does the maintenance arrangement look like after go-live, and what's included vs. billed separately?" A website isn't a product you buy once. Plugins update. Security patches need applying. Hosting environments change. Get clarity on the post-launch model before you commit, not after.

"How many rounds of revisions are included, and how do you handle scope changes?" Revision scope creep is one of the most common sources of conflict on web projects. Define it upfront, in writing, and you'll avoid most of the arguments that happen three weeks in.

The bottom line: the developer who is clear, direct, and thorough before the project starts is almost always the same way during it. The one who is vague, evasive, or rushed in the pitch phase rarely improves once you've signed.