Engineering Websites and Customer Portals: Planning the Public and Private Sides

An engineering website helps an unfamiliar buyer qualify the company. A customer portal helps an authorised person complete a defined task with private records. Plan those jobs separately, then specify the handoffs. Public project evidence, private drawings and internal work instructions should not share an accidental publication boundary.

A technical director wants the website to explain capability. Operations wants customers to find the current drawing. Sales wants fewer incomplete enquiries. These requests can belong to one programme, but they do not belong to one undifferentiated list of pages. Each has a different reader, source of truth and consequence when something is wrong.

This guide focuses on the boundary between public qualification and private operational work. For the wider public-site planning process, see the engineering website design guide. Here, the question is what a buyer may see before a relationship exists, what a customer may see after access is granted and who approves each record.

All company records, portal screens and numbers below are fictional teaching examples. Generated photographs illustrate ordinary work. They do not show a real customer installation. Download the engineering website and portal workbook or editable CSV pack. The five captioned web tables provide an ungated working equivalent.

Begin with the person and task

A procurement manager may need to establish whether the company performs a particular process. A technical reviewer may need approved materials, tolerances or certifications. An existing customer may need the latest released drawing for a project. An internal coordinator may need to answer a missing-information request. These are different tasks even if everyone uses a browser.

Write each task in plain language before selecting screens. Identify the input, permitted action and useful result. A customer downloads an approved document. An engineer submits a proposed revision for review. A coordinator assigns an enquiry. A director reads an agreed metric. Avoid requirements such as build a dashboard until the decision behind the screen is known.

Table 1: readers and tasks. Fictional roles illustrate distinct needs rather than a prescribed organisation chart.

An ordinary website may solve the first two tasks without a portal. A document-sharing tool may solve one customer task without a custom application. Inspect the actual friction before choosing technology. The useful requirement is the task that keeps failing, not the assumption that every engineering firm needs a login area.

Classify information before importing files

Create a content classification register. Public content should have permission for publication and a named factual approver. Customer-specific material should have an organisation or project boundary. Internal records should stay outside both unless the business deliberately authorises sharing.

A public case study can describe the problem, constraints and approved outcome without exposing protected drawings. A capability page can state a process range with units and conditions. A customer portal can show a released file for a particular project. The record behind that file can remain internal if it contains review notes or information the customer does not need.

Do not treat a publicly reachable storage address as private because the navigation omits it. Likewise, an obscure filename is not permission control. Decide which layer authorises requests for the record and for the actual file. Test direct access rather than only the portal's visible links.

Table 2: public and private classification. Permission to publish is a business decision; technical access must implement it.

Classification also applies to thumbnails, email notifications and exports. A safe portal page can still leak a project title in an unrestricted notification. Record the permitted content for each channel. A permission model that covers only the largest file misses the surrounding information that identifies it.

Make public qualification precise

The public website should help buyers judge whether a conversation is relevant. It needs clear service boundaries, application conditions and evidence that the company can approve. A broad phrase such as engineering services does little if it leaves the buyer unsure about processes, project stages or supplied materials.

Start with the questions staff repeatedly clarify. Does the company design, manufacture, install, inspect or maintain? Is a tolerance a general capability or specific to a material and process? Is a certificate current, and what entity or scope does it cover? These distinctions should shape the content before a designer chooses its layout.

Google's people-first content guidance asks publishers to provide useful, reliable information for their audience. It does not turn a capability claim into verified engineering evidence. The business remains responsible for approving technical statements, project permissions and the conditions attached to specifications.

Use an enquiry route that follows qualification. If the buyer needs to submit an application drawing, explain the approved method and its limitations. Do not encourage confidential uploads into an unreviewed public form. For some firms, the correct first enquiry contains only project type, required service and a request for an appropriate document-sharing route.

Specify permissions as actions

A role named customer is too broad. One customer may belong to two organisations. Another may be permitted to view documents but unable to submit revisions. A project manager may approve a record without having authority to change account membership. Express permissions as actions on a defined record set.

Separate identification from authorisation. Authentication establishes an account's identity through the implemented mechanism. Authorisation decides what that account may do. The Supabase authentication overview explains its identity features. Identity alone does not establish that a user belongs to the project whose record they request.

