The Software Should Fit the Business

Why digital transformation begins with business architecture, not platform selection.

Most digital projects begin with the wrong question.

Which platform should we use? Shopify or Adobe Commerce? Salesforce or another CRM? SaaS or custom? Headless or monolithic? Build or buy?

Those are legitimate questions. They are simply not the first questions.

The first question is harder: what does this business actually need its digital systems to understand?

Because a website is only the visible surface of a business. Behind the storefront are customers, products, prices, markets, suppliers, production, inventory, sales, finance, logistics, content, data, and decisions. In a simple company, those relationships can remain simple. In a growing company, they become the architecture.

And once that happens, choosing software before understanding the business becomes backwards, the same reversal covered directly in most companies don't need a new website, they need a new structure. The technology begins dictating the business. The platform's workflows become the company's workflows. The vendor's data model becomes the company's data model. The vendor's limitations become operational limitations. Every exception becomes another integration, plugin, workaround, or custom development bill.

The most interesting digital transformations happen in the opposite direction. They begin by understanding the business so precisely that the technology becomes a consequence of that understanding.

WEBSITE NOT BUSINESS

A Website Is Not the Business

A customer sees a product page. The business sees something very different. It sees a product with attributes, a price, a market, a customer segment, a stock position, a supplier, perhaps a production process, a sales representative, a contract, a tax jurisdiction, a fulfillment path.

A B2C customer may move through product, cart, checkout, payment, delivery. A B2B customer may move through account, negotiated terms, catalog, quotation, approval, order, fulfillment, invoice. A dealer may follow another path entirely. The website is merely where some of those paths become visible.

At a certain scale, ecommerce becomes an interface into the operating system of the company, exactly the shift covered more broadly in digital architecture. And once it reaches that point, the real architectural questions are no longer visual. They become questions of ownership. Where does the product truth live. Who owns the customer record. Which system owns the price. Where does inventory become authoritative. Who owns the order. What belongs in the website, what belongs in the ERP, what belongs in the CRM, what should remain a commodity service, and what part of the system is important enough that the business should own it permanently.

That last question is the one most platform conversations never reach.

THE CRM TRAP SHTAYER

The CRM Trap, in Practice: How SHTAYER Outgrew Its Software

A surprising number of transformation projects begin with "we need a CRM." Sometimes they do. Sometimes "CRM" is simply the first name a business gives to a problem it has not yet fully mapped. Sometimes the clearest way to understand digital architecture is to watch a real business evolve over time.

One of our long-running projects, SHTAYER, whose own brand story is told in building a brand for a new generation, began in 2019 with a relatively simple digital requirement: an ecommerce store and a small landing presence for B2B customers. The immediate business problem was sales. The company needed to build a sales department, organize customer interactions, and create a more structured commercial process. The logical answer was a CRM. At that stage, it was the right one.

But software does not freeze a business at the moment it is implemented. The first CRM helped create a more structured sales environment, but the next problem quickly became visible: the sales funnel itself was not efficient enough. The company did not simply need a place to store leads. It needed a better way to qualify, manage, and move those leads through the business. The funnel was redesigned, and it worked, more qualified inquiries started coming through. That created another problem. The bottleneck moved.

Now the company had more demand to process, but processing an order was no longer just a sales activity. Materials had to be sourced. Products had to move through operational processes. Orders had to be coordinated. Customer information had to remain connected to products and transactions. Different countries, suppliers, materials, production, finance, and fulfillment all became part of the same operational picture. The business had solved one problem and exposed another, the same pattern behind every enterprise system started as someone's spreadsheet.

Every successful layer can reveal the next missing system.

Over the years, the company went through three different CRM systems. That progression was not caused by indecision. Each system was chosen because it addressed the business requirements that existed at that particular stage, and each was evaluated for how far it could be adapted as those requirements evolved. But eventually the problem stopped being which CRM should we use. It became why are we trying to represent the entire business inside a CRM.

That is the moment a CRM problem becomes an architecture problem. The business was no longer dealing only with customers and sales opportunities. It had increasingly interconnected objects and processes: customers, products, materials, suppliers, production, orders, pricing, markets, inventory, finance, and fulfillment. Some of these belong naturally to a CRM. Some do not. Once those relationships become sufficiently complex, adding another CRM feature or another integration does not necessarily simplify the system. It can simply move the complexity somewhere else.

