Corporate Communication Platform

Who was your client

A confidential enterprise client building an internal communications system for government-sector organizations. This was the first project we built together — the relationship has since grown into a long-term partnership, with more projects delivered since.

End users: a cross-section of the organization, from entry-level staff to senior leadership.

We worked closely with the client's team — designers, developers, business analysts, and product owners.

What was the client's request for collaboration

The client came to us with a legacy, web-only email tool that was falling short of what an organization-wide communication hub needed to be. It was tied to a browser, offered no offline mode, and wasn't built to run consistently across the range of hardware used throughout the organization.

Documented goals for the new build:

• • Deliver a fully offline-capable email application to ensure uninterrupted productivity

• • Ensure high performance across devices, including older hardware

• • Provide a consistent cross-platform experience across Windows, macOS, and Linux

• • Use a shared web/Electron codebase to reduce development and maintenance cost

Our initial scope of work: a complete product redesign and rebuild — UI/UX from scratch, and a new React/Electron codebase replacing the legacy web version.

What is the client's bigger business goal

A unified communication hub — mail, calendar, and contacts — for daily operations and team collaboration, replacing a legacy system with an offline-first architecture that ensures uninterrupted productivity.

At what stage was the client's project

What the client had:

• • A working legacy product — existing web-only email/calendar/contacts tool

• • Their own Tailwind-based design system

• • Documented goals and constraints (offline capability, cross-platform reach, shared codebase, performance on older hardware)

• • Internal teams (design, development, business analysis, product) available for coordination throughout

What was missing:

• • A desktop application — no native experience on Windows, macOS, or Linux

• • Offline support

• • A shared codebase strategy to avoid maintaining desktop and web as separate products

• • A platform redesign that brought the interface in line with their design system

What was the expected outcome of the contract

For end users:

• • Work in mail, calendar, and contacts with or without a connection

• • A native app on Windows, macOS, or Linux, alongside the existing web version

• • Consistent experience across devices, including older hardware

For the business:

• • One shared codebase instead of separate desktop and web builds — lower long-term maintenance cost

• • Offline-first reliability with background synchronisation

• • A modular foundation (Mail, Calendar, Contacts, multi-category search) that can absorb evolving requirements

How the result was measured

Direct user interviews and live analytics weren't available during the design and build phase, due to access limitations.

To de-risk decisions without that access, the team leaned on:

• • Competitive analysis of leading email/calendar platforms

• • Close work with the client's Business Analysts, translating requirements and feedback into concrete design decisions

• • Cross-functional coordination with the client's design, development, and product teams to balance user needs against technical constraints

Before handoff, stakeholders and the product team reviewed and signed off on the design direction.

How the collaboration went

Duration: 18 months.

Synterra side: a cross-functional team — UX/UI design, frontend development, and backend development — carrying the project from research through to a production-ready build.

Client side: designers, developers, business analysts, and product owners, working alongside us throughout the project.

How it worked day to day:

• • A feature was designed in high-fidelity, then sent for review

• • Feedback came back, revisions were made

• • Once approved, the feature moved into development — reviewed by the client's development team — while the next feature was already being designed

Design and development ran as a pipeline: as soon as one feature was approved, it moved into development while the next feature entered design.

This project was the start of the relationship with this client — it has since grown into a long-term partnership, with several more projects delivered together since.

1. Offline-first architecture — designing an experience that works seamlessly with or without an internet connection.

2. Performance with shared codebase — maintaining strong performance with large mailboxes while keeping RAM/CPU usage low, on a single React/Electron codebase.

3. Native feel across three operating systems — delivering a UI that feels native on Windows, macOS, and Linux from shared code.

4. Evolving requirements — adapting to dynamic project requirements as features and user needs changed during the build.

5. Multi-parameter search — building an advanced search that lets users filter and combine multiple parameters at once, without the interface becoming overwhelming.

6. Threads — getting email threading right so conversations stayed readable and easy to follow, rather than a flat, hard-to-scan list of messages.