Need one small change made? How to get a developer to do it

One field on a form. One column on a report. One rule that fires the wrong email.

These are the jobs that sit undone for years, and the reason is almost never the work. It is that asking feels disproportionate: raising a four hundred pound problem through a process built for forty thousand pound projects, and suspecting that the asking will cost more than the fixing.

Here is how to get one small change made, what makes it cheap or expensive, and what to expect back.

Write it as an outcome, not an instruction#

This is the single thing that most changes the price you get back, and it costs you nothing.

Describe what should happen, not how to build it. "The Monday report should show the branch name next to each order" is a job anybody can price. "Add a column to the orders table and join it to branches" is a guess about the solution, made by somebody who cannot see the code, and a developer now has to work out what you actually wanted before they can start.

You know your business. They know the system. The division of labour works best in that order.

Say where, exactly#

Ambiguity is what turns a small job into a call.

Name the screen, the report, or the form. Paste the URL if there is one. A screenshot with an arrow on it removes more uncertainty than three paragraphs of description, and takes twenty seconds.

If it is a document or an export, attach the actual file, with real data if you can. A developer looking at your real spreadsheet will spot things you would never have thought to mention.

Say who it affects and how often#

Not because it changes the price, but because it changes how carefully the work is done.

"Two people use this once a month" and "every customer sees this at checkout" are the same change with very different amounts of testing behind them. A developer who does not know which one it is has to assume the second, and you pay for that assumption.

It also tells them what not to break, which is the most useful thing you can give somebody working in a system they did not write.

Say what it is costing you#

Optional, and worth including. "This takes somebody forty minutes every Monday" turns a vague annoyance into a case you can decide about, and it is the number you will want when you compare the quote to doing nothing.

It also quietly tells the supplier the job is real rather than a nice-to-have, which affects how quickly it gets looked at.

What makes a small change expensive#

Worth knowing so that a higher price than you expected reads as an explanation rather than a brush-off.

It touches money, tax, or personal data. The change is small and the testing around it is not, and that is the right way round.

There is nowhere safe to try it. If the only copy of the system is the live one, everything has to be done carefully rather than quickly. This is the most common reason a half-day job is not a half-day job.

Nothing is tested. Without automated tests, every change carries a risk of breaking something unrelated, and the only way to know is for a human to check by hand.

One piece of code does ten jobs. Systems that grew in a hurry often cannot be changed in one place, and a change that should be isolated is not.

Nobody knows what it currently does. If the behaviour is a mystery, the first work is understanding rather than changing. That is a separate, smaller job and it should be priced as one.

What you should expect in any of those cases is a plain-English explanation of which one applies. Not a refusal, and not a meeting.

What good looks like coming back#

A price, in writing, before anything starts. A sentence saying what will change and what will not. And an answer on when, even if the answer is "in about two weeks".

What should not come back is a discovery call, a proposal deck, or a request for a retainer. For a job of this size those consume more value than the change itself, and you will pay for them whether or not they appear as a line on the invoice.

A template you can paste#

Copy this, fill it in, and send it. It is the same information a developer would spend forty five minutes extracting from you on a call.

What should happen: [describe the outcome, not the method]

Where: [screen, report or form, with a URL or screenshot]

Who it affects: [how many people, how often]

What it currently costs us: [time per week, or the error it causes]

Anything attached: [the actual file or export]

How urgent: [genuinely, including "not at all"]

Six lines. In our experience that is enough to grade and price most small jobs without a single question coming back.

What we do#

There is no minimum. A half-day change is ordinary work here rather than a favour granted around the edges of something bigger.

You describe the job, it gets graded by size, and you get the price in writing before anything begins. Nothing starts until you approve it, and if the number is wrong for you, you walk away owing nothing. No discovery call, no proposal process, no account manager and no retainer to sign, which is precisely what makes a job this size possible at all.

The price changes with the size of the job. The standard never does.

If you have been sitting on something for months because it felt too small to raise, that is the work we would most like to see.