The requirement had changed from a better CRM to a better model of the business, exactly the distinction covered more broadly in custom CRM vs ERP, and more practically in which CRM is right for your business. A CRM is designed to manage customer relationships. It is not automatically designed to understand how a particular company sources materials, manages products, coordinates production, handles orders across markets, or connects commercial activity to operational reality. At a certain point, the business needs more than a sales system. It needs a system that understands how the business itself works, and even calling that an ERP is incomplete, because the answer was never simply to add an ERP to the existing stack. The business had already evolved beyond the architecture it started with, so the digital platform itself had to evolve.

What began as ecommerce with a small B2B presence became a full digital commercial and operational environment: a complete B2B website, a substantial B2C ecommerce platform, a Laravel application layer, a custom ERP, and an administrative environment connected to the whole system. The ERP was not selected in isolation and forced onto the business. It was designed around the requirements the business discovered through years of actual operation, the relationships between materials and products, suppliers and orders, production and fulfillment, different markets and countries, customer relationships, commercial processes, and financial operations.

The custom ERP is not the beginning of the transformation. It is the consequence of it.

There was no reason to build a proprietary ERP at the beginning. A CRM was the appropriate answer to the problem that existed then. Later, a more capable CRM made sense. Later still, the business needed capabilities no longer naturally contained inside a CRM. The architecture changed because the business changed, which is a far more useful way to think about custom software: build when the business has become too specific, too interconnected, or too strategically important to be represented properly by generic software.

The customer places the order. The product has to exist. The material has to be available. The supplier has to deliver. The operation has to process it. The order has to move. The financial record has to exist. And the customer relationship has to remain intact. The software succeeds only when those realities can coexist inside one coherent architecture.

How SHTAYER's Architecture Actually Evolved

Businesses rarely outgrow a CRM because the CRM is too small. They outgrow it because the business has become larger than the problem the CRM was originally chosen to solve.

SHTAYER shows what happens when a business discovers its architecture through years of operational growth. Schoeffel presented the opposite challenge: what happens when a business has the opportunity to design that architecture deliberately, before the next generation of the business is built.

Two Paths to the Same Architecture

WHICH CRM TOO SMALL

Which CRM May Already Be Too Small a Question

We encountered the same underlying issue from another angle while studying the architecture for Schoeffel, a Bahrain pearl house, an engagement documented as it unfolded in building the next century, Peretz becomes strategic partner, and the first landing page going live. The initial request included CRM. So we did not start with Salesforce. We started by decomposing the business.

The analysis identified separate requirements for procurement and pearl lots, stock and orders, production, product attributes, media and documents, customer relationships, clienteling, pricing by market, and accounting. When those requirements were classified by system type, only one of the seven blocks was actually a CRM in the narrow sense. The others belonged to ERP, OMS, PLM, PIM/DAM, accounting, or a business-specific clienteling layer.

That changes the conversation completely. A software vendor can sell you a CRM. An architecture exercise asks a different question: which systems should exist, where should they live, and who should own the master record for each critical object?

That is a business architecture question. And it needs to be answered before the technology decision.

WE BENCHMARKED FIRST

We Benchmarked the Category Before Choosing the Architecture

For Schoeffel, we did not want to form an opinion based on a handful of familiar competitors, the same discipline covered more broadly in Product Discovery. We examined thirty brands in the primary sample, three additional brands to validate the structure, and one further reference brand. Across the primary sample, eighteen brands could be tied to a specific architecture, using technical fingerprints such as URL structure, metadata, CDN paths, payment methods, and localization formats, alongside a direct review of the customer journey and a recorded confidence level for each finding.

That produced a much more useful picture than a list of technology logos. Among the architectures we could identify were Salesforce Commerce Cloud, Adobe Commerce, Adobe Experience Manager, Shopify Plus, WooCommerce, Next.js with Contentful, and a fully proprietary platform. Sixteen of the eighteen identifiable implementations used SaaS or licensed PaaS, with a small number of brands standing out as examples where the digital experience itself had become a strategic asset in its own right.

That finding removed an easy argument. We could not honestly say luxury brands need custom software because SaaS cannot produce a sophisticated experience. The benchmark showed otherwise. Beautiful digital experiences can be built on Salesforce, on Adobe, on Shopify. The platform itself is not the differentiator. The important question is what happens after the first launch.

TWENTIETH CHANGE

The Twentieth Change Matters More Than the First Launch

A new website is easy to romanticize. Everything is new: the visual system, the product pages, the navigation, the technology. But the real test of an architecture happens later. The fifth market. The tenth campaign. The new dealer flow. The new product family. The new localization. The new pricing logic. The new configurator. The new customer journey. The integration nobody anticipated three years earlier. That is where architecture reveals itself, exactly the cost covered directly in the hidden cost of choosing the wrong architecture.

