Real domain model signs you can hear on implementation calls

The problem shows up in setup calls

A product demo hides a lot. The happy path looks clean, the screens look tidy, and every step seems obvious. Then the first real setup call starts, and the team hears the rules that actually run the customer's work.

That is where the domain model shows up. People stop talking in marketing language and start saying things like, "we approve these orders in two steps if the buyer is a reseller," or "this account needs a parent company because billing is separate from usage." Those details are not decoration. They are the product.

Live onboarding is different from a demo because the customer is trying to get actual work done. They bring old habits, internal approvals, exceptions, and messy data. A sales demo can skip all that. An implementation call cannot.

Listen for repeated phrases: "special case," "only for this customer," "we handle that manually," and "this team does it differently." One comment might be noise. The same comment across three calls usually means your model is too thin.

Teams often react too fast and add another field, another toggle, or another screen. That feels practical for a week. After a few rounds, the UI starts to look like a storage room full of one-off fixes. New users get lost, support tickets go up, and nobody can explain why some settings exist.

A better move is to listen longer before building. Write down the exact words customers use. Check which exceptions repeat across accounts. Ask what triggers the difference, who owns the decision, and what happens if the step is skipped. Those answers often point to a missing concept in the product, not a missing button.

A simple example: if several customers ask for separate approval flows by location, department, or contract type, you may not need three custom screens. You may need a clearer rules layer in the product. Setup calls reveal that early if the team pays attention.

When a product architecture review starts from those calls instead of mockups, the product often gets simpler, not bigger.

Phrases that point to a weak model

A weak model hides in ordinary project talk. On implementation calls, nobody says, "our product structure is off." They say, "this is a special case," or "we only do this for one customer." Once or twice, that is normal. When the same line keeps coming up, the product is bending around something it does not model well.

Another clue is workaround language that repeats across different accounts. The team says, "we built a temporary step for Client A," then repeats almost the same step for Client B and Client C. If the workaround keeps returning, it is not a one-off anymore. It is part of the business, just without a proper name in the product.

You hear it in requests like "can we hide this for everyone except them," "we track that outside the system," "their process is different, but only a little," and "for this customer only, can we add one more status?" Another question matters even more: "who owns this rule, us or the client?"

When users stop and ask who owns a rule, they are often pointing at a hole in the model. A product should make it clear whether a rule belongs to the customer account, an internal team, a contract type, or a user role. If nobody can answer in one sentence, the product probably mixes rules together.

Renaming is another warning sign. One account says "branch," another says "property," another says "site," and the team keeps creating custom fields instead of asking whether all three mean the same thing. In many SaaS products, they do.

A solid domain model gives those ideas stable names and clear boundaries. It cuts down on special case requests because people can fit their work into existing parts of the product. If every call creates a new term, new exception, or new screen request, the product is learning too late and in the most expensive place possible.

What a real model sounds like

A real domain model sounds boring in the best way. People use the same words again and again because they mean the same thing to everyone.

If sales says "account," support says "account" too. Product does not quietly call it a "workspace" on one screen and a "client" on another. That kind of steady language is a strong signal that the product matches a real business object, not just a set of forms.

The same applies to actions and states. A request gets created, reviewed, approved, and closed. Teams do not rename the same step depending on who is talking or which page they are on.

You also hear rules stated once, in plain language. Someone says, "An invoice can be edited until it is posted," and that rule holds everywhere. The screen does not create the rule. The rule shapes the screen.

When rules live in one place, teams can add a report, API, or admin view without arguing about what should happen. They already know. The product has one source of truth, even if the code sits in several places.

Exceptions still exist, but they stay small and easy to explain. A team might say, "This customer needs a separate approval step because their finance team works by region." That is clear. It has a reason, a limit, and a name.

Weak products sound different. People stack one exception on top of another until nobody can tell what the normal flow is. After a while, every request starts to sound customer-specific, even when several customers asked for the same thing.

The clearest sign is simple: support, sales, and product tell the same story when a customer asks how the process works. They may use different levels of detail, but the nouns and rules still match. On implementation calls, that kind of consistency usually means the product can grow without adding another screen for every awkward request.

How to review calls step by step

Start with raw material, not opinions. Pull notes and recordings from sales, onboarding, and support for the same stretch of time. One call can mislead you. A small stack of recent calls usually tells the truth.

