A retrospective recall of the app behind the event that hosted some of the World’s leading experts of international security in February 2025. By its developer, Tim Brocklehurst.
There are client briefs that stay with you. Not because of the scale, or the technology, or even the elegance of the finished build – but because the nature of the project changes the way you think about almost every decision you make. The THESIS Global conference app was one of those.
THESIS was an invitation-only gathering drawing senior figures from business, law, politics and international security. It had one hundred delegates and was held in a prestigious private hotel in St. Moritz, Switzerland. Complete discretion: Not just requested, but fundamental to the event’s purpose and value. The application I was commissioned to build had to serve that world – and that meant approaching every aspect of the architecture, from data storage to internal communications, with an unusually high bar for privacy, security and operational reliability.
Starting With the Problem, Not the Platform
The first instinct in any build like this is to reach for existing event management software – something off the shelf, established, familiar. I rejected that approach almost immediately. Pre-packaged platforms are designed for openness: They are optimised for marketing, integrations with CRMs, and public-facing delegate portals. They store data on infrastructure you do not control, through APIs that third parties can and do access. For an event where the delegate list itself is confidential, that is an unacceptable starting point.
Instead, I built the platform from scratch as a WordPress-based multi-user web application, extended with a suite of custom PHP plugins that gave us complete control over every layer of the system: Who sees what, how data is stored, how it moves, and where it rests at each point in the process.
The result was a closed, self-contained digital environment: A private web application running on controlled infrastructure, with no third-party marketing integrations, no open APIs, and no data resident on commodity cloud platforms. Delegates were directed to it via a private URL, and access was gated from day one.
Delegate Registration: More Than a Sign-Up Form
The registration system was substantially more complex than a standard conference sign-up. The platform needed to capture not just contact details but logistical data – arrival airports, flight numbers and timings, departure arrangements – used by the event team to coordinate private transfers to and from the hotel. That meant building a structured data model that mapped each delegate’s travel profile, surfaced it cleanly for event administrators, and kept it entirely private between the delegate and the organising team.
Profile data – headshots, biographical summaries, role descriptions – was handled with particular care. These are not images and bios that could sit in a WordPress media library on a shared hosting account. They needed storage with access restrictions that went beyond standard password protection or user-role logic.
That is where the Safe-4 integration came in.
Safe-4: Security at the Infrastructure Level
Safe-4 is a high-security digital storage and asset management platform that enforces access control at the load-balancer level – meaning restrictions are applied before a request even reaches the application server, rather than relying on software-layer authentication that can, in principle, be bypassed. For data of this sensitivity, that distinction matters.
The integration I built sits in thesis_safe4_connect.php. Every interaction with Safe-4 – retrieving a delegate’s profile image, writing a new asset, creating a folder within the asset register – begins with a session key handshake: A POST request to Safe-4’s API using stored credentials, which returns a short-lived session token. That token is then used to authenticate every subsequent call within that operation. Credentials never travel with the data payload; they are resolved separately, on every request, and the token expires.
function s4_session_key(){
// Authenticates against Safe-4 API and returns a fresh session token // Called fresh on every operation - no persistent token storage
}File uploads to Safe-4 use multipart form data over cURL with the session key in the request header. File retrieval works the same way in reverse – the binary blob is fetched from Safe-4, written to a controlled local path, and then served from there. Nothing is streamed directly from Safe-4’s storage infrastructure to the client.
Safe-4’s asset register – essentially a high-security structured database – was also used to manage delegate profile records: A folder hierarchy per delegate, with assets named and typed in a consistent schema. This gave the event team a clean, auditable record of every profile in the system, without that data ever touching conventional cloud storage.
Encrypted Private Messaging Between Delegates
The most technically involved aspect of the build was the inter-delegate messaging system. The brief called for private, encrypted communication between any two delegates on the platform – conversations that could not be accessed by the event team, could not be reconstructed from server logs, and left no recoverable trace after the event.
The architecture I chose for this stores message threads as custom post types in WordPress (post_type = 'chat'), with each thread parent representing the conversation and each message stored as a child post. This gave me the full power of WordPress’s native data model – author attribution, timestamps, post status – while keeping everything within the controlled database environment.
Encryption and decryption are handled on send and receive respectively, using per-user message keys stored in user meta. Each delegate is assigned a unique key on first login:
if(!$msg_key){
update_user_meta($user->ID, 'msg_key', th_rand(32));
}The result is that even if the database were accessed directly, message content is unreadable without the corresponding key – and keys are held per-user, not centrally.
Unread message counts are calculated through a direct SQL join across the post tables – efficient, real-time, and private to each user’s session. The interface surfaces unread counts as notification badges, updates on a configurable timer, and supports delegate search with role-based filtering. Conversations can be individually removed by either participant, with removals tracked in post meta rather than hard deletion – meaning the platform retains structural integrity without preserving content the delegate has chosen to discard.
The full messaging interface was built as a single-page-style view within the platform: A contact list, a search panel for initiating new threads, and a single-chat view – all rendered server-side and toggled in the DOM, minimising network calls and keeping the experience fast even on hotel wi-fi.
Progressive Web App: A Private Mobile Experience
One of the most warmly received aspects of the platform was its availability as a mobile application. Not through the App Store or Google Play – both of which would have created public discoverability and required submission to third-party review processes – but as a Progressive Web App (PWA), installable directly from the private URL.
With the appropriate manifest and service worker in place, delegates on both iOS and Android could add the platform to their home screens and use it as a full-screen app, indistinguishable in feel from a natively installed application. Push notification support for new messages was available on supporting devices, and the offline caching strategy meant the core interface remained responsive even when connectivity was intermittent.
The PWA route also meant the installation process itself was private: There was no public listing, no store page, no name in a searchable registry. Delegates received the URL through secured channels and installed from there. From a security standpoint, it was the right call in every direction.
Not every delegate arrived without complications, however. A small number carried government-issued devices hardened against cookie storage – a reasonable security measure on those phones, but one that created friction with the platform’s verification flow, which granted access via a tokenised email link backed by a week-long cookie. With no cookie to persist, those delegates faced re-verifying on every session.
A last-minute on-site fix added username and password as an alternative authentication path – not elegant, but pragmatic: Even where a government-locked device refused to store a cookie, there was at least a reasonable chance it would offer autofill for a familiar email and password combination. It was a reminder that however carefully you architect a system, the real world introduces variables that no brief anticipates – and that the ability to diagnose and ship a fix in hours, rather than days, is itself part of what a bespoke build makes possible.
Operational Reliability Under Pressure
One hundred delegates, many of them senior public figures unused to troubleshooting technology, using a platform they had never seen before, in an environment where support options were limited and embarrassment was not an option. Reliability was not a secondary concern – it was a primary design constraint.
Every integration point in the system was built with explicit error handling and fallback logic. Safe-4 API calls that failed were logged to WordPress options (a deliberate temporary debugging layer, removed from the production build) and surfaced to administrators without exposing them to delegates. The session key renewal pattern meant that stale authentication tokens – inevitable in a long-running event – were handled gracefully rather than producing cryptic errors for the end user.
The messaging refresh timer was configurable via a WordPress option, allowing the event team to tune the polling frequency against the demands on the server at any given moment – useful when one hundred people are simultaneously sending messages during a dinner or plenary session.
The transfer coordination data – flight numbers, arrival times, airport details – was accessible to a small number of event administrators through a clean back-end interface, separate from the delegate-facing platform. Changes made by delegates to their travel details updated in real time. Administrators could filter and sort by arrival date, airport and transfer group without needing to access the raw database.
What This Build Represents
Projects like this one are, I think, where the real value of bespoke development becomes clearest. No off-the-shelf platform could have met this brief: Not because the technology required was exotic – WordPress, cURL, PWA manifests, and a well-specified API are all mature, well-understood tools – but because the brief required every architectural decision to serve a specific, non-negotiable set of security and operational requirements.
The challenge was not writing clever code. It was thinking clearly about data residency, access control, encryption scope, and user experience simultaneously, and building a system where all four were in alignment. When you are building for delegates who expect the highest standards of discretion – and who will notice immediately if those standards are not met – there is no room for assumptions.
The platform ran without incident across the full duration of the event. Delegates used the messaging system extensively. The transfer coordination module worked precisely as intended. The PWA was, by several accounts from the organising team, one of the most appreciated elements of the entire event experience.
That is what good architecture looks like in practice: Not visible, not remarked upon, simply there – reliable, fast, and absolutely private.
—
Web Inclusion builds bespoke, mission-critical web applications for organisations where operational integrity and discretion are non-negotiable. If you have a project where off-the-shelf simply will not do, let’s talk.