On this page7 sections
  1. 01Red Flags to Watch For
  2. 02Green Flags
  3. 03Questions to Ask Before Hiring
  4. 04Portfolio vs. Promises
  5. 05What to Expect From the Process
  6. 06Local Matters
  7. 07The Bottom Line

Hiring a web developer can feel like a gamble when two proposals use the word “website” for very different scopes. The useful comparison is not price alone; it is the work, responsibilities, ownership, process, and support attached to that price.

Here is what I recommend comparing before hiring someone—including me.

Red Flags to Watch For

No Portfolio (or a Portfolio of Templates)

Ask to see real work and to understand the developer’s role in it. A newer provider may have fewer client projects, and some work may be confidential, but they should still be able to demonstrate relevant design and development ability honestly.

Visit the live sites when possible, while remembering that a client can change a site after handoff. Check representative pages on your phone and ask the developer to explain the decisions, constraints, and results behind the work. A template is not automatically a problem; presenting template configuration as fully custom work is.

Vague Pricing

“It depends” is a reasonable first answer because page count alone does not define the work. After discovery, you should receive a written quote that explains the scope, assumptions, responsibilities, exclusions, payment schedule, and what can change the price.

I wrote a full breakdown of what small business websites actually cost if you want to know what’s reasonable before you start getting quotes.

Monthly Subscription Model

Some companies offer websites for a monthly subscription. That can be a reasonable model when the scope, support, and exit terms are clear. Ask what happens if you cancel, which assets and accounts remain yours, whether the site can be exported, and what work requires an additional fee. Compare those answers with a custom website and documented handoff before deciding.

No Timeline or Process

The developer should explain the phases, dependencies, review points, and what they need from you. A responsible schedule may include a range, but it should not leave progress or responsibilities undefined.

They Don’t Ask Questions

A provider who jumps straight to a visual style without understanding the business, customers, content, and desired actions is likely to miss the real job. The questions should fit the project rather than follow a scripted sales call.

Green Flags

They Show Real Work

Live websites, prototypes, and case studies can all provide useful evidence when the developer explains what they personally contributed. The strongest examples connect visual decisions with a customer or business need.

You can review my portfolio to see the client work and product systems behind these claims.

They Talk About Results, Not Just Design

A useful conversation covers how the website should support discovery, credibility, customer decisions, and measurement—not just colors and fonts. No provider can promise rankings or conversions, but they should explain how the structure and experience are meant to support those outcomes.

They Explain Things in Plain English

You should be able to understand the recommendation, trade-offs, and responsibilities without a computer science degree. Technical language is sometimes necessary, but the provider should translate it into practical consequences.

They Have a Clear Process

Good developers have a repeatable process: discovery, design, build, review, launch, support. They should be able to tell you exactly what happens at each step and what they need from you.

They Build for Speed and SEO

Ask how performance, accessibility, crawlability, metadata, analytics, and mobile behavior will be handled and verified. These are baseline considerations for a modern business site, although the exact work depends on the project.

Questions to Ask Before Hiring

These will save you headaches:

  1. “Can I see live sites you’ve built?” — Not mockups. Live, working URLs.
  2. “What do I own and receive when it’s done?” — Ask about code, design, content, domain, hosting, licenses, and handoff materials separately.
  3. “What’s included in the price?” — Design, development, content, SEO, forms, analytics, hosting setup?
  4. “What happens after launch?” — Is there a support period? What does maintenance cost?
  5. “How do you handle revisions?” — How many rounds of changes are included?
  6. “What platform or technology do you use?” — WordPress, Squarespace, custom code? Each has tradeoffs.
  7. “How will search foundations be handled?” — Listen for content relevance, crawlability, metadata, structured data where appropriate, sitemaps, performance, measurement, and an honest statement that rankings are not guaranteed.
  8. “What’s your timeline?” — The answer should reflect scope, content readiness, feedback time, and third-party dependencies rather than a one-size-fits-all promise.

Portfolio vs. Promises

Anyone can promise you an amazing website. The difference is in the work they can show you.

When evaluating a developer’s portfolio, look for:

  • Variety — Can they adapt to different industries and styles, or does everything look the same?
  • Performance — Run their sites through Google PageSpeed Insights. Treat the score as one diagnostic signal and ask the provider to explain the page, conditions, and trade-offs.
  • Mobile experience — Pull up their sites on your phone. Does it feel good to use?
  • Real content — Are the sites filled with lorem ipsum and stock photos, or do they have real business content?
  • Testimonials or references — Can they connect you with past clients?

What to Expect From the Process

A good web development project should look something like this:

  1. Discovery call — You talk about your business, goals, and what you need. The developer asks questions and takes notes.
  2. Proposal and quote — You receive a written scope of work with pricing, timeline, and what’s included.
  3. Design phase — The developer creates the visual design. You review and provide feedback.
  4. Development — The site gets built. You see progress along the way.
  5. Content and review — Final content goes in, you review everything, and request changes.
  6. Launch — The site goes live. DNS, hosting, analytics — all handled.
  7. Post-launch support — The agreement explains corrections, handoff, training, and any ongoing support option.

If any of these steps are missing from a developer’s process, ask why.

Local Matters

Some business owners prefer a nearby provider, while others care more about specialization, availability, or working style. A Long Island relationship can offer practical advantages when they matter to the project:

  • Local context can be easier to discuss. A Long Island provider may already understand common service areas, travel expectations, and regional business patterns—but you should still expect research.
  • Scheduling can be simpler. The same time zone and the option for an agreed local meeting may help, although remote communication can work equally well.
  • Local references may be easier to verify. You may be able to review nearby work or speak with a client serving a similar market.

That said, “local” doesn’t automatically mean “good.” Apply all the same criteria above regardless of where someone is based.

The Bottom Line

Hiring a web developer is an investment in your business. Take the time to evaluate your options, ask the right questions, and look at real work — not just promises.

If you want to see how I work and what I build, check out my portfolio. And if you’re ready to talk about your project, let’s have a conversation — no pressure, no hard sell. Just a straight answer on what your business needs and what it’ll cost.