The problem

Setting up a new starter meant creating accounts in Slack, Atlassian, Keeper and Dialpad by hand, one service at a time. It was slow, easy to get half-done, and exactly the kind of repetitive work worth removing.

The catch was the plans. The clean way to do this is each service's provisioning API, but those sit behind tiers the company wasn't on — Slack's admin.users:write needs Enterprise Grid, Keeper's SCIM needs Enterprise. So the interesting part wasn't wiring up four APIs. It was working out what to do when most of them were out of reach.

How it works

An Express backend with one connector module per service, and a React front end that reads the list of available services from the backend rather than hard-coding them. Each connector uses the best method its plan actually allowed:

• Slack — no admin scope, so it emails the person a workspace invite link through Microsoft Graph.
• Keeper — no SCIM, so it drives the Keeper admin console with Puppeteer over Edge's remote debugging port.
• Atlassian — the Jira Cloud REST API works on every plan, so this one is a direct call.
• Dialpad — a direct REST call on the Business plan.

What I'd change

The Keeper connector is the honest weak point. Driving a web console with a headless browser works, but it's fragile: it breaks the day Keeper changes their admin UI, and it depends on a login session staying alive. It was the right call given the plan, not the right call in the abstract. The day someone paid for SCIM, I'd throw it away and not miss it.

The design that made me happiest is the connector interface. Adding a service is a new file exporting isConfigured() and invite(), and the front end picks it up on its own. That part I would keep.

The problem

A lot of Exchange Online administration is half-remembered PowerShell. Checking which domains are configured, testing whether external-sender tagging is working, fixing a mailbox timezone, auditing settings across accounts — each is a cmdlet or two, but the kind you look up every time because you don't run them often enough to memorise.

I wanted the common ones in one place, runnable without opening a shell and reconstructing the syntax.

How it works

A set of PowerShell tools behind a local web UI, launched from one script. Each tool is a tab: search, domain and external-domain checks, external-tag testing, timezone fixes, an audit-settings view, and a couple of destructive ones (mailbox and calendar-entry removal) kept clearly separate because they don't undo.

The web front end matters more than it sounds. A form with named fields is harder to get wrong at 4pm than a raw cmdlet, and it means someone who isn't fluent in Exchange PowerShell can still run the safe operations.

What I'd change

The destructive tools need a confirmation step that makes you type the target back, not just click. They work, but "click to delete calendar entries" is one bad afternoon away from a mistake, and a UI that makes the dangerous action as easy as the safe one is a UI with the wrong emphasis.

Built for use only against devices and networks I own or have explicit permission to test. Several features actively change routing, ARP or DNS behaviour, or emulate other hardware, and are meant to be treated with the same care as any pentesting tool.

What it is

I kept reaching for the same handful of tools — nmap, tshark, John the Ripper, BlueZ, traceroute — and running each from its own terminal with its own flags. Zippy puts them behind one interface: a black-and-red, BIOS-styled desktop GUI, with each tool as a tab. The UI is plain HTML, CSS and JavaScript rendered through pywebview on GTK and WebKit, so it's a real desktop app rather than a browser tab or an Electron bundle.

Most tabs wrap an existing tool. A few are built from scratch where nothing quite fit: ARP and NDP spoofing to route a target's traffic through the machine, DNS-spoof-based redirection, Bluetooth HID emulation, and rogue-DHCP probing.

Some of what it does

• Nmap scan — service and version detection, OS fingerprinting, NSE scripts, whole-subnet scans.
• Device Monitor / Kill — ARP/NDP spoofing to observe a target, cut it off, or redirect every domain except a chosen one to a local server.
• Website Activity — which hostnames a device is actually reaching, from its DNS queries and TLS SNI.
• Rogue DHCP detection — broadcasts a discover and flags more than one distinct server answering.
• Password audit — real John the Ripper against pasted hashes with a wordlist.
• HID remote control — registers the machine as a Bluetooth HID keyboard so a paired device can be sent single, explicit key presses.

Privileges

The privileged features rely on things that only exist on Linux — AF_PACKET raw sockets, ip_forward, D-Bus and BlueZ. Rather than run the whole app as root, each privileged action prompts individually through polkit's pkexec. The app itself never runs as root. run.sh detects and installs missing dependencies across dnf, apt, pacman and zypper, so it comes up on most desktop distros without hand-holding.

The part I'd flag

The Bluetooth HID tab is the newest and least-proven, and I've written it up that way rather than hidden it. BlueZ's peripheral-role HID registration over D-Bus is a sparsely documented, version-sensitive corner, so behaviour varies by distro. It's confirmed working against a Steam Deck — I caught a successful pairing and key-press round trip in a btmon capture — and general phone pairing, but not yet against Windows, Android-as-host, TVs or consoles.

Two real bugs turned up through hardware testing rather than code review: a "UUID already registered" conflict, fixed by consolidating to a single profile registration with a combined SDP record; and a "PSM not supported" refusal, fixed by binding raw L2CAP sockets directly instead of relying on BlueZ's Profile1.NewConnection. More hardware will probably surface more.

Some limits are deliberate rather than unfinished: single key presses only, no text-typing or macros, no mouse. That was a scope decision — I wanted a live interactive remote, not anything that looks like payload injection.

The repository is private, and given what several of the tabs do I intend to keep it that way. Happy to walk through the code in an interview.