Field report: wholesale platform commissioning

Design, build and commissioning record for a trade ordering platform and dedicated web infrastructure delivered to a general goods wholesaler in North London. The engagement covered product design, application development, onsite hosting, offsite backup and production launch.

Assignment record

06 October — Initial contact

The client contacted Half Assed Web Design after its existing downloadable price list became difficult to maintain. Trade customers placed orders by telephone, spreadsheet and email, and different account managers retained separate copies of product descriptions and prices. The immediate requirement was a searchable catalogue that could apply customer-specific pricing and submit a structured order to the warehouse team.

An onsite workshop mapped the current sales process, product import, account approval, price-band assignment, availability updates and order export. Public retail checkout was excluded. Only approved trade customers would see prices or submit orders, while the public site would present company, delivery-area and account-application information.

09 October — Scope and information design

The product catalogue contained approximately 18,000 active stock lines across household goods, catering supplies, seasonal stock and general consumables. Source data came from a nightly export produced by the warehouse system. Product names and pack sizes were reasonably complete; categories, descriptions and photography varied by supplier.

The agreed structure separated public content, authenticated catalogue, saved order and account administration. Search needed to tolerate supplier codes, client stock codes and common abbreviations. Orders would be validated against the latest import, written to the platform database and exported in a format accepted by the warehouse system.

20 October — Design proofs

Initial proofs covered the public home page, category listing, product result, product detail, trade sign-in, basket, order review and account area. Desktop layouts reflected the wide tables used by regular purchasing teams, while narrow layouts prioritised product code, pack size, price and quantity entry without requiring horizontal scrolling.

The first review reduced promotional space and increased catalogue density. The second established category navigation, stock-state language and the distinction between unit and case pricing. A clickable prototype was tested with three account managers and two customers before visual approval. Their changes were incorporated into the signed component and template set.

Infrastructure design

The client preferred the application and product data to remain onsite because its warehouse export was generated within the local network. A dedicated server would operate from the communications room, using the business fibre connection and static address. An encrypted offsite repository was specified for nightly application, database and uploaded-media backups.

27 October — Backend implementation

The application was built around trade accounts, users, price bands, product imports, saved baskets and orders. A staged import validated source columns, rejected incomplete rows and produced a reconciliation report before replacing the searchable catalogue. Price and availability changes were applied transactionally so customers could not read a partially updated catalogue.

Administration screens covered account approval, price-band assignment, minimum-order rules, delivery notes and order export. Authentication used per-user accounts with rate limiting and password-reset expiry. Roles separated customer users, sales staff and platform administrators. Changes to price assignment, account status and order state were written to an audit log.

The order service recalculated every line against the current account and product record at submission. It preserved the accepted price, quantity, pack description and tax state as order-line evidence, then generated a warehouse export through a queued job. Failed exports remained visible to staff without asking the customer to resubmit the order.

10 November — Frontend integration

Approved design components were integrated into server-rendered templates. Catalogue search and basket updates used small asynchronous enhancements while retaining ordinary form submissions as a fallback. Focus state, error summaries, field labels, keyboard order and zoom behaviour were checked across the account and ordering journeys.

Images were generated at catalogue and detail sizes with a fixed placeholder for missing supplier photography. Responsive source selection reduced transfer on handheld warehouse devices. Static assets were versioned for long cache retention, and private account responses were marked to prevent storage in shared intermediary caches.

Testing covered current desktop and mobile browsers used by the client, representative older warehouse terminals, slow connections and expired sessions. Import and ordering tests used a scrubbed copy of the product catalogue and synthetic accounts. No live customer or order data was included in the development dataset.

24 November — Final adjustment

The client review requested denser search results, persistent quantity fields when filters changed and a printable order confirmation for customers working from paper picking lists. Category labels were aligned with the terminology used by the sales desk, and ambiguous “each” pricing was replaced with explicit unit and case descriptions.

Content editing concluded with delivery terms, account eligibility and contact routes. Product photography remained incomplete but did not prevent launch. The final acceptance run covered account creation, sign-in, price visibility, search, basket recovery, order submission, warehouse export and administrator state changes.

01 December — Infrastructure commissioning

The dedicated server was installed in the client communications cabinet, connected to the UPS and brought under system, disk, certificate and application monitoring. Mirrored storage degraded and rebuilt correctly during a controlled member test. UPS loss and automatic shutdown signals were confirmed without interrupting the client’s other network equipment.

Nginx, PHP-FPM, PostgreSQL and the application release were deployed through the documented production configuration. Firewall translation and the public TLS endpoint were tested using the static address and a temporary local hostname override. The warehouse export and import directories were mounted through a restricted service account, and a complete catalogue import succeeded on the onsite server.

