Customer-Facing App or Internal System? Where the Line Goes, and Why One Data Model Matters

A distributor asked us to look at why their dealer portal generated so many phone calls. The portal worked. Dealers logged in, saw their orders, saw a status. The calls came because the status was wrong — not badly wrong, just a few hours behind, because the portal had its own database and a nightly job copied orders into it. A dealer would see "in production" on a shipment that had left that morning and ring to check. Every one of those calls was created by an architectural decision made two years earlier: the portal and the operations system each held their own copy of an order.

Two views, one operation

The distinction people usually draw is between a website and a web application. That one is easy: a website presents information to anonymous visitors, an application processes transactions for identified users with roles, sessions and an audit trail. The harder and more expensive distinction is the one inside the application — between the part your customers touch and the part your staff run on.

The last row is the whole argument. Everything above it can and should differ. The row itself should not.

What two data models actually cost

Copying data between a portal and an operations system is a design that fails in four predictable ways, and all four show up as human work rather than as errors on a screen:

• Stale answers with confident presentation. A synchronised copy is correct at the moment it was written and increasingly wrong afterwards. The customer cannot tell the difference, so they call.
• Reconciliation as a daily job. Someone compares the two sides, finds records that did not copy, and fixes them by hand. This work never appears in a project plan and never goes away.
• Two versions of a dispute. The customer has a screenshot of the portal. Operations has the internal record. Both are outputs of your own system and they disagree, which makes the argument unwinnable rather than merely awkward.
• Every new field, twice. A change to what an order carries has to be made on both sides plus the job in between, so small requests get quoted like large ones and eventually stop being asked for.

The alternative is one set of tables with permissions deciding who sees which rows and which columns. A dealer's login is scoped to their own company; a coordinator's is not. Nothing is copied, so nothing can drift.

The four things that must never be duplicated

1. 1. The identifier

   One order number, generated once, shown identically to the customer, the warehouse, the invoice and the support call. Separate internal and external references create a translation step that a person performs, and people mistranslate.

2. 2. The status

   One status field, one place it is set. The customer view may collapse several internal steps into a simpler word, but that mapping is a display rule — it is not a second status that someone updates.

3. 3. The customer record

   One master record for a company and its contacts, addresses and terms. If a portal keeps its own account list, the address a customer updates today is not the address that appears on the delivery note tomorrow.

4. 4. The agreed price

   The figure the customer accepted is stored with the order, not recalculated on display. A price that is recomputed each time a page loads will eventually show a different number than the one on the confirmation, and that number is the one you are held to.

What is allowed to differ

Sharing a data model is not the same as sharing an interface, and over-correcting here produces the other common failure: an internal system with a customer login on it. Legitimately different are the vocabulary, the visible field set, the workflow depth, and the device the screens are designed for. A customer confirming a delivery date needs one screen and two buttons. The coordinator behind it needs capacity, alternatives and the reason the original date slipped. Same order record, entirely different pages.

Permissions carry the weight here, so they are worth specifying in the same detail as the screens: which role sees which rows, which columns are hidden rather than merely absent from a page, and what is written to the log when someone with broad access opens a record. That is the same discipline described in where your data is stored and who can read it.

Which side to build first

Build the side that produces the data, then the side that reads it. In practice that means the internal system first, because a portal is a window onto operational records and a window is not useful before there is a room behind it. Two exceptions are worth naming. When the customer is the origin of the data — order entry, applications, document submission — the external form comes first, because it is what starts the process. And when an internal process is already running acceptably on a spreadsheet, a portal that removes a hundred status emails a month may return more, sooner, than replacing the spreadsheet.

The sequencing question is the same one covered in deciding what to automate first: pick by where the repeated work is, not by which part is more interesting to build.

When keeping them separate is correct

• The systems belong to different organisations. Integrating with a customer's own ERP is an integration, not a shared model, and it should be a documented interface with a defined contract.
• The internal system is a package you do not control. Then the portal reads through the package's API and holds no operational data of its own beyond what it needs for a session. That is a boundary, not a duplicate.
• Regulation requires isolation. Some data cannot sit in a system reachable from the public internet. In that case the public side holds a deliberately reduced record and the link between the two is documented and audited.

In each of these the rule still holds in spirit: one system owns each fact, and everyone else reads it from there. The failure mode is not two systems; it is two owners of the same fact. How that connection is made in practice is covered on our integrations page.

How a build runs

1. Weeks 1–2: the data model and a clickable prototype

   Roles, records and the relationships between them, agreed against your existing spreadsheets and screens. The prototype exists so the argument happens over something people have used rather than over a document.

2. Weeks 2–4: the first live module

   One real process in production, on real data, with a named owner for anything that falls out of the standard path. This is the point at which the system starts returning time rather than consuming it.

3. Then: the second view onto the same data

   Once the internal side is producing reliable records, the customer-facing screens are a permissions and presentation layer over data that already exists, which is why they cost a fraction of the first module.

Cost and delivery

• Focused application with a handful of roles: $3,000–6,000 over 2–4 weeks.
• Multi-department system on one data model: $8,000–15,000 over 4–8 weeks.
• Platform scope including customer-facing portals and integrations: $20,000+ over 3–6 months.
• Annual maintenance: optional, 12–25% of build cost. Licence: perpetual, unlimited users, source code delivered.

Systems built on a single shared model include Elevatora SAHA, where technicians, planners and building managers each see the same maintenance record through different screens, and PAP, which tracks pharmaceutical import and export processes across parties with different levels of access.

If your portal and your operations system currently disagree with each other, start there rather than with new features. Request a quote, read the web development page, or compare bands on the pricing page.

Frequently asked questions

What is the difference between a customer-facing web application and an internal system?

They differ in audience, permissions and language, not in the data underneath. The customer-facing side shows one company its own records in terms it recognises. The internal side shows staff every company's records with the operational detail, costs and controls that customers should never see. Both should read and write the same tables.

Why does it matter that both use the same data model?

Because two data models mean two versions of the truth, and someone has to reconcile them by hand every day. When the portal has its own order table synchronised on a schedule, a customer can see a status that stopped being accurate an hour ago, and your staff cannot tell whether the discrepancy is a delay or an error.

Which should we build first, the internal system or the customer portal?

The internal system, in almost every case. A portal is a window onto operational data; if the data is not being produced reliably yet, the window shows an empty room. The exception is when the customer is the source of the data — order entry, applications, submissions — in which case the external form comes first.

What should never be duplicated between the two sides?

The identifier of a record, its status, the customer master record and the price that was agreed. These are the four fields a dispute is argued over. If the customer sees one order number and your staff quote another, or the portal says shipped while operations says packing, the system has created the argument rather than settled it.

What can legitimately differ between the customer view and the internal view?

Wording, level of detail, and what is visible. Customers see a status vocabulary that means something to them; staff see the underlying step. Costs, margins, internal notes, other customers' data and operational exceptions stay internal. Different presentation of the same record is correct; a different record is not.

What does a web application cost at KodDelta?

A focused application with a handful of roles is $3,000–6,000 over 2–4 weeks. A system covering several departments with shared data and permissions is $8,000–15,000 over 4–8 weeks. Platform scope is $20,000+ over 3–6 months. The licence is perpetual with unlimited users and the source code is delivered.