The first pass should stay simple. Write down repeated nouns such as account, location, contract, approver, seat, or project. Mark the actions people take, like submit, review, assign, renew, or export. Note every approval step and who owns it. Tag exception phrases like "special case" or "for this customer only."

Then merge similar exceptions when they point to the same business rule. This matters more than most teams think. People often describe the same rule with different words. One customer says "manager approval." Another says "team lead sign-off." A third says "ops review before launch." If the step does the same job, treat it as one rule until evidence proves otherwise.

Next, test your draft against three recent customer setups. Do not pick the easiest three. Pick one normal account, one account that felt messy, and one account that asked for custom work. Then ask a blunt question: can the same nouns, actions, and approval steps explain all three without inventing new objects every time?

If the answer is no, keep refining the model. If the answer is "almost," you may be close. Three customers may seem different until you notice they all need a gated release, just at different points in the process. That usually means your model needs a flexible approval stage, not another screen.

Pause UI work while you do this. New screens make weak thinking look finished. Once a team builds around the wrong objects, cleanup gets slow and expensive. If the pattern is still fuzzy after reviewing recent calls, keep the notes open, keep grouping requests, and wait. A week of patience can save months of product cleanup.

Decide if the request is custom or common

When a customer asks for a new screen, pause before you build it. The request may point to a real business rule, or it may describe one team's habit, reporting style, or pricing tier.

That distinction matters. If you treat every request as product structure, the product turns into a pile of exceptions. If you dismiss every request as custom work, you miss the moments when a real model is trying to surface.

Start with a simple question: does this change a rule, or only a preference? A rule affects how the business works. A preference affects how one customer wants to see or enter the same data.

A hospital that must store a second approval before discharge has a rule. A customer who wants the approval box on the left side of the screen has a preference. Both matter, but they do not belong in the product in the same way.

A short test helps. Ask what breaks if the product keeps working as it does now. Check whether the request changes business logic instead of layout or wording. Look for a second customer who asked for the same thing. Also ask whether sales packaged this as a paid exception instead of a product gap.

That last point saves a lot of mess. Teams often mix pricing with structure. A feature can be premium and still be part of the core model. It can also be expensive custom work and still be a bad fit for the product.

Two customers asking for the same thing is a strong signal, but only if the requests come from separate contexts. If both customers copied the same internal process from the same market, you may still be looking at a narrow case. If customers in different industries describe the same missing concept in different words, pay close attention.

Custom fields deserve extra suspicion. They look cheap, so teams use them to avoid harder product decisions. But a custom field often hides a missing concept. If customers keep creating fields like "approval type," "service window," or "site category," the product may need a proper object, status, or rule set instead.

This is also where outside review helps. During architecture work, Oleg Sotnikov often pushes teams to name the concept first and decide on the screen later. That habit keeps customer-specific workflows from leaking into every part of the UI.

A simple example from a SaaS rollout

A purchasing SaaS rolled out to two customers can hide the pattern in plain sight. Customer A has a simple rule: a team lead approves any request over $2,000, and finance approves anything over $10,000.

Customer B sounds similar on the first call. Their team lead and finance do the same job, but they add one extra step when the purchase touches regulated materials. A compliance manager wants to review those requests before finance signs off.

Many teams react the same way. They add a toggle in the admin panel called "extra review for this customer only" and move on.

That feels fast, but it usually creates a mess. The toggle hides the real rule: some purchases need an extra approval step when certain conditions apply. The condition might be product type, amount, region, vendor, or account type. Once you name it that way, it stops looking like a special case.

A few weeks later, Customer C asks for legal review on contracts above a threshold. Then Customer D wants security review when a new software vendor enters the system. Each request sounds different on the call, yet the shape is the same. Someone wants an extra approver when a rule matches.

This is where implementation calls tell you whether you have a real model. If your team keeps saying "we can hardcode that" or "we already have a customer toggle," the product probably models screens, not decisions.

A better fix is to turn approvals into a shared workflow object. Instead of one setting per customer, the product stores approval stages and the rules that trigger them. That object needs a few basic parts: who reviews the request, when that review starts, what conditions trigger it, and what happens if someone rejects it.

Now Customer A and Customer B use the same structure. One has two stages. The other has three because a rule adds compliance review.

That change also makes future requests easier to judge. If a new customer asks for another review step, the team can ask, "Is this just another approval rule?" Often the answer is yes. A product architecture review often starts with that simple question because it tells you when a one-off toggle is hiding a common workflow.

Mistakes teams make when they hear exceptions

