Last month a client asked me — genuinely, not rudely — why a project quote was so high. "You're just writing code, right?"

It's a fair question if you've never been inside a software company. From the outside, the work looks like a person at a laptop, typing. And typing looks free.

It isn't.

The mental model that's wrong

The "you're just typing" model treats software development like data entry. You have requirements; I put them in. Charge per keystroke. Done.

That model would make software cheap. It would also make it terrible.

Writing code is the visible tip of the work. Before a single line is written, a developer has to understand your problem, understand the constraints of the system you already have, decide which approach won't turn into a maintenance disaster in 18 months, and communicate all of that back to you in a language that isn't code. That part takes longer than the typing.

A senior developer can look at a problem and immediately know three solutions that won't work and one that will. You are paying for all four.

The tools nobody invoices for

This is the part that surprises people most.

Software development requires a stack of tools that cost real money — monthly, annually, and continuously. A partial list from what we actually pay:

What this adds up to A developer with a standard professional toolset is paying $200–500/month in subscriptions before writing a single line of your code. None of that appears on your invoice as a line item. It's folded into the rate.

The hours nobody sees

When you pay for 10 hours of development time, here's what you're often not getting: 10 hours of someone typing code.

You're getting roughly 2 hours understanding the problem correctly — the most valuable 2 hours in the project. Three hours of implementation. Two hours of testing, including edge cases you never thought to mention. One hour dealing with something in your existing system that doesn't behave the way the documentation says it does. One hour of communication and questions. And one hour of things going sideways in ways that are nobody's fault.

That's not padding. That's what building software for someone else's business actually looks like.

And none of that includes the years of accumulated knowledge that let a developer do 10 hours of work in 10 hours instead of 40.

The expertise you're not seeing

When we quote a project, the number reflects how long it will take us to do it right. That timeline is compressed — significantly — by experience. A developer who has built similar systems before isn't billing you for the time they spent learning. They already did that, on someone else's dime or their own.

You're not paying for code. You're paying for someone who knows what code not to write.

Every bad approach avoided is hours saved. Every architecture decision that doesn't require a rewrite in six months is money saved. Every security problem caught during development instead of after launch is a crisis avoided. Experience doesn't show up on a line item. It shows up in what doesn't go wrong.

How to evaluate a quote

If you get a quote and your first reaction is "that seems expensive," ask yourself: compared to what?

Compared to someone cheaper? Find out why they're cheaper. Are they faster because they're experienced, or are they underbidding to win the work and will recover the margin through scope changes? Both happen regularly. Ask what the timeline assumes. Ask what's not included.

Compared to off-the-shelf software? That's a fair comparison, and often the right one. Off-the-shelf exists because many problems have been solved before, and you shouldn't pay to solve them again. We tell clients this regularly — even when it means they don't hire us. But off-the-shelf has its own costs: fit gaps, workarounds, license fees that compound annually, and the ceiling you hit when your needs grow past what the product was designed for.

Compared to doing nothing? That one's the most expensive option. It just looks free because the cost is invisible — in manual work, in errors, in the competitive ground you're not gaining.

💡
Before you evaluate any quote: Ask the developer to walk you through where the hours go. Not to justify the number — to understand what's being built and what the risk is if it's done badly. A developer who can explain this clearly is probably someone who builds clearly too.