Our benchmark made this distinction explicit: beautiful storefronts can be created on many platforms, so the argument for owning a domain layer cannot be that SaaS cannot handle design. The meaningful divide is the economics of the next change, and what remains an asset of the brand afterward.

Not what can the platform launch, but what does every meaningful change cost, and who owns the capability after the change is made.

OWN VS RENT

Own What Differentiates. Rent What Is Commoditized

This became the central architectural principle. Not everything should be custom. Building everything yourself can be just as irrational as outsourcing everything to SaaS. Payments are a commodity. Anti-fraud is a commodity. Tax calculation can be a commodity. Shipping infrastructure can be a commodity. Infrastructure itself can often be rented. There is little strategic advantage in rebuilding what the market already solves well.

But what makes a business different is another matter. For a luxury pearl house, that might include the product model, the logic of pearl families, market-specific pricing, the way a customer discovers a product, collection logic, clienteling, or the relationship between editorial knowledge and the product itself, the same multi-market complexity covered in multi-country e-commerce for large catalogues, exactly the category-specific pressure covered in why luxury e-commerce breaks every rule of conversion optimization. Those are not interchangeable commodities.

Four Ways to Approach the Same Architecture Decision

The architecture developed for Schoeffel therefore separated these four approaches and arrived at a simple principle: own what differentiates the house, rent what is commoditized. That principle is bigger than one client. It is a useful way to think about digital architecture in almost any growing business, the same discipline covered from the buyer's side of a transaction in the build vs. buy equation.

OWNING THE SYSTEM

What Owning the Digital System Actually Means

For Schoeffel, the proposed architecture was deliberately split into layers. The domain core, built in Laravel, a choice covered on its own terms in Laravel vs Symfony, owns the product and pearl attributes, selection families, market-specific pricing, orders, customers, tax logic, and price-on-request rules. The storefront, in Next.js, controls the customer-facing experience, server rendering, modular content, storytelling navigation, and checkout. The administration environment, built with Vue through Inertia, keeps content, product data, selection parameters, and order operations close to the core. Commodity services, payments, PCI, taxes, shipping, email, and infrastructure, remain managed services that can be replaced when necessary.

Three critical layers belong to the brand. The commodity services do not. The result is not simply a Laravel website. It is a deliberate allocation of ownership, the same question covered more broadly in what you own vs what you're renting.

A technology stack is a list of tools. An architecture is a map of responsibility and ownership.

BUSINESS MODEL DETERMINES

The Business Model Determines the System

Consider two businesses. Both sell physical products online. It would be tempting to give them the same architecture. That would be a mistake. One may have complex materials, procurement, production, international suppliers, inventory, and both B2B and B2C sales. Another may have a network of dealers, multiple luxury markets, complex product-family relationships, different sales funnels, clienteling, and high-touch B2B and B2C interactions.

They both have ecommerce. They may both need CRM. They may both need ERP. But the reason they need those systems is different, and therefore the architecture should be different.

In the Schoeffel benchmark, the website was mapped against eight distinct areas: product and catalog, order and payment, boutique visits, clienteling, prices and markets, content and campaigns, procurement and warehouse, and accounting and reporting. The exercise did not assume everything belonged in the website. Procurement, warehouse, and accounting were explicitly separated into external systems. That boundary, what belongs in the digital product and what belongs elsewhere, is one of the hardest decisions in architecture, and one of the most consequential.

This becomes particularly important when a company sells both B2B and B2C. A consumer may need a beautiful product discovery experience, clear pricing, checkout, payment, fulfillment and post-purchase service. A business customer may need account structures, negotiated pricing, customer-specific catalogs, sales support, quotations, approvals, purchase orders, recurring orders, invoices, dealer logic, and a relationship that lasts years rather than minutes. Those are different commercial systems, not simply different templates, a distinction covered from the design side in Product Design vs UX/UI, the same distinction covered in more depth in when e-commerce becomes a business system. A common product model may make sense. A common inventory model may make sense. Customer identity may need to be unified. Pricing, checkout, sales workflow, and permissions may not be.

ECOMMERCE OPERATING SYSTEM

Ecommerce Becomes Part of the Operating System

There is a point at which an ecommerce platform stops being a sales channel and becomes part of the operational infrastructure, the exact question covered directly in what happens to e-commerce when a website stops being a website. At that point, a product page is connected to product information. Product information is connected to inventory. Inventory is connected to procurement. Procurement is connected to suppliers. Orders are connected to fulfillment. Customers are connected to CRM. Financial events are connected to accounting. Marketing activity is connected to customer behavior. And the website sits at the intersection of all of it.

