The most valuable thing we did on that project was delete most of it
A client asked for an automation system. Half of it was already a settings checkbox. Saying so cost us billable hours and won us the relationship.
An education client came to us with a clear brief: automate the handling of recorded classes. Start the recordings, file them into the right folders, manage the student lists, send reminder emails, handle admissions logic.
It was a decent-sized project. We quoted a much smaller one.
What was actually there
Working through the brief item by item, the list collapsed:
- Starting the recording automatically was a Google Workspace administrative setting. A checkbox. Not software.
- Students were already being added as calendar guests by their own team. Nothing to build.
- Admissions was handled elsewhere, by a process that worked. Touching it would have added risk for no benefit.
- Reminder emails were wanted, but nobody could say what should trigger them — a sign the requirement was not ready.
What remained was one genuine engineering problem: taking each finished recording and filing it into the correct batch folder, reliably, without supervision. That is what we built.
Write down what you are not building
We confirmed the reduced scope in writing before starting, and the project README opens by naming what it deliberately does not do — in the client's own words, not ours.
Explicit non-goals are the most reliable defence against scope creep, because they turn a future disagreement into a document somebody already agreed to.
Six weeks later, when a new team member asked why the system did not send reminders, the answer took ten seconds and involved no archaeology.
Why this is good business, not charity
The obvious objection is that we billed less. True, and it is worth being clear-eyed about the trade.
- 01A smaller project shipped on time. A larger one built on unready requirements would have slipped, and slipping is what damages a reputation.
- 02We did not take money for configuring a checkbox. Clients find that out eventually, and what they remember is that you charged them for it.
- 03The client now believes us when we say something is necessary — because they have seen us say the opposite.
That third point is the whole return. Trust is the only thing that makes the next, larger project possible, and the fastest way to build it is to argue against your own invoice once.
The question worth asking
Before quoting anything, go through the brief line by line and ask of each item: does this need code, or does it need a decision, a setting, or a conversation?