Why I price projects item by item

When a manager asks for a quote on a new system, what usually comes back is a single number at the bottom of the page. Above it, a list of features. Below it, a delivery date. The offer looks clear, but it leaves important questions unanswered.

I work differently. The offers I send are priced item by item. Here I explain why, what that kind of offer looks like, and what it means for you in practice when you remove, postpone, change or pay for something.

What a lump-sum quote hides

A lump sum puts very different things into one box. The order management screens, the accounting integration, the mobile app and the reports all melt into one figure. That's where the problems begin:

• You can't see where the money goes. A small part of the project might be the most expensive one, and you'd never know.
• Comparing offers is hard. Two quotes with different totals may cover different scopes, and a single number won't show you the difference.
• Removing anything starts a new negotiation. If you decide to drop a part, nobody knows how much should come off the price.
• What you don't need disappears into the total. An item you have no use for may be priced in, and you won't know it's there.
• The timeline is vague. One delivery date for the whole project doesn't tell you when any single part will be ready to use.

The total may be completely honest. The problem is that it doesn't give you what you need to make a decision.

What an itemized offer looks like

The offer starts from the written spec in Arabic that you checked line by line. I split the project into items, and each item is a piece that means something in your day-to-day work. For a typical operations project, the items might look like this:

1. Order management: receiving an order, tracking its status, assigning it to a staff member.
2. Connecting the online store through its API so orders arrive automatically.
3. A dashboard for management showing today's numbers on one screen.
4. A mobile app for delivery reps.
5. Monthly reports with export to Excel.

These are illustrative, not taken from a specific project. In the offer, each item gets a line that says three things: what it includes, what it costs, and how long it takes. The total comes at the end, after the items, not in place of them.

Items are described in the language of your business, not the language of programming. You don't need to know how a database is designed to decide whether you need monthly reports now or later.

Remove or postpone without renegotiating

The first practical benefit of itemized pricing is freedom to decide. You can remove or postpone any item, and the remaining items keep their prices and durations exactly as stated in the offer.

Take a typical situation: this year's budget doesn't cover the whole project. With a lump sum, a long discussion about discounts begins, and nobody is sure what gets cut in return. With items, the decision is simpler. You start with order management and the store integration, and postpone the reps' app until later. The new price is the sum of the remaining items, with no side calculations.

Quite often, a business owner reading the offer realizes that one item can be dropped entirely, because a tool they already use handles it well enough. Removing it at that stage costs nothing.

One point needs to be clear: some items depend on others. The reps' app displays orders, so it needs the order system first. I write these dependencies into the offer itself, so you know before removing anything what else is affected.

How I handle additions and changes

Additions are a normal part of any project. Once your team starts using the first release, new ideas come up, and some of them genuinely matter.

The rule I work by: any addition is priced before it's built. When you ask for something outside the agreed items, I write it up as a new item in the same format: what it includes, what it costs, how much time it adds, and where it fits in the order of releases. Then you choose:

• Build it now, knowing its effect on the delivery date.
• Postpone it to a later release.
• Swap it for another item that hasn't been started yet.
• Drop it.

I don't start on an addition until you've approved its price and its effect on the timeline in writing. That protects you from a surprise invoice at the end, and protects me from a scope that grows without anyone noticing.

An addition priced before it's built is a decision you make. An addition discovered on the invoice is a dispute.

There's a difference between an addition and a fix. If something already agreed in the offer has a bug, fixing it is part of that item and isn't priced again. After launch, the support period set in the offer covers any bug that appears, and maintenance after that is optional.

Payments tied to what's delivered

I deliver in releases. Each release is a group of items, deployed to a staging environment that you test yourselves. I don't move to the next release until you've approved the previous one.

Payments follow those releases. A payment is tied to a release I delivered and you tried, not to a date on the calendar. That way, what you pay for is something you can see and use.

This is where itemized pricing and staged delivery meet. Because each item has its own price, you know what a release is worth before it starts. And because each release is tested before the next one begins, you can revisit the remaining items after any release: remove some, postpone some, or add a priced one.

What this kind of pricing needs up front

An itemized offer takes more work before it's written. I start with one or more calls to understand how the work runs today, then write the spec for you to review. When a project is a good fit, I prepare a clickable prototype within days, with a walkthrough video, free of charge. Only then can I break the project into clear items that can be priced accurately.

If the project relies on connecting to platforms you already use, I check their APIs in the first week and give you a written report on what can be connected, what can't, and the alternative. If a connection turns out not to be possible, the related item is adjusted before it's built, not after.

A checklist before you accept any offer

Answer yes or no about the offer in front of you:

• Can you see the price of each part of the project separately?
• Does each part have a clear duration?
• Are the items written in the language of your business, so you understand them without a technical explanation?
• Can you remove or postpone an item without renegotiating the rest?
• Does the offer show which items depend on others?
• Is there a written way to price additions before they're built?
• Are payments tied to releases you receive and test?
• Do you know what the support period after launch covers?

If many of your answers are "no", ask for more detail before you sign. A clear offer protects both sides.

If it helps, describe how your process runs today and what you want the system to do, and I'll show you how it could be broken into items.

Related to this articleProcess