Building Got Cheap. Deciding What Belongs in the Product Did Not.

What actually changed

Understanding a bug is still hard. You reproduce it, read the transcripts, find the one conversation where behavior diverged, and work out whether the cause is the data, the configuration, or something the customer changed on their side last Tuesday without telling anyone. That has not gotten faster.

Understanding what a customer actually needs is harder still. People describe the solution they pictured rather than the problem they have, and getting to the real requirement takes conversations and the willingness to keep asking after the first answer sounds reasonable. No tool has touched that either.

What changed is everything downstream. Once you know what is wrong and what should exist instead, building it has become short.

I run the delivery group at Notch, and this has quietly rearranged what my group is for. The change is genuinely good, and it carries risks I do not think the industry is being honest enough about. Both halves are worth saying.

The authentication flow

One of the solution people on my team built a full authentication flow for a customer recently. Multi-step, with handling for the cases where it fails, and fallbacks for states nobody thinks about until production.

He is not a developer.

A year ago that request is a scoped ticket, a sprint, someone pulled off other work, a review, a release window. What made it possible was not a simpler authentication problem. He had been living with that account for months and knew exactly what was needed, down to the failure cases, because he had watched them happen. The expensive half of the work was done before he wrote anything.

That is the shape of the opportunity. The people who understand a customer's problem best are now the people who can build the answer to it. Capability moved to where the understanding already lives, which is the opposite of how software organizations have been arranged for twenty years.

What that opens up

The old math on a customer request was discouraging. A customer asks for something specific to how they operate. You estimate it. The estimate is expensive because it means a developer currently on something else. The request queues behind roadmap work or gets declined, and the reason given is effort.

Effort was never a good reason to say no. It was the loudest one, and it drowned out better questions. When the honest answer is that something would take a quarter, nobody gets as far as asking whether the thing should exist.

With that noise gone, more requests get a real examination. The conversation with a customer changes character, because we are weighing whether something is right for them over the next three years rather than whether it fits in a sprint. Sometimes the examination produces something different from what was asked for, smaller and better, because the real problem sat two steps earlier in their process. That conversation only happens when time has stopped being the first question.

None of which means a customer asks and we build. More requests get taken seriously. Not all of them get built.

What a request actually gets

Four questions, the same four every time.

Is this part of our strategy? Almost everything a customer asks for is useful to that customer, which makes usefulness a weak filter. The question is whether it sits on the road we already chose. Things that pull hard against that direction do not get built simply because they became cheap.

Can we sell it, or does the market need it? Something with exactly one buyer forever is a service, and we should call it that honestly. Something three other prospects would raise in a discovery call is a feature that arrived through the side door.

Is it generic enough? Some requests are shaped so tightly around one company's internal process that generalizing them costs more than building fresh later. Those stay contained, which is a legitimate outcome rather than a failure.

Is building it a good lab? Sometimes the first three answers are no and I still say yes, because doing it once with real data teaches us something we will use for years.

Nothing on that list is about how long it takes. That is the actual change, and it is worth more than the speed.

The risks, honestly

Now the other half, because the enthusiasm around this deserves a harder look than it usually gets.

Drift into several products. Enough independent customer-specific building and you stop having one product with variations. You have four that share a login screen. Each makes sense to whoever built it. Together they make sense to nobody, including the next person who has to change that area.

Erosion of the product line. There is a shape to how our product behaves, and that shape is a decision rather than an accident. No single customization breaks it. Twenty of them, each reasonable on its own, will. It erodes quietly enough that you notice from a customer's confused question rather than from anything internal.

The product is our business card. A customer meeting is not a place where anyone gets to explain that an odd screen was a one-off for a different account. Whatever is in the product is a statement about us.

Time spent on the wrong things. When building is cheap, people build, and that includes building for a request that made one stakeholder happy in one meeting and produced nothing afterward. Low execution cost makes it easier to spend real weeks on the wrong thing, not harder.

Understanding that leaves with the person. Something built quickly, by one person, for one account, tends to hold its full explanation in that one person's head. Six months later, when it misbehaves and they are on a different account, whoever picks it up is reading code nobody can quite account for.

The wider research says something similar in a broader frame. The most cited industry study on AI-assisted development found it acts mainly as an amplifier, magnifying an organization's existing strengths and its dysfunctions, with the deciding variable being the quality of the internal platform underneath. The same work found that higher adoption raised delivery throughput and delivery instability together. Speed and fragility arrived in the same box.