Database controls can enforce record boundaries below the screen. Supabase row-level security guidance describes policy-based access for its Postgres service. This is a platform-specific implementation option, not a ready-made portal permission design. The actual organisation, project and action rules still need to be defined and tested.

Table 3: role permissions. This fictional project needs separate tests for permitted and denied actions.

Administrative access should also be explicit. Some tools allow privileged server components to bypass ordinary policies. Keep that capability outside customer clients and ordinary screens. Test the actual deployed access route with separate users, including an unrelated organisation. A successful administrator test tells you little about customer isolation.

Give files the same boundary as records

A document row can be restricted while its stored file remains public. Check both. In a Supabase example, storage access control uses policies to govern operations on stored objects. Public buckets and private access routes have different behaviour. Choose deliberately and test the resulting direct file request.

The portal should identify the record, revision, release state and permitted audience. A file path should not become the entire data model. If a customer downloads an attachment, the visible description should make clear what revision was provided. If a file is withdrawn, the business needs a defined action for previously shared links and notification records.

Link expiry and account revocation are also different. An expiring link may stop working later, while a downloaded copy can remain with the recipient. A revoked account should lose the permitted system actions, but that does not recall copies already obtained. Explain this limit during requirements work so the portal is not sold as a way to reverse every disclosure.

Decide whether previews and generated thumbnails inherit the same rules. Decide who can export a project's document list. Decide whether a customer can see older released revisions. These questions affect the actual work and should be answered before a developer builds a general file library.

Keep approval and release separate

A draft can be reviewed without being released to a customer. An approved revision may wait for a scheduled release or associated instruction. A released record may later be superseded. Define these states in the process rather than relying on a filename such as final-final.

The portal should show a clear current record and a controlled history where needed. It should preserve the link between a revision and the person authorised to release it. If a file is replaced without a new record, the history becomes difficult to interpret. The business loses evidence about what was available at a particular point.

Database design can support consistent identifiers and relationships. PostgreSQL constraints include checks, unique constraints and foreign keys. These can prevent specified classes of inconsistent records. They do not decide whether an engineering revision is technically acceptable. Keep that judgement with the responsible approver.

In the fictional workflow, a contributor submits revision B. The approver reviews it and records a decision. The release action makes B visible to the assigned customer and marks A as superseded. A test should verify all three effects. Merely observing B on an internal screen does not establish that the customer sees the correct current record.

Follow the enquiry into project work

A public enquiry and a private project record can be connected without becoming the same object. The enquiry may be incomplete or unqualified. The project may require a confirmed customer organisation and agreed scope. Define the decision that permits the handoff, and preserve the original reference where it is useful.

Use a fictional enquiry for a replacement component. The buyer submits the application, material and contact details. A coordinator checks the request and asks for missing information. Only an approved progression creates a project workspace. A rejected or unrelated request should not automatically receive access to a document portal.

The integration must preserve record ownership and failure evidence. If the project is created but its notification fails, the process needs a visible exception. If the same enquiry is processed twice, decide whether the system should recognise the existing project. These are testable behaviours, unlike a vague requirement to connect the website to operations.

Stripe's webhook documentation provides a concrete vendor example of event delivery with retries and delivery considerations. It is not a general engineering-project API. The useful planning lesson is to read the actual integration's delivery contract and define how repeated or delayed events affect the business workflow.

Define dashboard figures before drawing them

A portal dashboard can create false confidence if its figures have no agreed meaning. Define the state, time window, exclusions and freshness for every number. A count of documents awaiting review is different from the count of projects awaiting customer input. The same record can appear in several working queues unless the design deliberately makes them exclusive.

Consider a synthetic snapshot of eight project records. Three are waiting for internal review, two are waiting for customer input and three are ready for the next agreed step. These categories are assumed mutually exclusive for this example. Their sum is eight. The model describes queue membership, not lateness, productivity or client performance.

If the real process allows several blocking reasons per project, counting reasons will produce a total larger than the project count. Explain that distinction on the screen and in the metric dictionary. A manager should be able to tell whether the figure counts projects, documents, tasks or reasons. Attractive chart labels do not resolve the underlying ambiguity.

