Winning work

Pricing, estimates, and the proposal that gets signed

Three pricing structures, an estimate you can stand behind, and the order a proposal has to be written in.

A client asks for a price. Someone spends three days reading the request, sketching tables, arguing internally over whether the payment integration is inside the number or outside it, and sends back a single figure under a two-line description of scope. Then one of three things happens: silence, a request for a discount, or acceptance followed by the discovery, three weeks in, that the figure never covered moving eleven years of records out of the old system. The three outcomes have one cause. The estimate was produced free, quickly, from an understanding of the problem that nobody had paid anyone to build.

Price is part of how work is won, not paperwork that follows it

Pricing tends to be treated as an administrative step after the selling is finished. It is closer to the first serious thing a buyer learns about a company. Before the number itself registers, the structure around it — fixed, hourly, staged, with or without a paid scoping phase — tells the buyer whether the company has done this before, and whether it intends to be held to anything.

A proposal also travels further than any conversation does. It is forwarded to a finance manager who was on no call and to an owner who heard about the project secondhand. The document argues on its own, in a room the seller is not in, which is why its contents and their order matter more than the tone of the meeting that produced it.

Structure filters as well. A company that always quotes a free fixed price attracts buyers who collect four such documents and compare numbers describing four different projects. A company that charges for scoping has fewer conversations and closes a larger share of them. Which is preferable depends on capacity, but it is a choice, and most companies have never made it deliberately.

Three structures, and the risk each one moves

StructureWho carries the risk of scope being wrongReasonable when
Fixed priceThe companyBoundaries are already known in detail
Time and materialsThe clientDirection will move; trust already exists
Paid scoping phaseShared, and smallThe work is not yet understood well enough to price

Fixed price gives the buyer certainty and hands the company every unknown. It is an honest instrument when scope is genuinely known and a quiet form of gambling when it is not. Companies that quote fixed prices on work they do not understand tend to recover the loss later by fighting over change requests, which costs them the relationship and the second project along with it.

Time and materials is the honest structure for work whose direction will move, and it needs a buyer who will read a timesheet and a supplier who will explain one. In Egypt and across the region, a first-time buyer of custom software will usually refuse an open-ended hourly arrangement, and the refusal is not unreasonable. They have no way to judge whether forty hours on a reporting screen was forty hours of work.

The third structure is not a compromise between the first two. It comes before both.

The paid scoping phase is the change worth making first

A scoping phase is a small fixed-price engagement, commonly two to four weeks, whose deliverable is not software. It produces a written scope, a data model, a list of integrations naming the state of each third-party system, a list of the risks that could move the number, and the estimate itself. Where screens are contested, it produces clickable ones. The fee is a fraction of the expected project value, and part of it can be credited against the build if the client proceeds.

Three things change at once. The company stops writing free specifications for buyers who were price-checking. Serious buyers identify themselves by paying a small amount, which is a cheaper qualification instrument than any number of meetings; the same signal is worth reading in the discovery call. And the estimate that comes out the other side is one the company can stand behind, because it was produced with access to the client's data, their existing systems, and the person who will actually use the thing.

There is a fourth effect that is harder to see. A paid phase changes the relationship before the build starts: the client has already bought something and received it, on time, in the form promised. The first delivery has happened, and the working relationship is no longer hypothetical.

Estimating a number that survives contact with the work

Decompose to deliverables, not to phases. "Backend" is not an estimable unit. "Supplier statement report, filterable by date and branch, exportable to Excel" is. If an item cannot be described in one sentence that names what a user does with it, it is not understood well enough to price, and that is worth discovering before signing rather than after.

Estimate every item as a range, low and high, and sum both ends. A single number implies a precision that does not exist and pushes the estimator to hide uncertainty inside padding. A range makes the uncertainty visible and, more usefully, discussable — the items with the widest ranges are exactly the ones worth scoping further, cutting, or moving to a later phase.

Carry contingency as a visible line rather than as quiet inflation spread through the tasks. Buried padding is found eventually, and once it is found every other number in the document looks invented. A stated contingency, with one sentence saying what it covers, reads as competence instead.

