What to Ask Before You Pay for a Custom Website

I build software for a living. Not the way a computer-science graduate does — I came to it from a career in corporate finance — but I ship production applications, so I know what goes into one and roughly what a custom website costs. Which is exactly why it's useful, every so often, to pose as an ordinary buyer and watch how the industry sells to people who don't know.

A little while ago a custom website company opened a chat with me. I asked three plain questions — the same three any sensible person asks before spending money.

The three questions to ask about custom website cost

How much does a basic custom site cost? Do I pay up front, or can I see it before I pay? And can I make changes later, or set up a maintenance agreement?

Reasonable. Specific. Answerable. Here's the short version of what came back.

What came back

First: "Are you a new or existing customer?" Then, before a single one of my questions was touched: "What is your business about?" Then: "Can we hop on a quick call right now?"

Notice what didn't happen. None of my three questions got an answer.

When I pushed — politely, but I repeated them — I got there eventually. On price: it "depends on pages and functionality," and since my idea had some complexity, it was "more of a custom web application than a basic website." Translation: no number. On payment: they "work with an upfront project start," though I could see a design direction "during the process," before full development was complete. Translation: pay first, see something later.

And when I said the obvious thing — that I don't like paying for something I can't see or use, and that as a buyer I need to compare before I commit — I got the line that explains the entire model:

The reason most custom development companies require a project-start payment is that the work begins immediately — planning, architecture, design, resources assigned to your project.

Why they do it — the fair version

Here's the thing: that's true, and I'm not going to pretend it's a scam. Custom work really does burn hours from day one, and a deposit protects a shop from a client who vanishes after booking a month of someone's time. If I ran a dev shop, I'd want some commitment too. The reasoning is sound.

But sound reasoning for them is not the same as a fair deal for you. Look at how the risk actually gets distributed.

Why that still leaves you exposed

The shop's exposure is covered before a single screen is designed. Yours is covered — never, really. You pay before you have any proof the product will be right. Once you've paid, you're anchored: switching means eating the loss and starting over, so you'll tolerate a worse outcome than you'd ever have chosen freely. And because you couldn't get even a ballpark, you can't compare offers or plan a budget. As I put it to the rep at the time:

The system is built to make sure you are taken care of first and me last.

That sentence is the whole article. It isn't dishonest, it isn't unusual — it's just structured entirely around the seller's risk, with yours as an afterthought. Most buyers never say it out loud, so they never notice they've agreed to it.

What to insist on before you pay a cent

None of this means "never hire a custom shop." Plenty are excellent. It means you buy with your eyes open and you hold the line on a few things before any money moves:

• A ballpark range, before any call. Anyone who has built a hundred of these can tell you "somewhere between X and Y, depending on Z." A flat refusal to estimate isn't discretion — it's a tell.
• A real mockup before you pay in full. Something you can look at and react to, tied to a small first payment — not the whole project on faith.
• Milestone payments, not one big upfront lump. Pay as deliverables land. It keeps both sides honest and caps your downside if it goes sideways.
• A portfolio of live sites you can click. Not screenshots, not "trust us" — URLs. If they can't show you working products, that's your answer.
• Ownership, in writing. You own the code, the domain, and the accounts. People skip this and find out later they're renting their own business.
• An exit. What happens if it isn't working — can you leave, and what do you take with you? Know it before you're in, not after.
• Changes and maintenance, defined. "We'll handle revisions" means nothing until you know how many, how fast, and at what price.

None of that requires you to be technical. It requires you to refuse to be rushed.

The question they couldn't answer

There was one more thing I asked, and it's the part that stuck with me. I told them what I wanted to build — an education idea I'd been kicking around — and asked a simple question: did anyone there help clients figure out whether the idea was actually any good? Was the model sound? Was there a market? How should it work to have a real shot?

They were glad to ask me a dozen questions about how the features should behave. They had nothing for the question of whether I should build it at all.

That gap isn't unique to them — it's true of nearly every shop like this, and it points at something that's quietly upended the whole industry. For twenty years, the ability to write code was the asset. It was scarce and hard, so if you had it, people paid you to build whatever they described — and that's exactly what these companies still optimize for and still sell. They'll build precisely what you tell them to.

But coding isn't the scarce asset it once was. The same stacks the big shops run on are available to all of us now, and for the first time we have a master coder on tap in AI. When building gets cheap, the scarce and valuable thing becomes knowing what to build and why — whether the model makes money, whether the market is real, whether the thing you're about to fund should exist at all. A shop that can only build will gladly take your money and build the wrong thing, flawlessly.

That's the difference between a developer and a partner, and it's the whole reason I evaluate the business before anyone writes a line of code. A perfect build of a bad idea is still a bad idea.

How I do it instead

I'll be straight about my bias: I structured my own work as close to the opposite of that chat as I could get. You see the number before you're committed to anything — a free conversation, then a written outline covering what can be improved, how I'd do it, how long it takes and what it costs, with the price fixed before the work starts. I wrote about the six ways consultants charge and what each one quietly rewards; the short version is that the structure decides how the work goes long before the number does.

The bottom line

You don't need technical skills to buy software well. You need to insist on proof before you're locked in — a number, a mockup, a portfolio you can click, and a way out. A vendor who's good at the work can hand you all four without flinching. The ones who can't are telling you something, and it's worth hearing before you've wired the deposit.

If you're weighing a build and want a read on whether the terms you're being offered are normal or a trap, that's a conversation worth having.