Quoting changes on an inherited project without losing your margin

A client comes to your agency with a website, a business application or an app that someone else built, and asks for “just a few changes”. Or they ask for something your team doesn’t usually do: an integration with their warehouse software, a members’ area, a custom plugin. Either way, the quote starts from a two-line request and a vague idea of what’s underneath.

When I work with agencies, most of the problems I see start right there, before the project begins. Someone commits to time and cost without understanding the technical side, or quotes changes on inherited code as if the code were sound. Once work is under way, integrations, data to migrate or code to fix turn up that nobody had priced in, and the margin goes with them.

In short

• Before you put a number on it, ask for access to the code, hosting and data, and find out who built it.
• On an inherited project, run a short technical check, then split the work into parts, each with an estimate and a risk level.
• Parts you can’t estimate don’t belong in a fixed price. Quote in phases, or sell the analysis as its own paid piece of work.
• Write into the offer the assumptions the price depends on, and what happens if one turns out to be wrong.

Why the margin disappears after signing

You price the visible part, the change the client asked for. The cost depends on the part you can’t see: the state of the code, the data, the integrations, the software versions on the server.

Construx, a consultancy that specialises in software estimation, calls this the “cone of uncertainty”. An estimate made at the initial-concept stage can be off by a factor of 4 in either direction, and that’s the best case, with skilled estimators. Uncertainty only shrinks as the work gets defined, and organisations that commit to time and cost too early undermine their own projects (Construx). A fixed-price quote signed on a two-line request is exactly that kind of early commitment.

A typical case: the client wants one more field on the sign-up form. It looks like half a day. Then you find out the form writes to a table that an external system also reads, the forms plugin was edited by hand and can’t be updated, and the server runs a PHP version the new code doesn’t support.

What to ask the client before quoting

Ask these while the answers can still change the price.

1. Who built the project, and can you still reach them?
2. Where is the code? A Git repository, a folder on the server, a zip file? Is what’s running in production the same as what you’re being handed?
3. Hosting and domain. Whose name are they in, who has the control panel login, where is DNS managed, does email run on the same domain?
4. Backups. Is there a recent one? Has anyone ever tried restoring it?
5. Data. What’s in the database, does it include personal data, does any of it need migrating or importing from another system?
6. Integrations. Payments, accounting or ERP software, CRM, newsletter, other external services: who holds the API keys, and whose name are the accounts in?
7. Licences. Paid themes, plugins or libraries: who are they licensed to, and when do they expire?
8. Documentation and a test environment. If they’re missing, creating them is work you need to quote.

If the client can’t give you access before the quote, don’t give them a fixed price for something you haven’t seen.

If you work with EU clients, personal data needs a thought too. Under the GDPR, an agency that processes personal data on the client’s behalf is a processor, and that processing has to be governed by a contract or other legal act. A processor also can’t bring in another processor without the controller’s prior written authorisation, specific or general (GDPR, Article 28). If you’ll need an outside consultant who can see that data, raise it with the client early.

A minimal technical check on an inherited project

This is narrower than a code audit. The point is to find whatever changes the price. These are the things I look at:

• Can it be installed from scratch? Try getting the project running locally or on a test environment. If it takes a day just to start it up, that day is a cost.
• Versions. Language, framework, CMS, plugins. For PHP, the supported branches today are 8.2 to 8.5, and 8.2 only gets security fixes until 31 December 2026 (php.net). Older branches no longer get security fixes at all. If your change needs an upgrade, the upgrade is a line item of its own.
• Third-party code edited by hand. Plugins, themes or libraries changed directly get overwritten on the next update. Find them first.
• Automated tests. If there are none, every change has to be checked by hand across everything connected to it, and that time has to be estimated.
• How far the change reaches. How many files and features it touches, and what depends on them.
• Data to migrate. Structure, volume and quality: duplicates, fields used for something other than their name suggests, inconsistent formats.
• Hidden processes. Scheduled jobs, webhooks, a script someone runs by hand every Monday.

How to price uncertainty

When I prepare an estimate for an agency, I split the work into parts and give each one a time estimate and a risk level. Clear parts can go into a fixed price. Uncertain parts only go in with a written assumption. Parts that can’t be estimated yet are flagged as such, with no made-up number next to them.

Part	Risk	How it gets priced
Test environment and a verified backup	low	fixed price
New field on the form and in the database	low	fixed price
PHP and plugin upgrades	medium	fixed price with stated assumptions
Sync with the external system	high	separate phase, after analysis

For the uncertain parts there are three tools, and you can combine them.

Phased quote. Phase one covers the check, making the project safe to work on, and the clear parts, at a fixed price. Later phases get quoted once phase one has removed the unknowns. The client knows from day one what it costs to start, and can see how you’ll get to the rest.

Paid analysis. When there’s a lot of uncertainty, the analysis becomes a piece of work in its own right, with a document at the end. The UK government’s Service Manual asks the same of its own teams: before committing to build a service you need to understand the problem, and you don’t start building during this “discovery” phase (GOV.UK Service Manual). The client keeps the document even if they decide not to go ahead.

Hours with a cap. For the parts you only understand once you’re in them, such as fixing bugs whose cause nobody knows, you can work by the hour up to an agreed maximum. When you hit the cap, you stop and decide together what to do next.

How to write assumptions into the offer

A useful assumption can be checked, and it says what happens if it turns out to be false. A few examples to adapt:

• “This quote is based on the code delivered in the stated repository on [date]. If the code in production differs, bringing them in line will be estimated separately.”
• “Migrating existing data and fixing faults present before our work starts are excluded. If requested, they will be estimated separately.”
• “The migration covers up to [number] records in a single format. Data in other formats will be estimated separately.”
• “If problems in the existing code turn up that block the change, we will flag them with an estimate before doing any work on them.”
• “The client will provide access to hosting, the repository and external services by [date]. Delivery dates run from that date.”

Name each exclusion. I avoid catch-all wording like “anything not expressly listed”: when a dispute comes up, each side reads it their own way. And have a lawyer review the contractual part of your offer template.

Where I come in

When an agency brings me in, I start from the analysis, and if the project already exists, from the state it’s in. You get a document to build your quote on, branded as yours if you need to pass it to the client, and if any part is uncertain I tell you before it reaches them. If what you need is a full assessment of the code’s quality, that’s a different job: a code audit.

How I work with agencies, from brief to handover, is on the white-label consulting page.