A freelance developer told me he sent a $14,000 proposal for a Next.js rebuild, got a "this looks great, let me loop in my CTO" reply, and then heard nothing for three weeks. He assumed they'd gone with someone cheaper. They hadn't. The CTO had been on parental leave, the proposal sat unread in a Slack thread, and a single follow-up email at the right moment would have pulled it back to the top of the pile.
So here's the direct answer: as a web developer, you should follow up on a proposal 2-3 business days after sending it, then again around day 7, day 12, and day 18 — four to five touches total, each one shorter and more specific than the last. The reason most devs lose these deals isn't price or skill. It's that they send one limp "just checking in" and quit.
Let me walk through exactly what to send and when, with scripts you can paste today.
Why developers lose proposals they should win
Dev work has a follow-up problem that designers and consultants don't quite have. Your proposals usually go to a technical buyer or get forwarded to one. That means your quote sits in a longer approval chain — a founder loops in a CTO, a marketing manager loops in IT, a startup waits on a budget call. Every handoff is a place your proposal goes quiet.
And the numbers say persistence wins. Research from Brevet found that 80% of sales require five follow-up calls after the initial contact, while 44% of salespeople give up after just one. Iko System's outreach data showed the first follow-up email can lift reply rates noticeably over the initial send — the second touch in one of their campaigns got an 18% response rate versus 30% on a later one, proving the later emails in a sequence aren't wasted. Translation: the deal you wrote off after one email was probably still alive.
The thing is, developers tend to treat follow-up like it's beneath them. You're an engineer, not a salesperson. But every quiet proposal is real money — and at $80-$200 an hour, a single lost project can be a month's income.
The timing framework that works for dev proposals
Here's the cadence I'd run for a typical web development proposal. Adjust the gaps slightly for bigger contracts (technical buyers move slower), but keep the structure.
Day 0 — Send the proposal. Send it Tuesday through Thursday, mid-morning their time. Avoid Friday afternoons, when nothing gets approved.
Day 2-3 — Confirmation nudge. Short. You're confirming they got it and offering to walk through anything technical.
Day 7 — Value-add touch. Don't just "check in." Add something — a note about a security or performance consideration, a relevant case study, a clarification on scope.
Day 12 — The direct ask. Ask a real question that needs a yes or no.
Day 18 — The breakup email. The "I'll assume the timing isn't right" email. This one gets replies precisely because it removes the pressure.
That's a roughly three-week window. After that, move them to a long-term re-engagement list rather than emailing weekly. For a deeper breakdown of the spacing, our guide on how many follow-ups you should send after a proposal covers the data behind these intervals.
The scripts (copy, paste, edit)
These assume you've already had a discovery call or exchanged enough detail to scope the work. Keep your real voice — but notice how short they are. No proposal recap, no apology for "bothering" them.
Day 2-3: Confirmation nudge
Subject: Quick question on the [Project] proposal
Hi [Name],
Wanted to make sure the proposal landed okay — sometimes PDFs get caught in spam. Happy to hop on a 15-minute call to walk through the technical approach or the timeline if that's easier than reading it cold.
Any questions on scope or the stack I picked?
[Your name]
Why it works: it gives them an easy on-ramp (a call) and signals you're thinking about their decision, not just waiting.
Day 7: Value-add touch
Subject: One thing I'd flag before we start [Project]
Hi [Name],
As I was reviewing the spec again, one thing stood out: your current setup will likely hit a performance wall on the product pages once traffic scales. I built the proposal to handle that with [caching/SSR/whatever], so you won't have to re-platform in a year.
Happy to explain the trade-offs whenever you're ready to move forward.
[Your name]
This is the most important email in the sequence for developers. You're demonstrating expertise they can't get from a cheaper freelancer. You're not nagging — you're being useful.
Day 12: The direct ask
Subject: Should I hold your start date?
Hi [Name],
I'm scheduling projects for [month] and want to make sure I can fit [Project] in. Are you good to move forward, or is there something still up in the air I can help with?
[Your name]
Scarcity that's actually true. You do have a calendar. This forces a decision without being aggressive.
Day 18: The breakup email
Subject: Closing the loop on [Project]
Hi [Name],
I haven't heard back, so I'm guessing the timing isn't right or you've gone another direction — totally understand either way. I'll close out the proposal on my end.
If things change down the line, just reply here and we can pick it back up. Wishing you the best with the build.
[Your name]
Honestly, this is the one that surprises people. The breakup email regularly pulls the highest reply rate in the whole sequence because it triggers loss aversion — suddenly the option is going away. If you want more variations, we wrote a full post on the breakup email for clients who won't respond.
Developer-specific moves that close more deals
A few things that matter more for dev work than for other freelance niches.
Follow up to the technical decision-maker, not just the buyer. If a founder told you "I need to check with my CTO," offer to talk to the CTO directly. "Want me to send a short technical brief your CTO can review, or jump on a call with them?" You remove the friction of them having to relay your pitch secondhand.
Reference the cost of waiting. Dev projects often have a real deadline — a launch, a funding round, a Black Friday. A good day-12 line: "If you want this live before [their event], we'd need to start by [date] to leave room for QA." That's not pressure, that's project management.
Don't re-explain the whole proposal. Technical buyers hate fluff. Every follow-up should be three sentences or fewer. The longer your email, the more it reads like you're nervous about the price.
Track opens if you can. If you know they opened the proposal three times yesterday, that's a buying signal — call them. If they never opened it, your problem is deliverability, not interest, and you should resend. Our post on proposal tracking explains how to set that up.
A real example of the cadence working
One freelance dev I talked to runs a version of this on every proposal. He sent a $9,500 quote for an API integration, got silence, and ran the sequence. Days 2 and 7 — nothing. On day 12 he sent the "should I hold your start date?" email. The reply: "Sorry, buried in a launch. Yes, let's do it — can you start Monday?"
The client wasn't comparing him to competitors. They weren't negotiating. They'd just forgotten, the way busy people do. The only thing standing between him and $9,500 was a two-line email on the right day. He told me that single sequence has become the highest-ROI habit in his business.
That's the whole game. Most of the proposals you think you lost are sitting in an inbox, waiting for one more nudge.
Where automation fits
The catch with all of this is consistency. You will not remember to send a day-12 email to every prospect while you're shipping code for paying clients. You'll do it for the big proposals and forget the rest — and the rest is where the leaked revenue hides.
That's the exact problem I built ChaseNudge to solve. You add a proposal once, and it sends the follow-up sequence automatically on the cadence above, stopping the moment the client replies — so you stay top-of-mind without babysitting your inbox or sounding like a robot. It's the difference between "I follow up when I remember" and "I follow up every time."
For the complete system — timing, psychology, templates, and tools all in one place — read our complete guide to proposal follow-up for freelancers. And if email isn't landing, our breakdown of when to send a follow-up after a proposal will help you nail the timing.
FAQ
How long should I wait to follow up on a development proposal? Send your first follow-up 2-3 business days after the proposal, then space the rest around days 7, 12, and 18. Technical buyers sit in longer approval chains, so give them a little more room than you would a solo client — but don't go silent for two weeks.
What do I say in a follow-up email to a tech client? Keep it to three sentences or fewer and add something useful — a performance note, a security flag, or a real scheduling question. Avoid recapping the whole proposal; technical buyers read it once and don't want the fluff.
How many times should I follow up before giving up? Four to five touches over about three weeks. Most deals close on the third to fifth contact, and 44% of people quit after one — so the developer who keeps going past the first email wins projects the rest leave on the table.
Should I call or email to follow up on a dev proposal? Email for the routine nudges, but call when you see a buying signal (they opened the proposal multiple times) or when a founder needs to loop in a CTO. A live technical conversation closes complex builds faster than any email thread.
My client said they need to check with their CTO. What now? Offer to make that handoff easy — send a short technical brief the CTO can skim, or offer a 15-minute call with them directly. The longer your proposal depends on someone relaying it secondhand, the more likely it stalls.
The takeaway: pick one open proposal sitting in your "probably lost" pile right now, and send the day-12 "should I hold your start date?" email today. That single message has a better chance of landing you a project than the next hour you spend writing code for free.