# How to Estimate Development Work Without Padding Quotes

> How to estimate development work on Shopify projects: estimation techniques that replace blanket padding with ranges, reference data, and named risks.

_Published: 2026-10-19 · CommerceCopilot_

## Padding is a confession, not a technique

Ask most agency teams how to estimate development work and the honest answer is some version of "gut feel, then add 30 percent." The padding is a rational response to getting burned: every developer has quoted two days for a ticket that took five, so the next estimate quietly carries the memory of the last overrun. The problem is that a blanket multiplier does not manage the risk it compensates for; it hides it. Safe tickets get overpriced and lose you work, genuinely risky tickets stay underpriced because 30 percent was never going to cover an undiscovered app conflict, and nobody learns anything, because the final number no longer maps to any belief that could be checked against reality.

This post is about replacing that multiplier with estimation techniques that survive contact with a real Shopify project: estimating from tickets instead of briefs, putting ranges on record instead of single numbers, and using your own history instead of your own optimism. It picks up where [project scoping](/blog/shopify-project-scoping) leaves off: scoping decides what is being built and what it depends on, and estimation puts effort numbers on work that is already defined.

## An estimate is not a commitment

The single most useful distinction in software estimation is between the estimate, the target, and the commitment. An estimate is an honest prediction with uncertainty attached: "this is likely 3 to 5 days." A target is what someone wants: "the client hopes to launch before Black Friday." A commitment is a business decision: "we will quote 4 days at fixed price." Teams that collapse these into one number end up negotiating the estimate itself, and an estimate that moves under pressure was never an estimate.

