Client Won't Agree to Pay Upfront? Do This Instead

The client emailed back in an hour. Everything looked good, until the deposit line. "We don't pay upfront. Ever." Now you're deciding whether to walk away from the project or start it with zero protection.

TL;DR: When a client won't agree to pay upfront, you don't have to choose between losing the deal and building for free. Ship code that only runs once the invoice clears, and the deposit argument stops mattering — the leverage moves from before delivery, where it's just a request, to after it, where it's enforceable. Keep your contract. Disclose the terms. Start the work.

Why clients refuse to pay upfront

This isn't usually about you. Most clients who won't pay a deposit have been burned before, by a freelancer who took the money and vanished, or by a bigger studio's contract that made deposits feel like a trap. Some have a finance department with a policy against pre-paying anyone who isn't already a vendor of record. Some are just testing whether you'll cave, because caving is common enough that it's become a habit on both sides of the table.

Treat it as a trust problem, not a red flag. A client refusing a deposit is not the same signal as a client refusing to pay at all — those get confused constantly, and the confusion costs freelancers real work. If you walk away from every client who won't pre-pay, you walk away from a meaningful share of legitimate ones.

That said, the risk you're worried about is real. Once you deliver working code with no payment condition attached to it, you've handed over the one thing you had to negotiate with. What you do about that risk matters more than how you feel about the objection.

What actually reduces the risk before you build

There are real, useful moves here even if you never touch a tool for any of this. They won't fully solve the problem — that's coming — but they're worth doing regardless.

Shrink the first deliverable. Instead of asking for 50% of a six-week project, propose a small, clearly scoped first phase — a working prototype, a single page, an API endpoint — priced and delivered on its own. It's a smaller ask, it's faster to invoice, and it gives you a real signal about whether this client pays on time before you're six weeks deep.

Put payment terms in writing before day one, not after a dispute starts. A contract that states net-7 or net-14 from delivery, with a specific late fee, changes the default from "pay whenever" to "pay by this date, or this happens." Courts and collections agencies both weigh a signed term far more than a verbal understanding.

Ask for a reference or a public footprint. A registered business with a website, past reviews, or a LinkedIn history you can check is a different risk profile than an email address that showed up yesterday. This takes ten minutes and screens out a meaningful share of the worst cases before you write a line of code.

None of this removes the core exposure. Even with a smaller first phase, a solid contract, and a client who checks out fine on paper, the moment you deliver, you're holding an invoice and they're holding a working product. That imbalance is the actual thing the deposit was trying to fix, and a smaller deposit only shrinks it — it doesn't close it.

The real reason the upfront fight keeps happening

Here's the part that doesn't get said out loud: the deposit conversation exists because delivery is irreversible. Once you hand over working code, you have no mechanism to take it back, and both sides know it. The deposit is just insurance against that one-way door. Fight to get the deposit, and you're really fighting for insurance against a structural gap in how software gets delivered.

That's why the fight keeps happening on every project, with every client, regardless of how good your negotiating is. You can win the argument this time and lose it again with the next client who has a no-deposit policy. The fix isn't a better argument. It's removing the reason the argument exists.

What if a client won't agree to pay upfront?

If the code you deliver only runs while the invoice is current, you don't need the deposit conversation at all. This is what DevAegis does, in four steps:

• Build normally. No change to how you write code or structure the project.
• Run the DevAegis CLI before delivery. It encrypts the compiled build with AES-256-GCM — the key stays with you.
• Client deploys as usual. A small runtime checks in with the DevAegis API and, in good standing, decrypts in memory so the app boots normally.
• Miss payment, flip one toggle. The runtime stops decrypting and the site stops booting. Mark it paid, and access restores automatically.

This changes the upfront negotiation completely. You're not asking the client to trust you with money before they've seen anything. You're not betting the whole project on their word. You start the work with zero deposit, because the leverage that used to require a deposit now lives in the delivery itself, and it survives handover — which no deposit, however large, actually does once the work is done and the invoice slips.

There's a contractual piece here that matters more than the technical one: this needs to be disclosed. You're not hiding a kill switch in the codebase — you're licensing software, and the license is conditional on payment, the same way Adobe, Salesforce, and every SaaS company already works. State it plainly in the agreement before you start. It's a standard term once it's written down, not a secret trapdoor.

Set it up once, and it applies to every project you deliver from then on, not just this one client. Plans and what's included are listed on the pricing page.

When escrow is the better call

DevAegis isn't the only way to handle payment risk, and it's worth being honest about where a service like Escrow.com fits better. Escrow holds the client's money with a neutral third party and releases it to you as milestones complete — the buyer fully funds the transaction before any work starts, and both sides agree the terms upfront.

That's a real advantage in one specific case: a client who's willing to pre-fund but wants a trusted intermediary instead of paying you directly — often for a first-time relationship or a larger contract where a neutral holder reassures both sides. If your client will fund an escrow account, use it. It's a solid, well-established option for exactly that situation.

It doesn't help with the client in this post. Escrow only works if the client agrees to lock up money before you start — the same upfront commitment they're already refusing. If they won't pay a deposit to you, they generally won't fund an escrow account either. That's the gap DevAegis is built for: it needs no upfront commitment and no client cooperation beyond agreeing to the license terms already in your contract.

The same negotiation, two ways it can go

This is one illustrative sequence, not a specific client or case study. It's the shape this plays out in on a fixed-price build with no deposit, from the first "no" to the invoice going quiet or getting paid. The table below runs it both ways side by side.

What to do next

Pick your next project with no deposit and write the payment-conditional license into the contract before you send the SOW — one sentence, disclosed upfront, is enough. Then set up delivery through DevAegis before you ship the first build, not after the first invoice goes quiet. If you're already chasing a payment on a project you delivered unprotected, start here instead — that one's about the invoice you already have out.

FAQ

What if a client refuses to pay any deposit at all? Don't treat it as a dealbreaker on its own — plenty of legitimate clients have a no-prepayment policy. Shrink the first deliverable, put firm payment terms in the contract, and deliver code that only runs while the invoice is current. That removes the need for a deposit instead of trying to force one.

Is refusing an upfront payment a red flag? Not by itself. It's common among clients with finance departments, past bad experiences with freelancers, or a general policy against pre-paying new vendors. Combine it with other signals — no verifiable business presence, pressure to skip a contract, vague scope — before treating it as a warning sign.

Can I use escrow if the client won't pre-fund it? No. Services like Escrow.com require the buyer to fully fund the milestone before work begins, which is the same commitment the client is already declining. Escrow solves a different problem: it's for clients willing to pay upfront but who want a neutral third party holding the money.

Is a payment-conditional kill switch legal to use? It's a standard licensing term as long as it's disclosed in the agreement before delivery — the same conditional-access model every subscription software company uses. DevAegis doesn't provide legal advice; put the term in your contract in plain language and, for anything unusual about your jurisdiction or client type, have a lawyer review the clause.

Does this work if the client hosts the app on their own server? Yes. The client deploys and runs the build on their own infrastructure exactly as they would any other delivered code. The DevAegis runtime checks in with the DevAegis API to confirm payment status before it decrypts and boots the app, regardless of where it's hosted.