The offsite backup agent was registered and an encrypted repository was created. Connectivity, credentials and retention policy reported ready. A small commissioning file was transferred and read back through the repository client; the scheduled application backup was left to begin after the production data cutover so the initial retained point would contain the launched database and media set.

03 December — Go live

The final release was deployed during the agreed morning window. A DNS change had been prepared to direct the public hostname from the development endpoint to the client’s static address. During the change, external access to the onsite address was inconsistent from one test network, while the same release remained available through the development host.

To maintain the announced launch time, the development endpoint was retained as a temporary public route while the onsite firewall state was rechecked. The public hostname displayed the approved release, TLS validation passed, customer sign-in worked and test orders reached the warehouse export. The launch checklist recorded the service as live after the client completed its acceptance order.

Later that day the onsite endpoint responded correctly through a direct host override. The temporary route was therefore considered cleared for removal. The DNS line item was marked complete, monitoring showed the public page healthy and launch communications were issued.

First seven weeks of operation

Trade customers adopted the site and the sales team approved additional accounts. Product imports ran each night, users maintained saved baskets and orders were submitted throughout the working week. Minor requests concerned search synonyms, pack descriptions and the order-confirmation layout. None required an infrastructure change.

Availability monitoring continued to request the public home page and sign-in screen. Both returned expected content and valid certificates. Application-level monitoring did not include an origin identifier, database sequence or proof that the responding host was the commissioned onsite server.

21 January, 18:40 — Development host retirement

The shared development server was scheduled for reuse by a new client project. Existing test applications were listed as superseded or complete, and the wholesale platform was recorded as having moved to its dedicated production infrastructure in December. Its development virtual machine, attached database volume and uploaded-media volume were therefore deleted during routine reprovisioning.

The host was rebuilt from the standard development image. Local virtual-machine snapshots were removed with the old project allocation, and storage discard completed before the new project environment was installed. No production change was expected because development had been formally closed after launch.

22 January, 08:07 — Client outage report

The client called to report that the catalogue and account sign-in were unavailable. Monitoring had begun failing at 18:42 the previous evening, coinciding with the development rebuild, but the alert route was assigned to the completed development project and had not produced an attended incident.

The public hostname resolved to the address used by the shared development service rather than the client’s static onsite address. Requests reached the newly provisioned development host, which had no virtual host for the wholesaler domain and returned its default response. Direct connection to the onsite server remained healthy.

08:31 — Origin investigation

DNS history showed that the prepared production record had never replaced the temporary development origin. The go-live checks had confirmed the correct page and certificate but had not recorded the destination address, server identifier or response header. The later direct test of the onsite server used a local hostname override and therefore did not prove that public DNS had changed.

The commissioned server contained the release installed on 01 December, the scrubbed acceptance accounts and the catalogue imported during commissioning. Its application database showed no live customer registrations, saved baskets, catalogue changes or production orders. Warehouse import timestamps stopped at the commissioning run. Web access logs contained health checks by static address but no public customer traffic.

09:12 — Production data location

Review of the former development routing and application logs established that every production request since launch had continued to reach the development virtual machine. Customer accounts, password records, product imports, saved baskets, orders, administrator changes and uploaded product media had all been written to the development database and filesystem.

Those volumes were deleted during the previous evening’s wipe. The storage had been discarded and reallocated to the new project, and no retained hypervisor snapshot covered the former machine. Recovery from the active development storage was assessed as unavailable.

09:46 — Offsite backup assessment

The backup agent on the dedicated onsite server was connected and its repository credentials remained valid. Examination of the offsite repository found the container and retention definition but no completed application archive, database dump, media set or backup manifest. Stored data usage was zero.

The commissioning transfer had used the repository client’s connection-test area and was automatically removed after verification. The scheduled backup definition remained disabled pending the production data cutover event. Because the cutover was marked complete without the associated enablement step, no nightly job had run. No backup agent had been installed on the development server, as that system was not authorised to hold production data.

Data-loss assessment

Source code and the pre-launch scrubbed catalogue remained available in version control and on the commissioned server. They did not contain the production state created after launch. All live customer accounts, credential records, saved baskets, product amendments, order records, audit events and uploaded media were lost. No complete or partial production-data recovery point was identified.

Finding and corrective position

The incident resulted from separate delivery checks being treated as proof of one completed cutover. Public availability established that a server responded; direct infrastructure testing established that the onsite server could respond; neither established that they were the same server. Backup readiness established that a repository accepted credentials; it did not establish that a production dataset had been written or restored.

The development wipe was performed against records stating that the platform had moved to production and was not, by itself, inconsistent with the development-host lifecycle. The production route, origin identity, backup execution and restore evidence were not reconciled after launch. The outage began when removal of the unrecorded production dependency exposed that state.