Is the cheapest quote always the wrong choice?

No. It can be the right one if the scope is genuinely equivalent and the person across the table has understood what you need. What should worry you isn't a low price, it's a quote that doesn't let you tell what you're buying.

Why do some providers refuse to give a price before several meetings?

Because quoting seriously means understanding the business, the specific rules and the tools already in place. That's legitimate up to a point. Beyond two conversations with no ballpark at all, you're entitled to ask for one.

Should I ask for a detailed quote or a simple one?

Both. A short, readable quote listing what you receive, and a separate document explaining the technical terms. An unreadable quote protects nobody, not you and not the person who wrote it.

What must a development quote always include?

The precise scope, what is explicitly excluded from it, the price, the timeline and the date it starts counting from, the payment schedule, how long the acceptance period lasts after delivery, and what you own at the end.

Is a fixed price always better than time and materials?

For you, yes in the vast majority of cases. A fixed price moves the overrun risk to the provider, and forces them to scope the project properly before starting. Time and materials mainly makes sense when the scope genuinely can't be defined upfront.

All articles

Field notes

Two Quotes, 40% Apart: How to Actually Compare Them

Roméo · Founder

August 15, 202610 min read

Two quotes for the same project, 40% apart: how to actually compare them#

On our first large project, the client had two quotes on his desk. Ours, and another one, 40% cheaper. We never saw the other one. We lowered our price, because it was our first project and we wanted it.

What stayed with us wasn't lowering the price. It was realising, afterwards, that our client had probably never read the quote. He had read the number. And you can't blame him: a development quote is often four pages of terms he has no reason to know, written by someone who forgot the reader isn't a developer.

Since then, our quotes are short. The deliverables in plain language, a price, a date. And alongside it, a separate document that explains every feature: what it does, why we build it that way, with which technology. You can read one without the other. It's the only way we've found to make a quote comparable by something other than its total.

The gap is real, and wider than you think#

La Fabrique du Net compiled more than 1,300 real projects in France in 2026. A custom e-commerce build sits at a median of €45,000, with half of all projects landing between €20,000 and €65,000. A custom web application averages around €18,000. And in Paris, expect roughly 50% more than the rest of the country.

The interesting detail is that the Paris premium doesn't come from salaries. The daily rate gap between Paris and the rest of France is 5.6% for a front-end developer: €566 against €536. Meanwhile, the gap between a developer with two years of experience and one with fifteen is €317 against €671, more than double.

In other words: what you pay extra at a large firm is rarely the developer. It's the firm.

Here's a concrete reference point. We quoted €15,000 for a multi-location e-commerce platform: three languages, point-of-sale integration, orders from three delivery platforms centralised in one place, click and collect with time slots, and a back office with three permission levels. That sits below the bottom quartile of the French market for that kind of project. Local agencies in the client's own country were pricing the same scope between $20,000 and $40,000.

The real difference is in what gets finished#

Price isn't the first place where two providers diverge. The first place is the quality of what actually ships.

A lot of developers now write code with AI. That isn't a problem, we're the first to say how much it helps, and it lets you build fast. The problem is when the next step gets skipped. Checking for bugs. Checking security. Pushing the product to its limits before handing it over. A tool generated quickly and never tested works beautifully on demo day, and costs you dearly six months later.

Then come things that are less visible on a quote and very visible in daily use. The quality of the interface and the flow. How well the code and the database are optimised. Simplicity above all, which never happens by accident: it comes from real thinking upfront about how your team will use this thing every day. That's where experience shows, for better or worse.

A tool your team understands on their own saves you hours of training, and more importantly, months of poor adoption. You can't read that on a quote. You can read it in a demo.

How much attention someone can actually give you#

There's a factor nobody talks about: how many projects your provider is running at once.

A developer handling two projects in parallel has a psychological price floor they won't go below, because a third project would cost them significantly more mental load. That floor has nothing to do with how many lines of code need writing. It has everything to do with available attention.

And that's the real shift of the past few years. A developer today sells their thinking more than their code. AI lets you ship a feature extremely fast, but the brain deciding which feature to build, how it fits with everything else, and what will break in six months doesn't move any faster.

It's also why we take on few projects at a time.

Outsourcing: a real factor, but not the only one#

