The customer's screen and your operator's screen should be looking at the same record

Three different things get called "a website"

The word covers work with very different costs and risks, and the first useful step is separating them.

• A corporate site and campaign pages. Content that has to load fast, be found, explain what you do and capture an enquiry into a database rather than into an inbox. Largely a publishing and performance problem.
• A customer or partner application. Authenticated screens where someone outside your company does something real: places an order, tracks a job, uploads a document, approves a quotation. This is a software problem wearing a website's clothes, and it belongs on the same data as your internal system.
• A field or mobile application. The same idea aimed at people working away from a desk, where the phone, the camera and the absence of a signal set the design.

The mistake that costs the most is treating the second and third as if they were the first. A portal built as a website with a database bolted on will work for six months and then start disagreeing with the system it was supposed to reflect.

Why the customer app should share the internal data model

The principle is simple: the customer's screen and the operator's screen are two views of one record, with different permissions. Not two records kept in step.

What that means in practice:

• One identifier for an order, a job or a case, quoted the same way by the customer and by your staff
• One status vocabulary, with the customer view showing a subset rather than a translation
• A change made by an operator is visible to the customer immediately, with no integration involved
• Permissions decide what each side sees, on the same tables, so an internal cost field simply is not returned to a customer session
• One audit trail covering both sides, which is what settles a dispute about who changed what and when
• New fields are added once, not twice with a mapping between them

The alternative is a portal with its own database and a synchronisation job. That design has a predictable set of failures: duplicate identifiers, statuses that do not map cleanly in both directions, a record created on one side while the other is unavailable, and drift that nobody notices until a customer quotes a number your staff cannot find. If you already run that arrangement, the way out is described in the migration guide.

There is one legitimate reason to separate them: when exposing the internal database to the public internet is unacceptable on security grounds. The answer then is not a second system with a two-way sync, but a read model — a defined, minimal subset published outward, with writes coming back through a narrow, validated interface. The cost of separation is accepted deliberately, for a stated reason, rather than arrived at by accident.

Offline working, and what it really costs

Offline capability is asked for casually and is not casual to build. It roughly doubles the complexity of everything on the write path, so it is decided at the start of the design rather than added later. Here is what it actually involves.

Which of these you need depends on the work. A customer checking an order status needs none of it. A technician in a lift shaft or an engineer in a basement needs all of it. The choice between a progressive web app and a native one is worked through in PWA or native app.

Separate application, or another screen of the system you have?

This is the decision that most affects the budget, and it is decided by the audience and the conditions rather than by preference.

Read plainly: if the users are internal, always online and on a laptop, add the screen. Building a separate application for an internal, occasional, connected task gives you a second thing to maintain and nothing else. The dealer-facing version of this decision is worked through on dealer portal, and the field version on field service.

The public site, treated as engineering

The corporate site and campaign pages are a smaller problem than the applications, but they have their own failure modes and they are worth stating without inflation.

• Speed against a published standard. We build against Google's published Core Web Vitals thresholds — largest contentful paint under 2.5 seconds, interaction to next paint under 200 milliseconds, cumulative layout shift under 0.1 — and measure the real pages rather than a development machine. We will not quote you a conversion percentage we have not measured on your traffic.
• Enquiries stored, not just emailed. Every submission is written to a database first and notified second. Email-only forms fail silently, and the failure is discovered by a customer asking why nobody replied.
• Structured data that matches the page. Schema markup describing what is actually on the page, including questions and answers that appear on screen rather than only in the markup.
• Content your team can edit. Articles and case pages editable without a developer, through a lightweight content layer rather than a plugin stack that needs weekly patching.
• No licence attached to the design. Templates, styles and code are yours. Hosting is included for the first year and is a modest annual figure after that; the bands are on pricing.

When we would tell you not to build this

• The internal system does not exist yet. A customer portal over a process still run on spreadsheets exposes the spreadsheets. Build the operational system first; the customer view is then a small addition.
• Nobody will use it because nothing changes for them. If customers can already get an answer by messaging your team in thirty seconds, a portal has to be better than that, not merely available. Design the reason to use it, or do not build it.
• A brochure site is all you need. If the site's only job is to exist and be found, say so and keep it small. We would rather build the right small thing than a portal nobody signs into.
• Offline is a wish, not a requirement. If your users are on a warehouse floor with reliable Wi-Fi, offline complexity buys nothing. Ask where the work actually happens before paying for it.
• The requirement is a marketplace or a consumer shop at scale. Established platforms handle that well, and the honest comparison is on package versus custom.

How a build starts

1. Decide the data model question first

   Same database with permissions, or a published read model with a stated security reason. Everything else follows from this answer, and changing it later is the expensive kind of change.

2. Name the tasks, not the pages

   What does the customer or the technician need to complete, in how many taps, in what conditions? A page list is a layout. A task list is a specification.

3. Prototype in the first 2 weeks

   Clickable screens with real data, tested on the device the work actually happens on. If it is a phone in a stairwell, it is tested on a phone in a stairwell.

4. First module in production, 2–4 weeks

   At $3,000–6,000, narrow enough to be real: usually order or job status, documents and requests. A wider application with several roles, offline capability and integrations is $8,000–15,000 over 4–8 weeks.

The source code is delivered to you, the licence is perpetual with unlimited users, and maintenance is optional at 12–25% of build cost. Applications we have built on this pattern include Elevatora SAHA, a multi-tenant lift maintenance and field service system with mobile use in the field, Elevatora İMALAT, a manufacturing and ERP system for lift components, SEMP Group, a group-wide operations platform, SmartHukuk, our own legal technology product, and a pharmaceutical import and export process tracking system; Elevatora PROJE is in development. See cases and custom software.

Frequently Asked Questions