A surprisingly large amount of product complexity can begin with a sentence like this:

“We just need the customer to send one more field.”

One field sounds harmless.

I ran into this while working on a workflow where technical activity had to be connected to a business result.

We needed a small amount of context from the customer, and the obvious approach was to ask them to send everything required for the calculation.

Then we started looking at each field individually.

Did we really need the customer to send duration? No. We already had them.

Did we need them to tell us information that another connected system already knew? Again, probably not.

What remained was much smaller: information that genuinely belonged to the customer's business process and could not be derived safely elsewhere.

That exercise changed how I think about integration design.

A field is rarely just a field. Once it becomes part of a product contract, it needs documentation, validation, product support, backwards compatibility, troubleshooting, examples, UI treatment, and eventually an answer for what happens when the field is missing or wrong.

The implementation cost is only part of it. The customer also inherits another piece of information they must keep synchronized with the product.

This is especially easy to miss in developer products because we often reduce developer experience to lines of code. A two-line integration looks better than a ten-line integration, so we optimize the sample.

But I think there is a deeper measure of developer experience: how much knowledge does the customer have to maintain on behalf of the product?

An integration with three lines of code and six pieces of duplicated context may be worse than one with five lines that asks only for information the platform cannot obtain itself.

I now treat every new required field with a little suspicion.

Before adding it, I want to know where that information originates, who is authoritative for it, whether it can be derived reliably, and what happens when two systems disagree.

Sometimes explicit input is still the right answer. Derived data can be late or ambiguous. Inference can be wrong. The customer may genuinely be the only source of truth.

The principle is not “never ask.”

It is:

“Do not make the customer carry information the product already has.”

That sounds like a small UX decision.

Across a large product, it becomes an architectural one.