You Got 100 Proposals. How to Choose a Developer Without Reading Them All

You posted the project, and the proposals keep coming. Between late September and mid-October, the Upwork job posts we read collected anywhere from 50 to 290 applicants each. A SaaS client portal MVP got 265. A request to audit and improve an existing SaaS got 155, and one to check a system built with AI got 86.

Most founders deal with that pile the same way: open the first ten, feel worse, and pick whoever sounded most confident. That's how you end up paying for a rebuild a year later. Here's a slower method that takes less time overall.

Why the proposals all look the same

When a hundred people apply, most of them have read your post for a few seconds. They answer with a template: years of experience, a list of tools, "I can start today". The tool list is the least useful part. One client we read had already given up on it and wrote straight into the post that it wasn't for people who collect technologies in their profile.

You're not looking for the best writer of proposals. You're looking for the person who read your post properly and has built something like it before. Both are easy to check, if the post is written to let you check them.

Step 1: write a post that filters for you

The best filter is set before anyone applies.

• Describe the problem in business words. Who uses it, what they do today, what has to change, and the 3 to 5 things they must be able to do in version one. The one-page brief is enough. A clear brief draws developers who understand the business; a list of frameworks draws people who match keywords.
• Put in a budget range. Hiding it doesn't get you a lower price. It gets you a hundred quotes for a hundred different products.
• Ask one question only a reader can answer. "What would you build first, and what would you leave for later?" works for almost any project. Ask them to start the proposal with the answer.

That last line does most of the work. Anyone who opens with "Dear hiring manager" instead of answering has told you how carefully they'll read your messages later.

Step 2: the first pass

Now go through the pile with three questions, yes or no:

1. Did they answer your question, in their own words?
2. Have they built something similar, and can you see it: a live link, screenshots, a case with a named product?
3. Do they say anything about your project that isn't in your post? A risk, a question, a cheaper way.

Two "no" answers and the proposal goes. Don't read the rest of it. You're not being unfair. You're spending your attention where it has a chance to pay off.

What's left is usually short. Pick the five you'd be happiest to talk to.

Step 3: a short call with five people

Twenty minutes each is enough. Don't ask about tools. Ask about your product.

• "What would you cut from version one?" A good developer will cut something. Someone who agrees to everything will also agree to a deadline they can't meet.
• "How would you make your first change to code you've never seen?" If you already have a prototype or an old codebase, this one matters most. The right answer is reading it, running it and making a small, reversible change. The wrong answer starts with "I'd rewrite it".
• "What will I own at the end?" You want the code in a GitHub or GitLab repository registered to you, the hosting, the database and the Stripe account in your name, and a one-page note on how to deploy.
• "How will I see progress?" The answer you want is a working link every week that you can open on your phone. A status report doesn't count.

Listen for plain language. If they can't explain a problem without jargon, they'll explain your delays the same way.

Step 4: a small paid task for the last two

A conversation tells you how someone talks. A task tells you how they work.

Pick a slice of the real project that takes a day or less: one screen, one connection to Stripe or your CRM, or a written plan for the first 2 weeks. Pay for it at their normal rate. Free test tasks put off the good candidates first, because they have paying work. At $40 an hour, a task of 4 to 8 hours costs $160 to $320, which is small money against the price of hiring the wrong person.

Then look at three things. Did they ask questions before they started? Did they deliver when they said they would? Could you follow what they did without a developer standing next to you?

Red flags worth walking away over

• They quote a fixed price for the whole project before asking a single question.
• They want the domain, hosting or App Store account registered to their own email.
• They can't show anything they built, only describe it.
• The price is far below everyone else's, with the same scope. Somebody is going to pay the difference, and it's usually you, later.
• They push to move the conversation off the platform before any contract exists.

Freelancer or studio

Both can be the right call. A freelancer is usually cheaper per hour and you talk to the person writing the code. The risk is that the whole project depends on one person, which is how founders end up with a product nobody else can deploy. A studio costs more per hour than many freelancers, but if one developer drops out, someone else picks the work up.

Whichever you choose, compare the estimate, not the hourly rate. A developer at half the rate who needs twice the hours costs exactly the same, and you waited twice as long. Ask every finalist for an estimate in hours, broken down by feature, the way we priced a marketplace MVP line by line. If they can't break it down, they haven't thought it through yet. Our own estimate for an audit of existing code, for comparison, is 8 to 12 hours.

The short version

Write a post that asks one question. Drop everyone who didn't answer it. Call five, pay two for a small task, and hire the one whose work you understood without help.

If you'd like a second opinion before you decide, book a free 20-minute call with us. If a call doesn't suit you, send the brief through the form and we'll answer within one business day.