Price the operating cost separately and show it. A build quoted at, say, 600,000 EGP may carry infrastructure, backups, monitoring and a support retainer of roughly 7,500 to 12,500 EGP a month, and a buyer who learns this after signing feels misled even though nobody lied. What a custom system costs is always a build number and an annual number, and the second one decides whether the relationship continues; the support and second-project economics follow directly from how visibly it was priced at the start. Softwiro quotes build and operation as two numbers on one page for that reason.

What a proposal contains, and in what order

  1. The buyer's problem, in the buyer's words. Half a page in their vocabulary, with their branch names and their process. This is the section that gets the document read by the third person it is forwarded to.
  2. Scope. The deliverables, listed as they were decomposed for the estimate.
  3. Exclusions. What is explicitly not included.
  4. Price. Build, contingency, and monthly operating cost, kept separate.
  5. Timeline. Milestones with dates, and what the client must supply for each date to hold.
  6. Terms. Advance, payment schedule, acceptance criteria, and what happens when scope changes.

The order is doing real work. A proposal that opens with the company's history and its list of technologies asks the buyer to care about the seller before the seller has shown any understanding of the problem.

The exclusions section prevents more disputes than the scope section does.

Scope tells the buyer what they are getting. Exclusions correct what they had silently assumed. Content writing, cleaning the data in the old system, third-party licences and gateway fees, training beyond a stated number of sessions, a mobile application, integration with an ERP that has not been chosen yet — each of these has ended projects that had a perfectly clear scope section. Exclusions are not defensive legal text. They are the part of the document where two parties discover they were imagining different projects, at the one point where discovering it is still cheap.

"It is too expensive", and what to say instead of a discount

The sentence usually means one of three things: the budget genuinely is smaller than the project, the value has not been established, or the number is being compared against a cheaper proposal for a different scope. Each has a different answer, and none of the answers is a discount.

If the budget is smaller, make the project smaller. Take the two deliverables carrying the least immediate value out of the first phase and quote them separately, so the price falls for a stated reason. If value is unestablished, go back to the cost of the current process — hours of manual reconciliation each month, stock written off, invoices issued late — and let the buyer make the comparison. If a cheaper proposal is on the table, put the two scopes side by side line by line; the gap is rarely price and usually everything the other document did not mention, and showing that is more persuasive than defending your own number.

A discount given for nothing teaches the buyer that the first number was invented, and it puts every later number you send in the same category. If the price moves, something in the scope moves with it, visibly.

Terms carry their own weight. An advance of roughly a third is standard and defensible, and a client who cannot support one will usually struggle with the middle instalments too. Tie the remaining payments to demonstrable milestones rather than to calendar dates, since a date can pass without anything being true, and write the acceptance criteria for each milestone before the work starts rather than negotiating them at the moment of invoicing.

The change with the widest effect is to stop giving the scoping work away: charge a small fixed fee for the phase that produces the estimate, and let the estimate be something worth signing. If there is a project to scope now, contact Softwiro.

Questions this raises

Should the scoping phase be free if the client says they will sign afterwards?

No. A promise to sign later is not a commitment, and the phase costs the company real weeks of senior time. Charging a small fixed fee is what separates buyers who intend to build from buyers who are collecting comparison documents. Crediting part of the fee against the build if the client proceeds keeps the offer fair without making it free.

What advance payment is reasonable on a custom software project?

Around a third of the build price is standard and easy to defend, with the remainder tied to milestones that can be demonstrated rather than to calendar dates. A client who cannot pay an advance will usually struggle with the middle instalments, so the request also works as a check on whether the project is funded at all.

Fixed price or time and materials for a first project with a new client?

Neither, until the work is understood. Run a paid scoping phase first, then quote fixed price for the part the scoping made concrete. First-time buyers of custom software rarely accept an open-ended hourly arrangement, and a fixed price offered before scoping simply moves an unmeasured risk onto the company that quoted it.

Have a system to build?

Softwiro designs, builds, and operates production systems. Describe what you need and we will come back with a scope rather than a slogan.

Start a project