FN-02Field note

Hiring a freelance frontend developer in Chicago: rates, red flags, and what to ask

This is the guide I'd hand a friend who runs a business: what the job actually is, how the money works, and the short list of questions that sorts pros from problems before any contract gets signed.

· 8 min read

What you're actually hiring

Say you run a business in Chicago and the website needs real work: a rebuild, a set of Figma files somebody handed you, a store that loads too slowly. You've decided to hire a frontend developer instead of an agency. Good instinct, usually. Now you have to pick one, and most of the advice online is written by people selling courses.

One disclosure before anything else. I'm a freelance frontend developer in the Chicago suburbs, and I want this kind of work. That's exactly why this checklist is safe to use: every test in it is one I'm happy to be measured against, including by you, on me.

Start with the job itself, because the titles blur together. A frontend developer builds the part of a site people actually touch: the HTML, CSS, and JavaScript, the speed it loads at, whether it works on a phone, whether someone using a screen reader can get through it. A designer decides how the site should look and behave, usually in Figma. Some of us do both; many don't. An agency wraps design, development, project management, and a sales layer into one invoice, and you pay for all of it whether your project needs all of it or not. A freelancer is one person with a direct line and much less overhead. The trade is that you have to confirm the one person covers what your project needs. If you already have finished designs, a frontend developer is exactly the right hire. If all you have is a logo, ask whether they design too, or can bring in someone who does.

How pricing works, and what actually drives cost

Three models cover nearly every freelance arrangement, and the difference that matters most is who carries the risk when the work takes longer than anyone thought.

The three pricing models · who carries the risk, and where each one fits

  • Hourly

    You pay forTime

    Risk sits withYouThe meter has no natural end.

    Maintenance and genuinely unclear work. The wrong model for "build me a website."

  • Fixed scope

    You pay forA written scope

    Risk sits withThe developerOnce the scope is agreed.

    Project work. Both sides are forced to think before anything gets built.

  • Retainer

    You pay forA set monthly commitment

    Risk sits withSplitBy the month, on both sides.

    A site that needs continuous care and small improvements. Wrong for a one-time build.

Assessment: my own, from twenty years of quoting all three

Fixed scope is what I use for project work: a free scoping call, then a written fixed quote before any work starts. If the scope changes mid-project, the quote changes in writing too. That's a feature, not friction.

I don't publish prices, and I'd be careful with anyone who does, because the honest answer to "what does a website cost" is "what does it need to do." The things that move a quote up or down are boring and concrete: how many genuinely distinct page layouts you need, whether your team has to edit content themselves (that means a CMS), how much animation and interactivity is involved, which third-party systems it talks to (payments, bookings, email), whether the content already exists or someone has to chase it, and how strict your performance and accessibility targets are. That gives you a useful test: anyone who names a firm price on the first phone call, before hearing any of that, is guessing. You'll pay for the guess later.

Red flags

None of these are quirks. Each one predicts a specific way the project goes wrong.

  • No written scope. If the deliverables live in a phone call, every disagreement later becomes your word against theirs, and you're the one who already paid.
  • No staging URL. You should watch the site take shape at a real link, on your own phone, not in screenshots someone curated. I put every project on a staging URL and demo it weekly. There's no good reason not to.
  • Vague ownership. Ask who owns the code, the domain, the hosting account, and the analytics before work starts. If a developer registers your domain under their own account, leaving them later gets expensive. The right answer is that everything sits in accounts you own, from day one.
  • "Trust me" estimates. A real estimate comes with its assumptions written down. If the answer to "what happens if this takes longer" is a shrug, the shrug is your contract.
  • A portfolio with no live links. A screenshot can't be slow, can't break on mobile, and can't reveal that somebody else built it. Live URLs can be checked. Mine are on the projects page for exactly this reason.
  • No questions. A developer who doesn't interrogate your project during the sales conversation won't do it during the build either. The right person asks about your customers, your deadline, and your content long before they mention a framework.

Questions worth asking

I've sat on the hiring side of this table too. As a web lead at Universe I've run hiring pipelines and technical interviews, and screening freelancers works the same way screening candidates does: a few plain questions expose more than any resume.

  • "Who owns the repo and the accounts?" You want to hear "you do, from the start." Not "we'll sort that out at handoff."
  • "What happens after launch?" Sites break in week two, not week one, and content questions show up once real people start using the thing. I build 30 days of post-launch support into every project. Whatever your developer offers, get the after-launch story in writing.
  • "How do you test?" The good answer involves real devices, more than one browser, accessibility checks, and performance measured in numbers rather than vibes. If they bring up Core Web Vitals unprompted, that's a strong sign. I wrote a plain-English guide to those metrics if you want to know what to listen for.
  • "Can I see something you shipped, live?" Then actually open it on your phone. Slow is slow no matter how nice the case study reads.
  • "What do you need from me, and when?" Projects slip on the client side as often as the developer side: missing content, missing logins, slow decisions. A pro can tell you exactly what they'll need from you and when.
  • "Who can I talk to?" Ask for references you can actually contact. My version of that answer is public: 36 recommendations on LinkedIn from people I've built things with.

Does local still matter?

Sometimes, genuinely. I work from Buffalo Grove, in the northwest suburbs of Chicago, and some of the most productive hours in any project happen across a real table: the scoping conversation, a homepage walkthrough with the people who'll own it, an afternoon sitting next to the person who'll actually edit the CMS. Same timezone, no scheduling gymnastics, and if something goes sideways the week of your launch, a person can show up. That's the practical case for hiring a freelance frontend developer in Chicago or the suburbs instead of a name on a marketplace.

Plenty of projects need none of that. A weekly demo at a staging URL works from anywhere, and I've been freelancing since 1999, long enough to have shipped plenty of work for people I've never shared a room with. My honest rule: pick local when you want working sessions and someone whose reputation lives in your community, and pick purely on skill when the project is well-defined and remote-friendly. What you shouldn't do is pay a local premium for someone you'll only ever see on video calls anyway.

The whole checklist, on one screen

Everything above, compressed to the things you can actually verify. The left column is what you confirm before signing anything. The right column is what you say out loud on the call.

The hiring checklist · ten things, one screen

Confirm before you sign

  • The scope is in writing, and so are its assumptions.
  • There is a staging URL you can open yourself.
  • You own the code, the domain, the hosting, and the analytics from day one.
  • Their portfolio has live links, not screenshots.
  • They asked about your customers, your deadline, and your content.

Ask on the call

  • "Who owns the code and the accounts?"
  • "What happens after launch?"
  • "How do you test?"
  • "Can I see something you shipped, live?"
  • "What do you need from me, and when?"

Every item is one I am happy to be measured against, including by you

Use this list on me

Back to the disclosure from the top. I'm a freelancer writing a guide about hiring freelancers, so of course I want the work. That's the point of publishing the checklist: every question above has an answer I've already put in writing. My process is on the services page: a free scoping call, a written fixed quote before work starts, four steps (Survey, Chart, Build, Verify), weekly demos on a staging URL, and 30 days of support after launch.

30 days of support after launch, built into every project My standard terms
Weekly demos on a staging URL you can open on your own phone My standard terms
36 recommendations from people I've built things with LinkedIn

If you're comparing developers right now, run this list on all of us, me included. And if you'd rather start with the free call, the contact page is the shortest path.