The more interconnected the business becomes, the less sense it makes to evaluate the ecommerce platform independently.

ECONOMICS OF SOFTWARE

The Economics of Software Change as the Business Grows

Platform costs are not just license costs. There is implementation, integrations, apps, agency dependency, maintenance, migration, data transformations, and the cost of every unusual requirement that appears later.

In the Schoeffel benchmark, platform economics were modeled across five years and three revenue scenarios, with an important distinction: platform costs can be tied to revenue, while a proprietary core is primarily tied to the changes the business actually chooses to make. The deeper point is not that proprietary systems are always cheaper. They are not. The point is that the economics have different shapes. One model effectively says the more successful you become, the more the platform participates in the economics of that success, exactly the kind of dependency worth surfacing before an acquisition, covered in how to audit a digital product before you buy it. The other says you pay for the capability when you change the system, not simply because the business grew.

Which model makes sense depends on the business. But it should be a conscious architectural decision, not a default.

CUSTOM NOT AUTOMATICALLY BETTER

A Custom System Is Not Automatically a Better System

This is important enough to state explicitly. We do not believe custom software is inherently superior to SaaS. That would merely replace one dogma with another.

SaaS is excellent when the business process is standardized and the vendor solves that process better than the company could reasonably solve it itself. Custom software becomes interesting when the business contains capabilities that are too specific, too interconnected, or too strategically important to outsource to a generic product. A hybrid system is often even better: use SaaS where the market already provides a strong commodity solution, own the layers where the business is different, and integrate them deliberately.

The architecture should follow the economics and the operating model. Never the ideology.

BRANDS EXPLAIN BADLY

Most Brands Explain Themselves Badly

The technology benchmark was only one part of the Schoeffel research. The other was the customer and information layer. Across direct competitors, product facts, provenance, history and category knowledge were often buried inside beautiful editorial language rather than represented as structured, attributable facts. The information was effective for a human reader but poorly exposed for machine-readable discovery.

That matters now because search is changing. An assistant answering "what is an Akoya pearl" does not need another luxury homepage. It needs an authoritative explanation. A question about a brand needs a source that actually explains the brand. A question about provenance needs attributable facts. A question about a particular product needs structured product information.

Our benchmark's snapshot found that, for several real buyer questions about pearls, search and assistant-facing answers were dominated by institutions, guides, retailers, forums and third-party reviews. The pearl houses themselves were often absent, or appeared only because another source had described them. That creates an unusual opportunity. A company does not necessarily need to outspend a century-old competitor to become an authoritative source. It has to explain what it knows, the same gap covered from the translation side in multilingual AEO.

PLATFORM ANOTHER JOB

The Digital Platform Now Has Another Job

This is where architecture becomes even more interesting. The platform should not only sell. It should know. It should connect brand, product, attributes, provenance, author, content, market, and customer, and expose that information consistently to humans, search engines, and AI systems. That requires control over templates, control over structured data, control over localization, coherent entity naming, and content and product data sharing the same underlying model.

In the Schoeffel architecture, SEO, AEO, GEO and E-E-A-T are therefore not marketing decorations added after development. Structured data, product and organization markup, machine-readable answers, authorship, provenance, localization and hreflang sit inside the architecture itself, the same layered thinking behind SEO gets you found, AEO gets you recommended, your commerce infrastructure gets you bought.

The category already has live chat, WhatsApp, and human specialists. But those are not the same as an assistant that understands the actual product. The architecture developed for Schoeffel treats a future assistant not as a widget pasted onto the site, but as a function of the underlying domain model. The assistant should be able to read product attributes, understand availability, explain selection logic, answer in multiple languages, know when to hand the conversation to a human, and refuse to invent price or availability when the underlying system does not contain the information, exactly the distinction between real capability and surface claim covered in the AI wrapper problem.

A chatbot can sit on top of a website. A useful business assistant has to sit on top of business knowledge. And business knowledge has to exist somewhere first.

PLATFORM NOT THE ASSET

The Platform Is Not the Asset

Saas platforms are extraordinarily capable, which is precisely why so many major brands use them: Salesforce Commerce Cloud, Adobe Commerce, Adobe Experience Manager, Shopify Plus can all produce exceptional experiences, our benchmark demonstrated that clearly. So the question cannot simply be which platform is strongest. The more important question is which parts of the digital experience should become an asset of the business itself.