Table 4: metric definitions and limits. Figures below are defined measures, not recommended performance targets.

Record the data refresh time. If a dashboard reads a cached summary, make that visible. Test one underlying change and observe when the figure updates. An old number with a clear timestamp is easier to interpret than an apparently current number whose inputs were loaded the previous day.

Plan the data model around ownership

Define the relationship between organisations, people, projects, documents and tasks. A user account is not the same as a customer organisation. A person may change employer. A project can have several authorised participants. The data model should preserve those distinctions without depending on an email domain as the only membership rule.

Give every imported record a stable reference. Preserve source identifiers where reconciliation requires them. Specify which fields can be corrected and who approves corrections. If the old spreadsheet contains two customer names for the same organisation, decide how they are resolved before import. The developer should not infer legal or commercial identity from similar names.

The PostgreSQL privileges documentation describes database permissions. These are another layer of implementation authority, separate from the business role model. A database user allowed to update a table is not automatically an engineering approver. Keep the application workflow and platform permissions aligned through explicit checks.

Record deletion also needs a defined meaning. Closing a project, removing customer access and deleting files are different actions. Some records may be needed for the business's approved retention process. Ask the responsible owner to decide that process and obtain relevant professional advice where required. The portal should implement the decision rather than invent it.

Migrate with a reconciliation record

Before copying legacy documents, inventory the source. Identify current revisions, historical revisions, duplicates, unsupported formats and missing metadata. A folder name may encode a project or customer, but the import should not rely on that assumption without confirmation. Keep unknown records in a review queue.

Use a pilot project that includes ordinary files and a known exception. Import it into a controlled environment. Compare the record list, file access and revision state with the approved source. Ask the customer-side tester to find the current file through the intended journey. The internal administrator's ability to find it is a different check.

Reconcile totals by record type, then inspect samples. Counts can show that something is missing, but equal totals do not prove equal content. A renamed duplicate can replace a missing original and leave the count unchanged. Where files matter, compare identifiers, approved metadata and actual content as appropriate to the platform.

Keep the old source available under the agreed access arrangement until acceptance is complete. Document which system becomes authoritative and when. If staff keep updating the old spreadsheet, the new portal can be wrong immediately after import. The cutover plan needs a clear record-entry boundary and a route for late changes.

Test the boundary through actual requests

Test permitted and denied actions with representative accounts. An authorised customer should open a released document for its project. An unrelated customer should fail through the direct record route and the direct file route. A former participant should lose access under the agreed revocation process. A contributor should not bypass release approval.

HTTP responses can help describe the observed request outcome. The MDN status reference explains response classes and individual codes. Record the status and actual returned content. A page displaying an error message does not establish the server's access behaviour on every underlying endpoint.

Table 5: acceptance and ownership checks. Use controlled fictional records and keep evidence outside public content.

The checks should follow the deployed configuration. A local prototype can demonstrate interaction while leaving permission enforcement untested. Record environment, version and user role with each result. The evidence should show what was checked and where its conclusions stop.

Work through a document-release example

In a fictional fabrication company, the public website states that the team can evaluate specified materials and processes. It includes an approved project description without a customer drawing. A buyer enquires with an application summary. The coordinator asks for details through an agreed private channel, then creates a project when the request is accepted.

The portal has two customer contacts. One can view releases. The other can submit comments. Both belong to the same assigned project. An internal engineer uploads revision A as a draft. The file remains invisible to customers until the approver records the required review and releases it.

During pilot testing, the customer cannot see the draft on the portal page but can open an old unrestricted file link. That fails the file boundary test. The implementer changes the storage route and repeats direct-access checks with both an authorised user and an unrelated organisation. The public website never receives the private attachment.

Later, revision B replaces A. The system marks B current, retains the agreed A history and sends a permitted notification. A current-revision snapshot counts one current released revision. A release-event measure counts two if both A and B were released within its selected window, or one if only B falls within that window. The operations owner keeps these definitions separate so historical releases are not mistaken for concurrently active documents.