Kahneman and Tversky named the [planning fallacy](https://en.wikipedia.org/wiki/Planning_fallacy) in 1979 to describe the tendency to underestimate how long tasks will take, and its sharpest feature is that it survives experience: people underestimate their next project even when they know their previous ones all ran over. Your developer's "two days, probably" is not a lie. It is a best-case scenario wearing the costume of a prediction. Good estimation technique is mostly machinery for correcting that bias, which is why "just estimate better" never works as advice.

## Why early estimates are wide, and what narrows them

Barry Boehm's research data, later popularized by Steve McConnell as the [cone of uncertainty](https://athena.ecs.csus.edu/~buckley/CSc231_files/McConell_ConeofUncertainty.pdf), shows that at the initial-concept stage a software estimate can honestly land anywhere from 0.25x to 4x of the eventual actual. The range tightens as requirements and design get settled, but only if someone does the settling: the cone narrows because decisions get made, not because time passes.

Two practical rules fall out of this. First, do not quote with more precision than your current information supports; a tight single number against an unsettled scope is false precision, and the gap gets paid out of your margin. Second, the cheapest way to improve an estimate is rarely a better formula. It is resolving the questions that keep the cone wide: which apps are installed, whether the integration has an API, who signs off. That is why estimation accuracy is downstream of everything covered in the [scoping process](/blog/shopify-project-scoping).

## How to estimate development work: four techniques that hold up

### Estimate tickets, not briefs

A brief cannot be estimated, only guessed at. "Improve the mobile PDP" could be two days or three weeks, and no technique fixes that, because the variance lives in the ambiguity, not the math. The unit of estimation is the [dev-ready ticket](/blog/how-to-write-development-tickets): one change, with scope boundaries and acceptance criteria. Decomposing the work first converts one unestimatable blob into a list of mostly small, familiar tasks, and it surfaces the tickets that resist decomposition, which are exactly the ones hiding the risk. A ticket you cannot break down is a ticket you do not understand yet; flag it as an open question instead of absorbing it into a padded total.

### Use three points, not one

For any ticket with real uncertainty, ask for three numbers instead of one: optimistic, most likely, and pessimistic. The [PERT weighted average](https://pmstudycircle.com/three-point-estimation/), (optimistic + 4 × most likely + pessimistic) ÷ 6, turns them into a single expected value that keeps most of the weight on the realistic case. A metafield-driven size guide might be 4 hours if the theme cooperates, 8 hours most likely, and 24 hours if the product data needs restructuring: (4 + 32 + 24) ÷ 6, call it 10 hours.

The number matters less than the conversation it forces. The pessimistic estimate is where the developer finally says out loud what they are afraid of, and the spread between the three points is a direct readout of the ticket's uncertainty. A ticket estimated at 6 to 10 hours and one estimated at 4 to 40 hours are completely different quoting situations. Blanket padding treats them identically; three-point estimation prices them apart.

### Check against your own actuals, not your intuition

The strongest corrective to the planning fallacy is what Kahneman called the outside view: stop simulating how this project will go and look at how similar projects actually went. For an agency, that means your tracker is an estimation asset. Before a quote goes out, pull the last few comparable jobs and compare their estimates to their actuals. If your last four theme-section builds each ran 1.4x the estimate, the honest move is not to hope this one is different; it is to apply 1.4x and then find out why the ratio exists. That ratio is not padding: padding is a buffer on a guess, while a historical ratio is a measured correction that improves as your data does. It only works if actuals get recorded, so fifteen minutes at project close to log them against the estimates is the cheapest estimation improvement available.

### Get a second estimate, independently

Estimates converge fast when people hear each other's numbers first, and they converge on whoever spoke first or most confidently, not on whoever is right. If a ticket is big enough to matter, have two people estimate it without seeing each other's numbers, then compare. Agreement means move on. Divergence is information: one person knows something about the theme, the client, or the edge cases that the other does not, and ten minutes of comparing assumptions is worth more than any formula. This is the useful core of planning poker without the ceremony; for a small agency it is just two people writing a number down before the standup.

## Where Shopify work breaks generic estimates

Generic estimation advice assumes the main variable is the code. On agency Shopify work, the estimate-killers cluster somewhere else:

- **The existing theme.** An estimate made against "a Shopify store" instead of this store's theme is a guess. Years of accumulated custom code can triple a simple section build, and the only way to know is to read the theme before the number goes out.
- **Installed apps.** Apps inject scripts, own DOM elements, and conflict with each other. A ticket that touches the cart on a store with 30 apps carries integration risk the ticket text never mentions.
- **Checkout boundaries.** Work that drifts toward checkout customization changes category, not just size, depending on the store's plan and Shopify's extensibility rules. Flag it as scope, not as hours.
- **Waiting, not working.** Most calendar overrun is not development time; it is content, approvals, and third-party dependencies, as the breakdown in [how long a Shopify build takes](/blog/how-long-does-a-shopify-build-take) shows. Estimate effort and duration separately, and quote dates against duration.

## From estimate to quote, without the blanket multiplier

The estimate describes reality; the quote is a business decision built on it. Three habits keep the translation honest. Quote ranges where the cone is still wide, tied to the specific question that would narrow them: "$6,000 to $9,000, depending on whether the subscription app exposes order data via API." Convert hidden padding into named contingency: a line for "theme integration risk, up to 2 days" can be discussed, challenged, and dropped when it does not materialize, where a silent 30 percent cannot. And let the remaining uncertainty pick the pricing model: well-understood scope can carry a fixed price, while a still-fuzzy edge is a [time-and-materials conversation](/blog/fixed-price-vs-time-and-materials-shopify), not a padding problem.

## Where CommerceCopilot fits

Everything above assumes the thing being estimated is a defined ticket, and that is the step that falls apart under deadline pressure: the translation from calls, briefs, and Slack threads into scoped, dev-ready tickets usually lands on a senior person who does it late, which is how teams end up estimating briefs after all. That translation is what CommerceCopilot's Business Analyst agent does. It reads briefs, call transcripts, and connected channels, and drafts a dependency-mapped backlog with scope and acceptance criteria structured on every ticket, flagging open questions instead of assuming answers, with your team reviewing the draft before anything is created in the tracker. The [brief-to-tickets walkthrough](/docs/your-first-brief-to-ticket-project) shows that flow end to end.

For estimation specifically, that changes two inputs. Bottom-up estimation becomes possible immediately, because the decomposition it depends on already exists. And the flagged open questions are a ready-made map of the fuzzy edge: each one becomes a range, a named contingency, or a pre-quote technical check, instead of a surprise in week four.

## FAQ

### Should agencies estimate in hours or story points?

For client-facing quotes, hours (or days) are unavoidable, because invoices are denominated in money, not points. Points can be useful internally for relative sizing, but a small team maintaining two estimation currencies often loses more than it gains. A reasonable middle ground is estimating in ranges of hours and tracking the ratio between estimated and actual over time.

### How much contingency is reasonable on a Shopify project?

As a blanket number, none; that is the padding habit this post argues against. Contingency should be sized per named risk: an old theme, an unverified app API, a data migration of unknown cleanliness. Summed, those lines might total 15 percent on a clean project or 50 percent on an archaeological one, and both are defensible in a way a flat multiplier never is.

### Who should produce the estimate?

The person closest to the work, corrected by the record: a developer's three-point estimate, checked against historical actuals for similar work, with an independent second number on anything large. What does not work is estimation by whoever is best at sounding confident in the sales call.

### What should you do when an estimate turns out wrong mid-project?

Say so early, with the new range and the reason. An estimate is a prediction, and updating it on new information is the system working, not failing. The margin-killer is not the wrong estimate; it is carrying a known overrun silently until it becomes a dispute at invoice time.

---
Canonical page: https://www.commercecopilot.ai/fr/blog/how-to-estimate-shopify-development-work