Teams often treat every exception like proof that the product needs one more screen. That feels responsive in the moment. It usually makes the product harder to set up, harder to explain, and less consistent for the next customer.

The first mistake is simple: the loudest request wins. A buyer says, "Our team needs a separate approval path for just this case," and the team builds it fast. A month later, another customer asks for a different edge case, so another screen appears. After a few cycles, the product has a pile of one-off flows and no clear shape.

A strong model gets weaker every time the team adds UI before naming the rule underneath it. If the rule is real, it should live in the product as a rule. If it only lives in a kickoff doc, a support note, or one project manager's memory, the team has not solved anything. They have only moved the problem out of sight.

Another common mistake shows up with large deals. A company with a big contract asks for custom steps, custom labels, and custom exceptions. The team says yes because the revenue is hard to ignore. Soon the product reflects one customer's org chart instead of the shared pattern across the market.

That is how teams end up with settings that read like apology notes. A toggle exists because someone could not fit the workflow into the current model. A label changes because the underlying object means different things to different customers. The interface looks flexible, but the structure underneath is confused.

A small SaaS team might start with accounts, users, and approvals. Then one enterprise customer wants "regional reviewers" with a separate override path. Instead of asking whether this is just another approval role with a condition, the team adds a new page called Regional Review. Six months later they add Global Review, Partner Review, and Emergency Review. The names change, but the rule is still the same kind of thing.

Good teams slow down when they hear exceptions more than once. They ask whether the request reveals a missing concept, a missing rule, or a true one-off. If they skip that pause, they keep painting over broken structure with more screens and more toggles.

Quick checks before you add more screens

Extra screens often hide a model problem. A team hears three odd requests, adds three UI patches, and feels busy. Six weeks later, onboarding takes longer, support needs more hand-holding, and nobody can explain why one customer sees fields that another customer never uses.

Pause before you build. Listen to two recent setup calls and ask whether the product already has stable nouns and stable rules.

Say the main objects out loud in plain words. If the team cannot agree on names like account, contract, location, approval, or task, the product probably does not have a clear shape yet.

Compare two customer setups. If both customers follow the same base flow with only small differences in timing, labels, or access, you may not need a new screen at all.

Ask support to explain the rule without product stepping in. If support says "it depends" three times and then asks product to clarify, the logic likely lives in people's heads instead of the product.

Test the new request against existing rules. If it fits the same approval logic, ownership model, or billing rule with one extra condition, extend the model first and touch the UI later.

Then look at your last three workarounds together. If one cleaner model would absorb all three, stop patching around the edges.

A real domain model sounds boring in the best way. People use the same words on calls. They describe the same flow for different customers. Exceptions still exist, but the team can place them inside a known structure instead of inventing a side path every time.

One simple test helps a lot: remove the customer name from the request. Then read it again. If the request still makes sense as a rule, it may belong in the product. If it only makes sense with "for this customer only," treat it as a service choice, not a product feature.

Teams that do this early save a lot of cleanup later. They add fewer screens, support learns faster, and product decisions get easier because the product has one shape instead of a pile of exceptions.

Next steps for your team

Start with one phrase your team kept repeating last month. Good candidates are "special case," "manual workaround," or "this customer needs it different." Pick one, then trace where it shows up in sales notes, setup calls, support tickets, and the product itself.

That small audit often tells you more than another planning meeting. If the same phrase appears in three places, you probably do not have a screen problem. You have a modeling problem.

Write the messy area in plain language first. Turn the nouns into objects, the verbs into actions, and the limits and exceptions into rules. Then check which rules apply to many customers and which belong to one contract.

This forces the team to name the work instead of patching around it. A "discount approval flow" may sound like one feature, but the model may really include account types, approval levels, expiry rules, and region limits. Once those pieces are clear, the model usually gets simpler, and the number of screens often drops instead of growing.

Do not review that draft in a product-only meeting. Put product, sales, and support in the same room. Sales hears what customers ask for. Support sees where people get stuck. Product knows where the current design bends and breaks. If those groups use different words for the same thing, fix the language before you touch the interface.

Keep the review tight. One messy flow is enough for one session. Forty focused minutes beats a long debate about ten edge cases.

If the pattern still feels muddy, get an outside review before you add more UI work. Oleg Sotnikov at oleg.is is a sensible choice for that kind of review because his work spans product architecture, startup systems, Fractional CTO support, and AI-first software teams. One blunt review now can save months of extra screens, one-off rules, and support pain later.