The example does not claim certification, measured time savings or complete prevention of disclosure. It shows four different acceptance questions: public accuracy, private access, controlled revision and metric meaning. A portal proposal should make those questions visible before the company approves screen designs.

Operate the public and private sides separately

Public content needs technical approval, search review and ongoing fact maintenance. Private records need account management, workflow support, recovery and customer assistance. Some people will hold several roles, but their tasks should still be distinguishable. A public content editor should not acquire document-release authority merely because both areas use the same CMS.

Keep support routes visible to customers. Explain what they can do when a file is missing, an upload fails or the record appears wrong. Provide a fallback that reaches the responsible team. A portal that only says contact administrator leaves a customer guessing which person or organisation owns the problem.

Search work concerns the approved public side. Protected portal pages are operational screens, not acquisition landing pages. A noindex instruction can govern indexing behaviour, but it is not a substitute for private access control. Decide permissions through the application and file layers, then configure discovery controls for their separate purpose.

Test a departing customer's access

An account departure is a useful acceptance scenario because it touches identity, membership and files. In the fictional pilot, one customer contact leaves its organisation. The business administrator removes that person's project membership under the approved procedure. The customer organisation and its remaining contact stay active.

The test checks the former member's direct record request, file request and visible project list. It also checks that the remaining authorised contact can still retrieve the released document. A successful denial is only half the result. The change must preserve the legitimate working route for the customer that still needs it.

The business records the date, scope and person who approved removal. It does not delete the organisation merely to remove one account. Historical release decisions remain linked to their records. If a temporary link remains valid after membership removal, the implementer explains that behaviour and the business decides whether the implementation meets its approved requirement.

Downloaded copies remain outside this test's control. That limit should be stated during permission planning, not discovered during a real departure. The purpose of the exercise is to verify defined future access and record continuity, while preserving the distinction between revocation and recall.

Frequently asked questions

Does the portal need to share the website's platform?

No. A shared platform can simplify some administration, while a separate application may fit different permissions and workflow requirements. Choose after inspecting the tasks, integrations and operating responsibilities. The boundary between public and private content needs testing either way. Matching colours or a common domain does not establish shared access rules.

Should every customer receive an account?

Only when the account supports a useful agreed task. An occasional document exchange may be handled through another approved route. A repeated revision workflow may justify persistent project access. Define how accounts are invited, reviewed and closed before expanding access across the customer list.

Can the portal replace technical approval?

It can record and enforce an agreed approval route. It cannot decide whether a drawing or specification is technically correct merely because a button was pressed. The business must name the authorised reviewer and required evidence. The system should preserve that decision and prevent accidental release outside it.

Is a dashboard count enough to manage work?

Only if its meaning is clear and it connects to an action. Counted units, states, exclusions, refresh time and ownership need definitions. A synthetic teaching figure is not evidence of real workload. Reconcile the production number to representative source records and check how users interpret it.

Can customer downloads be recalled?

Access can be revoked and future links can be restricted according to the implementation. Copies already downloaded may remain with their recipients. State that limit when planning permissions and document release. The company should not assume a portal turns external sharing into a fully reversible action.

What proves the handover is ready?

The receiving team can invite a permitted customer, find the current record, handle a failed task and identify the recovery and escalation route. The technical owner can explain the access model and operating dependencies. Record any unresolved issue with an owner instead of treating training attendance as proof of operating competence.

Start with the boundary that is failing

Bring one public claim buyers misunderstand and one private task customers struggle to complete. Together they show whether the problem is content, records, permissions, workflow or a combination. A portal may be the answer, but the diagnosis should establish what it must protect and what it must make easier.

Creatif Work can scope website work, web applications and ongoing search work around those distinct responsibilities. The business retains technical approval and customer-sharing decisions. Start with the problem.

Sources and limits

Official documentation checked on 4 October 2026. Platform mechanisms are examples. They are not claims that every engineering portal uses the same architecture.

• Supabase: authentication.
• Supabase: row-level security.
• Supabase: storage access control.
• PostgreSQL: constraints.
• PostgreSQL: privileges.
• Stripe: webhook delivery.
• MDN: HTTP response status codes.
• Google: helpful, reliable content.