That distinction becomes especially clear in an example the benchmark surfaced elsewhere in the category, a brand that moved toward a platform where the experience is assembled dynamically around visitor intent rather than presenting a fixed set of pages, turning the digital experience itself into something the company develops as intellectual property, a technology one of the major platform vendors later invested in directly. That is not an argument against using a major platform. It is an argument for ownership of differentiation. The vendor relationship can remain valuable. The strategic layer does not have to belong entirely to the vendor, exactly the ownership logic that ends up reflected in why tech companies get valued on different math.

IMPLEMENTATION NOT ARCHITECTURE

Implementation Is Not Architecture

An implementation project asks how to configure this platform. Architecture asks what should exist, why it should exist, where it should live, and who should own it. Implementation starts with software. Architecture starts with reality. Implementation asks how to connect systems. Architecture decides whether those systems should be separate in the first place. Implementation optimizes a solution. Architecture determines what the solution is.

That is why the most important work on a digital project may happen before the first line of production code is written. Technology is not the difficult part, there are excellent tools for almost everything. The difficult part is deciding what the business actually is: where one process ends and another begins, which data is authoritative, which workflow is strategically important, which capabilities are interchangeable, which dependencies are dangerous, which systems should be replaceable, and which should become permanent assets. What happens when the company enters another country. What happens when it adds B2B. What happens when B2C grows. What happens when the sales funnel changes. What happens when the product catalog becomes more complex. What happens when the company needs another ERP. What happens when AI becomes part of the customer journey. None of those questions are answered by choosing Shopify, Salesforce, Adobe, or Laravel. They are answered by understanding the business.

The highest-value digital project is therefore not a website redesign, an ERP implementation, a CRM migration, or even an ecommerce rebuild. It is the design of a digital model of the company, one in which customers have relationships, products have structure, prices have rules, orders have lifecycles, materials have provenance, markets have logic, operations have workflows, systems have responsibilities, and the business owns the layers that make it different. Sometimes that model will be mostly SaaS. Sometimes mostly custom. Often it will be hybrid. What matters is whether the architecture follows the business, not the other way around.

The next system should not be chosen from a vendor list. It should be derived, from the business model, from the customer journey, from the product model, from the operational lifecycle, from the data, from the markets, from the economics, from the parts of the business that create differentiation. That is how an ecommerce project becomes a business system. That is how a CRM question becomes an architecture question. That is how an ERP becomes more than accounting software. That is how custom software becomes an asset rather than an expensive experiment.

Not putting a modern website on top of an old business. Building a digital system capable of representing the business as it actually works, and giving it enough ownership to keep evolving. That is the difference between buying software and designing an operating model.

Design the business digitally first. Then choose the technology that deserves to carry it.

The Peretz Ownership Architecture Principle

Understand the business. Map the processes. Define ownership. Choose the systems. Own what differentiates. Rent what is commoditized. Connect what must work together. And build only what the business actually needs to own.

Why shouldn't a business start a digital project by choosing a platform?

Because the platform decision only makes sense once the business itself is understood: what data is authoritative, which processes are strategically important, and which parts of the operation are unique versus interchangeable. Choosing the platform first tends to let the vendor's workflows and data model quietly become the business's own, rather than the other way around.

Does needing a CRM automatically mean a business should buy CRM software?

Not necessarily. "CRM" is often the first name a business gives to a problem it hasn't fully mapped yet. Once customers, products, materials, suppliers, production, and financial processes are all involved, a CRM may only address one piece of a larger system that could actually need an ERP, a PIM, an OMS, custom software, or some combination, decided by what each part of the business actually requires.

Is custom software always a better choice than SaaS?

No. SaaS is often the right choice when a business process is standardized and a vendor already solves it well. Custom development becomes worthwhile specifically when a capability is too specific, too interconnected, or too strategically important to outsource to a generic product. A hybrid approach, SaaS for commodity functions and ownership for differentiating ones, is frequently the strongest answer.

What does "owning" a digital system actually mean in practice?

It means a deliberate allocation of responsibility: which layers of the system, the domain model, the customer experience, the administrative logic, belong to the business itself, and which functions, like payments, tax, or infrastructure, are better treated as replaceable, commoditized services. Ownership is a map of responsibility, not simply a choice of technology stack.

Why does structured, machine-readable content matter for a business's digital architecture?

Because search and AI assistants increasingly need attributable, structured facts rather than well-written editorial prose alone to represent a brand accurately. When product facts, provenance, and category knowledge exist only as narrative content, a business risks becoming invisible to the exact systems that customers increasingly use to ask questions and get answers about that category.