Pricing: every project is quoted individually

Why a quote rather than a price list

In short: Two projects described by the same phrase — “a marketing site”, “a conversational agent” — can require incomparable amounts of work. The phrase does not state the scope; the price follows the scope.

A price list assumes comparable products. Software sold under licence can have one: the product is identical for everyone. Custom work cannot, because what gets delivered differs every time. “A marketing site” may mean a single page fed by text that is already written, or a multilingual set connected to an existing management system, with access rules and content migration. The same label covers two workloads with nothing in common.

Publishing a starting price dodges the problem rather than solving it. The figure attracts, then the real scope contradicts it, and the conversation opens with a correction — a poor way to start. The honest alternative is to state what makes cost vary, to state it up front, and to set the figure once the scope is written down.

A quote is more than a price. It is the first document where scope is written explicitly: what is included, what is not, what the client supplies and what remains to be produced. That part is what prevents later disagreements, far more than the figure itself.

What makes a project cost more or less

In short: Five factors explain most of the spread: functional scope, the existing system to carry over, content and its languages, third-party integrations, and the level of rigour expected.

Functional scope is the most visible factor. A page presenting an offer with a contact form is not the same work as a space where users sign in, upload documents and trigger processing. Every function brings its interface, its error cases, its access rules and its tests — the function itself is often the smallest part.

The existing system weighs just as much, and is underestimated more often. Starting from a blank page is sometimes cheaper than carrying over a live system whose data must be migrated, whose addresses must be preserved, whose users have habits, and which has to keep serving traffic during the switch. Poorly documented data migration can account for a significant share of a project’s effort while producing nothing visible on screen.

Content determines a share of the cost that many discover along the way. Who writes the copy? Is it ready? How many languages, and who signs off on each? Translation is not mechanical conversion: it needs review by someone who speaks the language and knows the subject. A project can be technically finished and still stall for lack of content.

Third-party integrations add a dependency on something you do not control: a payment system, a management application, a sending service, a data source. Each brings its own authentication, usage limits, possible outages and documentation of varying accuracy. The cost of an integration lies less in wiring it up than in what it forces you to plan for when it fails to answer.

The level of rigour, finally, is chosen and paid for. Verified accessibility, measured performance, reviewed security, test coverage, operational documentation: these are real work, not checkboxes. They can be reduced knowingly; what is expensive is discovering them after launch.

Fixed price, time and materials, retainer: what each model implies

In short: Three billing models exist, and the choice is less about price than about who carries the risk. The quote states which one applies, and to what.

A fixed price sets a figure for a described scope. It moves estimation risk to the supplier, which is reassuring — on one condition: the scope must be precise enough to be held to. Its counterpart is rigidity. Anything not described falls outside, and every change goes through an amendment. Fixed price therefore suits work that is stable and well understood, rarely exploration.

Time and materials suits the opposite: a scope that will evolve because you learn as you go. It moves the risk to the client, and is only acceptable alongside real visibility — what was done, what is under way, what was decided. Without that reporting it becomes spending without a rudder.

A retainer covers what does not stop: maintenance, dependency updates, monitoring, fixes, regular improvements. It matches a reality that project mode hides — a site is not an object delivered and then finished. The point to clarify in a retainer is always the same: what it includes, what it excludes, and what happens when a request exceeds its frame.

These models often combine on one project: fixed price on the stable part, time and materials on what remains to be explored, a retainer once live. What matters is not which model is chosen, but that it is named and that its limits are written down.

What to gather in order to get a usable quote

In short: A quote is worth what the description before it was worth. Four elements are enough to move from a vague estimate to serious costing.

The first is the objective, expressed as an outcome rather than a solution. “We want a website” describes a means. “We want appointment requests to arrive without a phone call” describes an outcome, and leaves open whether a website is the best answer. An objective stated as an outcome also lets you check later whether it was met.

The second is the existing system: what is already in place, what must be kept, what can be dropped. Current addresses, accounts, tools used daily, data to carry over. This is the part most often left out of quote requests, and the one that explains most gaps between an estimate and a final cost.

The third is the constraint, whatever it is: a budget envelope, a deadline imposed by an outside event, a regulatory obligation, a mandated tool. Naming a budget does not weaken your position — it lets the scope be adjusted rather than producing an off-target proposal.

The fourth is the decision: who signs off, and on what. A project with no identified decision-maker moves until the first trade-off, then stops. Naming that person at quoting time is the cheapest and most frequently forgotten step.

How to compare two quotes

In short: Comparing figures before scopes is meaningless. The cheapest quote is often the one describing the least, which is not the same as the one that will cost the least.

Start by putting the scopes side by side, not the totals. A price gap is almost always a content gap: one plans for data migration, the other does not; one includes testing and acceptance, the other leaves them to the client; one prices three languages, the other one. As long as the scopes differ, the figures are not comparable.

Then look at what is explicitly excluded. A serious quote contains a list of exclusions; its absence does not mean everything is included, it means the question was not settled. The most common exclusions concern content, translation, hosting, third-party licences and training.

Finally check the clauses that carry no price but a cost: who owns the code produced and the accounts created, where the data is hosted, what is handed over at the end, and what happens if the collaboration stops. These points negotiate well only before signature. Afterwards, they are endured.

What the initial price does not cover

In short: Launch is not the end of spending. Hosting, domain names, software dependencies and content all keep existing after delivery.

A live site consumes resources: hosting, domain name, certificates, sometimes third-party services billed by usage. These items are usually modest relative to the project, but they recur, and a forgotten renewal takes a site offline as surely as an outage does.

Software dependencies age. The libraries in use publish fixes, security ones included, and a project left without updates becomes progressively harder to pick up: the wider the gap grows, the more the catch-up costs. It is the easiest expense to postpone and the most expensive to postpone for long.

Content, finally, dates faster than code. An offer changes, a service disappears, a page stays. The question to ask at quoting time is not only “who builds it?” but “who updates it, and how?” — because a site nobody can change without technical help ends up never being changed at all.