What you can charge for when the work got cheap

When a piece of work gets quicker to produce, a lower quote is a reasonable thing to discuss. If you run a business on your own, or work as a fractional exec, that discussion needs to cover the job you are agreeing to do. The file at the end may be only part of it.

If AI makes the first proposal, design or code change quicker to produce, count that saving when you work out the cost. You still have to understand the request and check what you deliver.

Cost, price and value are separate. Your cost can fall while the result remains useful to the customer. That leaves room for a fee discussion; it establishes neither the price nor a reason for the customer to pay more. The useful question is what you are prepared to take responsibility for.

A proposal commits someone to the work

A proposal service can include deciding what to offer and checking that the promises are deliverable, as well as writing the document.

For illustration, suppose a solo operator is preparing a proposal to replace a customer's manual reporting process. Producing the draft is one task. Finding out whether the problem is late reports or unreliable source data is another. A quicker report built from the same unchecked figures may leave the customer's problem untouched.

The operator taking on that decision needs to examine the current process and agree what the proposed work excludes. If cleaning up old records belongs to the customer, that has to be settled before the proposal promises usable reports. The exclusion changes what is being sold.

A polished proposal can make a bad promise look agreed. Checking each promise against what can actually be delivered is a service someone can buy, provided that checking is included and done.

A design has to fit its intended use

Checking a design means trying it against the tasks and devices the customer agreed.

In a separate hypothetical example, a customer wants a booking page. A first layout gives them something to react to. It leaves decisions open about what visitors need to know before booking, which information the business needs to collect, and how someone corrects a mistake on a phone.

If the designer owns those decisions, the work includes agreeing the booking steps and checking the proposed screens against them. A mobile layout needs a mobile check. Walking through the agreed task on a phone is a concrete part of the service; adding a page headed “quality assurance” explains very little.

The customer may already have settled the booking process and only want layout options. In that case there is less responsibility to buy. The designer needs to describe that smaller job accurately too.

Code needs an agreed behaviour

For a code change, agree what it must do and how you will check it.

Suppose, as an illustration, a customer asks for a download button on a reporting screen. Writing the button leaves open which records it exports and who is allowed to download them. If those decisions are included in the engagement, the operator has to resolve them with the customer before treating the change as complete.

The checks then have something specific to test. The file should contain the agreed records. Someone without permission should be refused. A failed download needs an agreed response too, so a working demonstration is only part of the check.

Those checks provide evidence about the behaviours they cover. They do not establish that every possible failure has been found. Taking responsibility includes saying what was checked and what remains outside the agreed work, even when generating the change itself was quick.

Responsibility needs a visible act

Paid responsibility becomes specific when the customer can name a decision you will make, a check you will carry out and the result they can accept.

For the hypothetical booking design, that could mean owning the proposed booking steps, checking the screens against those steps on the agreed devices, and correcting failures found in that check before handing over. The customer still owns decisions about what their business will offer.

“Judgement” on its own is a difficult thing to inspect. A decision and its reason give the customer something to discuss. A recorded check shows what was examined. Extra paperwork without either adds little to the explanation of the fee, and more checking is no guarantee of a better commercial result.

A smaller service can be enough

A customer who needs only an initial draft has a reasonable case for buying a smaller service. They may have the experience to check it themselves, or already employ someone who will make the remaining decisions. Asking them to buy those decisions again needs a reason.

I think a fee is easier to defend when the responsibility is specific enough for the customer to decline it. They can then compare a draft they will finish themselves with work you will take through the agreed checks. Neither choice implies that the other is foolish.

There is no automatic premium for doing the work properly. The customer has to need the service, and you have to be capable of providing it. If the fee no longer supports that work, the scope or price needs another discussion. Calling the same work “strategic” does not resolve it.

The promise needs an ending

The engagement needs a named person who can accept the work against the agreed result, plus a way to handle a changed request.

In the reporting example, the customer might accept a download once it contains the agreed records and the access checks pass. Adding a different source of records changes that agreement. A failure to export the records already promised needs correcting; the new source needs a separate scope decision before work starts on it.

If the customer wants to add that source, agree who will check its records and what they will accept before quoting for the extra work.