Build Where the Workflow Already Lives
The default instinct is to build a destination with its own login and surface. For most workflows that is the wrong place to build. Embedding into the…
The default instinct when building a product is to build a destination: your own app, your own login, your own surface the customer has to come to. For most workflows, that is the wrong place to build. The customer already lives somewhere, inside a point-of-sale system, an ERP, a marketplace, a tool they open forty times a day. The product that embeds into that existing surface wins distribution that a standalone destination spends years and a marketing budget trying to buy. Distribution is not a channel you find after you build. It is a constraint you design for before you write the first line of code. Building a destination means signing up for a tax you pay forever. First you have to make the customer aware the destination exists. Then you have to convince them it is worth a new login and a new habit. Then you have to fight, every single day, to remain one of the handful of tabs they keep open, against every other product making the same demand. Most products never clear the first hurdle, and the ones that do spend the bulk of their capital on the second and third. The destination tax is the structural reason so many genuinely good products never find users. The product was fine. The distribution model asked the customer to change behavior, and behavior is the most expensive thing to change. Almost every business workflow already runs inside a system the customer opens by reflex. The merchant lives in the point-of-sale and commerce platform. The operations team lives in the ERP. The seller lives in the CRM. These surfaces have already won the habit war. They are open all day, and the customer's attention is already pointed at them. A product that installs into that surface inherits the habit instead of competing with it. You are not asking the customer to come to you. You are appearing inside the thing they are already looking at, at the moment they are already doing the work you improve. The dominant ecosystems are racing to build agent and integration layers for exactly this reason. They understand that the next wave of value attaches to whoever lives inside the workflow, and they would rather host that layer than cede it. For a builder, that race is an opening: the embedding surface is being actively built out, and the cost of meeting the customer where they already are has never been lower. The mistake is sequencing. Teams build the product first and then ask how they will distribute it, treating distribution as a downstream marketing problem. By then the most important distribution decision, where the product lives, has already been made by default, and it was made wrong. The teams that win decide where the customer already is before they decide what to build, and then they build into that surface deliberately. Distribution stops being a channel they go hunting for after launch and becomes a property of the product itself. There is a real tradeoff to name. Building into someone else's surface means accepting that surface's constraints, its review process, its revenue share, its platform risk. That is a legitimate cost. But for most workflows it is a smaller cost than the destination tax, paid in distribution you would otherwise never win. The discipline is choosing the surface with clear eyes, not avoiding the choice by defaulting to a destination. We make this call at the start of product and integration engagements: whether the right move is a destination or an embed, and which surface to build into if it is an embed. That choice is a distribution decision made before the architecture, because by the time the architecture is set the decision has already been made for you.