CASE STUDY · SECURITY AND IT LEADERSHIP · AI CONSULTING

One sign-in. One page. Every signal an employee needs to start the day, pulled from twelve systems across nine sites in three countries. Built, secured and shipped by one person in under six weeks, on a hosting bill of roughly ten dollars a month.

Client: INNOVA, an HVAC manufacturer with offices in Israel, the United States and Canada  ·  Role: IT Manager, sole architect and developer  ·  Delivered: September 2026, in daily use

THE PROBLEM

An employee at INNOVA starts the day in Google Workspace for mail, Quo for calls and voicemail, Salesforce for cases, HiBob for time and HR, Jira for IT tickets, Slack for messages, Confluence for how-to pages, and a folder of static HTML for training. Each has its own URL, its own sign-in, and its own idea of what is waiting for that person. Nobody sees a consolidated view of their own outstanding work.

Three things made this expensive rather than merely annoying:

• Status-chasing. If you can't see the state of your ticket, you message IT. If you can't see whether HR still needs a signature, HR messages you. Every one of those messages is a context switch for two people.
• Shared inboxes broke identity. Roughly 17 staff in concierge and support departments sign in to shared mailboxes. Google cannot tell them apart, so any Google-based SSO would resolve four humans to one account and let them punch the same clock.
• Onboarding started with an email. A new hire's accounts were provisioned only if somebody read the HR email in time. On a bad week the person arrived before the accounts did.

The brief was simple: reduce the number of places an employee has to go to do their job, without building yet another system that owns data.

WHAT IT DOES

The design principle that shaped every decision: aggregate signals, never own data. The portal shows counts and summaries, then deep-links into the system that owns the record. HiBob stays authoritative for people, Salesforce for cases, Jira for tickets, Gmail for mail. The portal holds user preferences and an audit log, nothing else.

DESKTOP

The home page. Greeting from the HiBob record, the clock in the header, tiles with counts, Drive search, guides, and the IT operations cards below for IT staff.

MOBILE

The same page on a phone, installed as an app. The tile row sheds sub-text, then labels, then collapses to icon and badge. Layout stability over information density.

THE BUSINESS CASE

The project was sponsored by the Business Systems Director and built inside the existing IT role. No budget request, no new headcount, no new hosting. The value shows up as time returned and risk removed.

SECURITY BY DESIGN

A portal that can clock people in, read mail and move computers between security groups is a target. The SSDLC document for this project runs to eleven sections and an integration inventory listing every connection, its identity, its exact permissions and what it reads and writes. The controls that matter most:

• The magic link goes to the address on the HiBob record, never to an address in the request. This is the single control the whole identity model rests on.
• Tokens are single-use, short-lived and bound to one employee ID. Sessions are rows in Postgres, so revocation is immediate and a signed-out session cannot be replayed.
• Enumeration resistance. The claim step returns the same response whether or not the identifier exists. The portal cannot be used to find out who works here.
• Privileged access is portal-side. Admin rights live in a portal group table, never derived from a HiBob field, so editing an employee record can never grant administration.
• Least privilege on every integration. One HiBob service user in its own permission group; separate Google service accounts for the portal and for provisioning; a guest Confluence account scoped to one space; a read-only Salesforce permission set; per-person Slack tokens that the person grants themselves.
• Data minimisation. Mail is metadata only unless the person asks. Slack is counts and names, never text. Leave type is stripped server-side before it reaches any screen, TV or the assistant. No document contents are ever rendered.
• No silent success. Anything the portal cannot complete becomes a visible task. A partially provisioned starter looks partially provisioned.
• Pre-deploy gate. Syntax, module loading, imports, undefined names, page scripts, migrations and the lockfile are checked as the Railway build step. A failure stops the deploy and the live version keeps running.
• Content-Security-Policy, signed webhooks, append-only audit log, and an assistant usage log that records every question, every tool step and the outcome for 90 days.

UNDER THE HOOD

• Node 20 and Express, Postgres, hosted on Railway, deployed from main on every push
• Signed cookie sessions in Postgres; TOTP MFA; QR scan-to-sign-in
• 44 SQL migrations applied once, in order, at boot
• Installable PWA: service worker, offline shell, push notifications, versioned assets
• Live updates over a server-sent channel that carries only a "something changed" signal; each page fetches its own data with its own session
• Seven themes as swaps of the same CSS custom properties, remembered per person server-side
• PostHog usage analytics with private areas masked; typed text never captured

• HiBob: people, attendance, time off, tasks, equipment table, org chart; webhooks for joiners and leavers
• Google Workspace: Gmail metadata, calendar, Drive search, directory; nightly profile sync into WiseStamp signatures
• Slack: per-person unread counts, live message events, bot lookup for "message on Slack"
• Salesforce: seven read-only CRM views by department, cases, orders, products and pricing, service health
• Jira and Confluence: two ticket projects, one knowledge space, one token
• Quo: numbers, missed calls, voicemail, call-completed webhook
• ESET and Teramind: endpoint health, incidents, computers present in one and missing from the other
• Omada Central: network events
• Anthropic: Claude behind Ask INNOVA, with tools scoped to what the asker is entitled to see

HOW IT WAS DELIVERED

• Late August: interactive HTML prototype built and walked through with the sponsor and HR. HR approval recorded for clock in and out before a line of production code.
• SSDLC first: business drivers, scope in and explicitly out, user roles, integration requirements, security requirements and open decisions written down and versioned alongside the code. The document now lives inside the portal under Administration.
• Build, not buy, on identity: a managed identity layer was priced and rejected on cost and on shape. HiBob is a registry, not an identity provider; there was nothing to federate to.
• Stage-gated build: deploy pipeline first, then authentication, then the data layer, then the first tile with a real number. Nothing after stage one was started until the deploy path worked end to end.
• Daily production releases: 383 commits between the first production push and go-live. Every one deployed automatically and was verified against the live page, not against the push result.
• Feedback loop: a feedback button on every page routes bugs and requests to an IT card with who, when and which page. The sponsor's UX feedback shipped the same day it was given.

Fractional IT leadership, AI integration scoped securely by a CISSP, and the hands to build it. This portal went from prototype to daily use in one job, alongside the day job.