At agencies, outsourcing explains part of the gap, and it should be said out loud.

We're not against it on principle. If the code quality is reviewed by a developer at the agency, and if professional testing pushes the build to its limits for bugs and security, everyone wins. The client gets a better price. The person writing the code earns a fair rate, often a very good one relative to where they live. And the agency keeps responsibility for the project going well.

Outsourcing isn't the problem. Outsourcing with no review and no testing is. So ask the question directly, rather than trying to guess the answer from a quote.

The four line items that almost always go missing#

Looking at other providers' quotes, these four are the ones that disappear most often.

Recurring infrastructure costs. Hosting, database, deployment services. We regularly see estimates that forget them or underestimate them, because these costs depend on your traffic and not on the provider's work. They're on your bill every month all the same.

AI-related costs. If your tool calls an AI model, every use has a price. These costs are genuinely hard to estimate before launch, and we won't pretend otherwise. But a provider who never mentions them hasn't planned for them.

Who owns the code on delivery. This one almost never appears, and it's the one that ties you down longest. Do you walk away with the source code? With the hosting credentials? If it isn't written down, the answer is probably no.

Training your team. It's nearly always absent from the main package, and nearly always offered separately once the project has launched.

Six lines on a quote that should stop you#

Three nobody warns you about, and three classics you should never let through.

The three quiet ones:

"Hosting included", with no duration and no mention of what happens next. Included for how long? And after that, who gets the bill, and how big is it?
"Compatible with your existing system", without naming the system. Compatible with which one exactly? Who provides the technical access? And if your current tool doesn't expose what's needed, who pays for the investigation? Third-party integrations derail more projects than anything else.
"SEO optimisation included." That can mean correct tags and a clean structure, which is half a day of work. Or a real content and link strategy, which is several months. Ask which one.

The three classics:

"Custom development: fixed package", on a single line. If the scope fits on one line, there is no scope. What isn't written won't be delivered, or will be billed again.
"Support and maintenance", with no amount, no scope and no response time. Support with no price and no commitment is a sentence, not a service.
"Delivered within X weeks", without saying from when. From signature? From the deposit? From the day you hand over your content and access? There's often a month between those three dates.

Day rates: a number that says very little#

We used to have a day rate of €550. We no longer apply it to our projects, because we don't think it means much.

We don't sell our time, we sell a finished product. If we spend several hours stuck on an idea and that's on us, it isn't your job to pay for our fog. And the other way round, if we ship a feature very fast, that doesn't mean the price should drop: speed has value, and it's actually what you're buying.

A day rate billed as you go rewards slowness and penalises mastery. That's why we'd rather study the project, set a firm price, and hold it. We take whatever time is needed to understand the requirements before quoting: sometimes one call, sometimes several days depending on the size of the project and how much of it is unknown.

In the same spirit, be wary of search ranking sold with a guaranteed position. Nobody controls Google's rankings. Promising a spot means selling something you don't own.

Three questions to ask before you sign#

Do your teams use AI to write code, and how do you check the output?

The first half of the question doesn't matter. The second half does. What you want to hear is how bugs and security are verified before delivery.

Describe my requirements back to me in your own words.

A provider who has understood your business will describe your own problem better than you did. A provider who repeats your brief word for word hasn't digested it yet.

What will my recurring costs be, and what exactly does maintenance cover?

Ask for amounts, not percentages. And ask what happens if you don't take the maintenance.

Can you really compare two quotes?#

Honestly, only if the scope is close. Two online stores, yes. Two business tools with comparable capabilities, yes. A web application against an automation, no: those are different kinds of project, with different timelines, different complexity, and a different effect on your business.

Before you compare totals, bring both quotes back to the same scope. Line by line, what one contains and the other doesn't. It's tedious, it takes an hour, and it's the one hour of your project that might save you several thousand euros.

And if a quote makes that exercise impossible because it's too vague or too technical, that isn't your fault. That's information about whoever wrote it.

Let's talk about your project#

If you have a quote in hand and don't know what to make of it, tell us in a couple of sentences what you have in mind. We'll tell you honestly what we think, including when the right answer is to stay on an off-the-shelf tool.

Let's talk about your project

Frequently asked questions#

Comments

No comments yet. Start the conversation.