Build the Engine Once, Paint the Experiences Many Times

Published 2015-02-24 · Updated 2026-06-23 · By Alan Wizemann

Topics: Platform Architecture, Product Strategy & Development, Team Building & Culture, Mobile Development

We say we want one Target experience, the same guest with the same capabilities whether they happen to be on a desktop, a phone, a tablet, or whatever screen shows up next year. It sounds like a design goal, and everyone in the room nods along, because who in their right mind would argue with it. The reason we do not actually have it yet, though, has almost nothing to do with design. It has to do with how our teams are wired underneath, which is a much less comfortable thing to talk about on a slide.

Here is the shape of the problem as I see it. Today our desktop teams are aligned vertically to a module-based web stack, which means a team owns a chunk of the website top to bottom and front to back, and that arrangement worked perfectly well back when the website simply was the product. But it also means that the logic for something genuinely fundamental, what a price is, what is in the cart, how search behaves, lives tangled up inside a specific web module that was built for that one surface and no other. When the apps need the same capability, they cannot simply reach over and use it; they rebuild a version of it, and then the next channel rebuilds it again, and the domain logic, the actual engine of the business, ends up being an afterthought, scattered and duplicated across every experience that happens to need it.

You can see the symptom clearly in how hard cross-team experiences are to actually execute. Anything that has to work consistently across web and apps turns into a long negotiation between teams that each own their own slightly different version of the same idea. Everybody is reimplementing pricing, everybody is reimplementing the cart, and we are paying for the same engine over and over while getting a subtly different one each time we pay. The fix, stated plainly, is to turn the architecture inside out: build the engine once, and paint the experiences many times on top of it.

In practice that means a services-first approach, where the domain services (search, browse, cart, pricing and promotion, the enterprise capabilities) get pulled out of any single front end and built to stand on their own, as one canonical version of each. Those services then power everything, the web and every app and any future digital channel we have not even built yet, and the front-end experiences become exactly that, experiences. They are the paint. They render the capability for a particular screen and a particular context, but they do not own the logic sitting underneath them, because that logic now lives in the service, in one place, defined once and only once.

This is as much an org change as a technical one, and that, in my experience, is the part people consistently underestimate. You cannot get a services-first architecture out of teams that are structured around web modules, because the structure quietly produces the architecture – Conway's old observation still holds, and you really do ship your org chart whether you mean to or not. So the org has to move first, or at the very least move alongside the technical work. In the interim, current and upcoming work has to start decoupling the front end from the services as a matter of plain discipline, even on the days when doing it the right way is slower than doing it the old way. And we need a team that does not exist today, one focused purely on UI standards and interactions, so that all the painting stays coherent across surfaces instead of slowly drifting into a dozen different dialects nobody chose on purpose.

Where this lands, in its mature state, is two kinds of teams instead of a tall stack of vertical ones. One collective services team powering all of the digital channels and responsible for the engine, and then a set of experience teams, organized around familiar capabilities, that drive the UI work on top, with the UI standards team keeping all of them consistent. The guest gets one Target, and the teams get to specialize in the thing they are actually good at, rather than each one carrying a full vertical slice and quietly reinventing the parts in the middle for the third or fourth time.

I want to be honest that the interim is the hard part, and it is exactly where efforts like this usually go to die. For a while you are carrying both models at once, because the old vertical modules still have to run the business while you extract the services out from underneath them, and it is genuinely slower before it is faster. There is a real stretch where a reasonable person can look at the whole thing and ask, not unfairly, why we are spending all this effort to rebuild something that already works. The answer is that "already works" is hiding the cost from you – the duplication tax is absolutely real, it is just spread thinly across every team so that nobody ever sees the whole bill in one place. Centralize the engine and the bill finally shows up, this time as savings, everywhere at once.

The payoff is what makes adaptive even possible in the first place. Once the capabilities live in shared services, supporting a new screen stops being a rebuild and starts being a new coat of paint, so a watch, a new device form factor, an in-store surface, whatever happens to arrive next, you are rendering existing capabilities in a new context rather than re-implementing the entire business from scratch yet again. The thing that takes a year today should take a fraction of that, because the hard part, the engine, is already built and, just as importantly, already correct. So when someone frames "one experience across every device" as a design project, I push back, gently but firmly, because design is downstream of all of this. The real work is structural: pull the engine out of the front end, build each capability once, and reorganize the teams around that split so the structure stops fighting the goal we all keep nodding at. Build the engine once. Paint the experiences as many times as our guests have screens.