For a delivery group, I would put it more specifically. What gets amplified is your product architecture. Every seam your product already had, fast customer-specific building will find and widen.

Ownership helps, and is not enough

The first thing we did was structural. We split customers across the solution people and gave each one end-to-end ownership of their accounts, from the request through the build through what happens after go-live. The person who scoped it and built it is the person who hears about it at eight in the morning when it misbehaves.

That does real work against the risks above. When you build something you will personally answer for in six months, speed comes with an instinct for what you are going to regret. Nobody had to be taught that.

We paired it with triage in two layers. The first routes by customer, because judging urgency requires knowing what that account has riding on this week. The second routes by product area, because once something is established as a platform issue it belongs to whoever owns that surface. Collapsing them fails both ways. Route everything by customer and each account rebuilds the same fix alone. Route everything by product area and the person judging urgency has no idea what is at stake.

Today, on top of that, anything with customer visibility or behavioral impact still comes through me. I am a deliberate bottleneck at this stage and I do not defend it as an end state.

Because none of this scales. Ownership makes individual judgment better. Review makes my attention the safety mechanism. Neither one changes what happens to the product when the volume triples, and holding the volume down is not an acceptable answer when the entire point is that we can finally respond to customers properly.

The frame these initiatives need

What is missing is a product frame. A defined place where all of this work belongs, rather than a set of good decisions holding it together.

Right now, when someone builds something for one customer, it lands in the product. Not in a designated place for that kind of thing. Next to everything else, held apart by care and review rather than by structure.

What the product needs is a surface for add-ons, where a small application built for one account sits on top of the core product instead of inside it. Four properties, none optional.

In the product line. An add-on should look like it belongs and behave like the rest of the product. The person using it does not know which parts came from the roadmap and which were built for them last month, and should not have to.

Holding the standard by construction. Components that already behave correctly. Patterns that are the easy path rather than the disciplined one. If doing it right depends on remembering to do it right, then at volume it will not happen, and that is a design failure rather than a people failure.

Safe at its boundaries. An add-on should not be able to reach another customer's data, degrade shared performance, or become behavior everyone inherits. Isolation has to come from the surface, not from good judgment on a Thursday afternoon.

Governable. Visible in one place, attributable to a person and a reason, testable against one customer without touching the rest, and cleanly reversible. If we cannot answer what exists, why, and how to remove it, we do not have a platform, we have accumulated history.

Two supporting pieces make it real. Per-customer feature management, so enabling something for one account means knowing exactly what it touched and how to take it back, close to what we already practice with versioning agents in production. And isolated per-customer testing, because today proving a change helps one tenant and harms none of the others takes more effort than making the change itself.

There is one more decision the frame makes possible, and it is the one I find most interesting. Something built for a single account can stay there permanently, or be promoted into the product everyone gets. Those are very different commitments. Promotion means maintaining it, supporting it, and reasoning about it every time anyone touches that area again. Without a frame, that promotion happens by default and by accident. With one, it becomes a deliberate decision with evidence behind it, because the thing already ran with real customers and we can see what it actually did.

None of this is exotic. The multi-tenant architecture literature has argued for years that customization has to be a platform capability rather than a series of one-off accommodations. What is new is where the pressure comes from. It used to be enterprise sales demands landing on a roadmap. Now it is our own delivery people, building daily, on behalf of accounts they own.

What delivery is for now

The traditional shape of a delivery organization is that product builds and delivery deploys. You configure what exists, connect it to the customer's systems, go live, support it.

That is not what my group does. When capability sits at the edge and the pace is this high, delivery's job is to make sure the people at the edge have something solid underneath them. A connector library so integrations get picked rather than written. Prebuilt integrations for the systems these customers actually run. Processes that move fast because they are narrow rather than because anyone is cutting corners. And the add-on surface, which is what turns all the rest of it from a speed advantage into something durable. We wrote about a related version of this in scaling agents without turning them into a macro.

The industry's answer to this gap has mostly been headcount. Companies are hiring forward-deployed engineers to stand between a product and a messy customer environment, and postings for that role grew severalfold in the past year. It works, and it is a cost you pay again for every account. A frame is paid once.

So the deliverable of a delivery group now is not the customization. It is the place where a hundred customizations can happen without any of them becoming a problem for the other ninety-nine. My team is further along on the building and the ownership than I expected. The frame is mine to build.

‍