Autoweb: The “Impossible” integration built in three days

The acquisition hinged on more than the price

After acquiring CarSmart, Autobytel was weighing another strategically important deal: buying its rival marketplace, AutoWeb. The rationale was strong. Combining the businesses would expand Autobytel’s audience, customer relationships, technology, and market presence.

But the economics depended on integration. Running two large websites on separate platforms, separate hosting, and separate development models would keep most of the cost and complexity of operating two independent companies. To make the deal pencil out, Autobytel had to show that the AutoWeb experience could move onto shared infrastructure supported by one development organization.

The catch was timing. We had less than a week before a critical meeting with AutoWeb’s executives, and an upcoming General Motors trial partnership was expected to freeze significant changes to the Autobytel site for six months. That left a narrow window to prove integration was even possible. Most stakeholders thought the deadline was fantasy.

Reframing the challenge

The immediate question was “how do we move the AutoWeb website onto Autobytel’s platform?” But that framed the job as a one-time migration. The better question: how do we build a shared digital foundation that supports multiple brands without forcing them to look or behave like the same company?

That distinction changed the solution. Copying AutoWeb’s pages into Autobytel’s existing site would have produced a fragile pile of exceptions, custom code, and brand-specific workarounds. We needed to separate what should be shared from what needed to stay distinct.

The shared system would own the parts customers never see: core functionality, hosting, data, application logic, reusable components, and maintenance. Each customer-facing experience would independently control the parts customers do see: brand identity, visual design, content, navigation, messaging, and partner requirements. The goal wasn’t to erase the differences between Autobytel and AutoWeb. It was to preserve those differences without duplicating the entire operating system beneath them.

Building adaptability into the architecture

We built a modular web framework that split branding and content presentation from the underlying domain and application infrastructure. Instead of constructing each website as its own product, the framework let multiple experiences draw from one technical foundation, with brand-specific rules deciding how shared functionality appeared to the customer. The same system could support Autobytel, AutoWeb, CarSmart, white-label partners, co-branded programs, and whatever brands got acquired next.

That gave us a kind of architectural adaptability. The organization no longer had to choose between total standardization and expensive duplication. It could standardize the components customers don’t see while adapting the ones that shape their experience. The principle fit on a bumper sticker: centralize the engine, adapt the experience.

The three-day proof of concept

A framework diagram wasn’t going to move AutoWeb’s executives. They needed to see the idea work without damaging the brand they’d built. So we used the new framework to reconstruct the AutoWeb customer experience on Autobytel’s integrated platform, and finished in three days.

The result reproduced AutoWeb’s look and feel closely enough to pass for the real site — while running entirely inside the shared framework underneath. That gap between the surface and the plumbing was the whole point. To the customer, AutoWeb could stay AutoWeb. To the combined company, it could become part of a leaner, more flexible operating model. Consolidation didn’t require erasing the acquired company’s identity.

Replacing debate with evidence

The meeting with AutoWeb’s leadership hit its critical moment when the executives questioned whether our theming and shared-platform approach could really reproduce the AutoWeb experience.

Rather than keep explaining the architecture, I showed them the prototype. At first they thought they were looking at their own website. Then we told them it had been rebuilt on Autobytel’s infrastructure using the new framework. The effect was immediate: an abstract technical claim turned into something they could see with their own eyes. The conversation shifted from whether integration was possible to what the combined organization could do with the capability.

By the end of the demo, AutoWeb’s leadership backed the approach and the agreement moved forward. Autobytel and AutoWeb announced their merger agreement on April 11, 2001.

More than a faster migration

The immediate win was reproducing the AutoWeb experience quickly. The bigger win was a new organizational capability. The framework let Autobytel absorb brands, launch partner experiences, and support different identities without rebuilding the underlying platform every time — which changed the economics of future growth.

Without a shared framework, every new brand or partner could demand its own codebase, extra hosting, dedicated support, duplicated functionality, parallel maintenance, and longer launch cycles. With it, the company could reuse its foundation and adapt only the presentation and experience around each brand. That lowered the cost of variation. Every new opportunity stopped being a unique technology project and became a configurable extension of a system that already existed.

The adaptive marketing lessons

The AutoWeb integration illustrates several principles at the center of The Adaptive CMO.

Adaptability has to live beneath the campaign layer. Companies love to call marketing adaptive because they swap messages, audiences, or media spend. But those changes depend on the systems underneath. When every new experience takes months of development or its own stack, marketing can only adapt within narrow limits. The AutoWeb framework widened what the organization could actually change, making brand presentation flexible while keeping the technical foundation stable.

Fix the recurring constraint, not just today’s problem. We could have treated AutoWeb as a single migration and solved the acquisition requirement while saddling ourselves with yet another custom platform to maintain. Instead we built a capability that could handle AutoWeb, other acquired properties, partnerships, and future white-label experiences. Adaptive leaders ask what system would solve this problem and make the next similar one easier.

Modularity creates options. A rigid platform forces big, irreversible choices. A modular one creates alternatives — preserve an acquired brand, consolidate it gradually, launch a co-branded experience, offer a white-label version, share select components, or change the customer-facing identity without replacing the system. The architecture didn’t lock in one strategy. It let us pick among several as conditions changed.

Speed is usually an architectural outcome. The prototype took three days, but the lesson isn’t “work faster under pressure.” Speed came from restructuring the work. Once presentation, content, and brand rules were separated from core functionality, the team could reproduce a new experience without rebuilding the whole product. Sustainable speed doesn’t come from repeated heroics. It comes from designing systems that make the work easy to repeat.

A prototype can resolve strategic uncertainty. The AutoWeb executives didn’t need a longer presentation. They needed proof the integration could preserve the experience their customers already knew, and the prototype answered that directly, reducing uncertainty for both sides of the deal. A good prototype does more than show technical competence. It helps an organization make a decision.

Preserve what customers value; change what they don’t see. Integration projects usually start with internal efficiency, which tempts companies to standardize in places where differentiation still matters to customers. Our framework let Autobytel consolidate infrastructure without making the AutoWeb brand disappear — standardizing the invisible layer while protecting the visible identity.

Technology decisions can decide strategic feasibility. This acquisition wasn’t only a financial and legal transaction; its viability depended on whether the combined company could operate efficiently. By cutting the technical and operational burden of supporting multiple brands, the framework made the business strategy more achievable. Marketing technology gets treated as a downstream implementation detail. Here it helped determine whether a corporate deal could succeed at all.

Demonstration beats argument. The starting assumption was that integration couldn’t be done in the time available, and arguing the point would only have generated more argument. The working experience changed the discussion because people could see the result themselves. Adaptive leaders don’t always need to win with greater certainty. Sometimes they design the smallest credible experiment and let the evidence do the persuading.

Build for reuse without forcing uniformity. Standardization lowers cost but, taken too far, weakens relevance. Customization improves relevance but, left unlimited, creates cost and complexity. The framework found the middle path: shared infrastructure, reusable functionality, configurable experiences, distinct customer-facing brands. Reuse what should be common; adapt what creates real differentiation.

The lasting lesson

The AutoWeb initiative began as an urgent integration problem and became a case study in how flexible systems expand strategic possibility. By separating the customer-facing brand from the underlying infrastructure, we built a platform that could consolidate operations without cramming every experience into a single identity.

The three-day prototype did more than prove AutoWeb could be migrated. It showed that Autobytel could become easier to extend, integrate, and adapt. That helped move the acquisition forward, but its value outlasted the transaction — a foundation for managing multiple brands and partnerships with more speed and less complexity.

That’s what adaptive infrastructure does. It doesn’t try to predict every future requirement. It gives the organization more ways to respond when the next one shows up.

 

Build Marketing That Learns Across the Entire Customer Journey

This is an example of the operating principles explored in my book, The Adaptive CMO: The Secret to Revenue, Relevance, and Results.

The book provides a practical framework for recognizing customer signals, designing measurable experiments, connecting marketing activity to revenue, and building programs that get smarter while they run.

Explore The Adaptive CMO