Skip to content
Version 2Active developmentInfrastructure completeDesktop application under construction
Building LynxDock

Engineering Journal

What we built, what problem it solved, and what we learned. Dev logs from the codebase, founder updates on where the company is going, and research notes from the bench.

Type
Topics

22 articles

LatestEngineering

Squadron Control grows an operations layer

In one focused stretch, the tactical board went from an empty section of the new client to a full operations platform: units, wings, orders, alerts, zones, formations, snapshots, mission templates, undo, a permanent audit log with time-travel replay - and then an operations layer on top: multi-waypoint routes you can edit like vector paths, advance in real time, and command from a live roll-up. Here's what we built and the architecture that made it fast to build.

7 min read

Read article
Engineering

A settings system built like a platform, and a week of polish

Settings grew from four toggles into a 20-category, searchable system with Basic and Advanced modes - where every setting the platform will ever expose is declared, and the ones whose subsystems haven't shipped are shown honestly as planned instead of faked. Plus: replies, custom status, readable errors, and an accessibility and performance pass across the client.

5 min read

Founder Journal

LynxDock applies for NSF research funding

We've submitted a Project Pitch to America's Seed Fund (NSF SBIR) to fund research into the hard problems under LynxDock: real-time state synchronization, large multi-party voice, and self-healing operability on affordable self-hosted hardware.

2 min read

Release

Internal Alpha: stress-testing LynxDock's networking layer

Our version 2.2 networking stack was built and unit-tested, but no one had watched it work end to end. So we ran a live verification pass across three simultaneous clients - server restarts, offline queueing, reconnection, and a concurrency stress test - then hardened the one real defect it surfaced before tagging the release. Here is what we tested, what held, and what we fixed.

6 min read

Founder Journal

Our roadmap was wrong. The code proved it.

Our public roadmap said networking and voice hadn't started yet. The repository contained working, tested implementations of both. We nearly corrected the wrong side - deleting real shipped work from the record because an official-looking document said it didn't exist. Here's the rule we adopted instead.

5 min read

LynxBench

Repair knowledge dies with the people who hold it

Almost everything known about repairing a given board lives in a few people's heads and a scattering of forum posts. When they go, it's gone. LynxBench is our attempt at the opposite: a hardware knowledge graph, evidence-based diagnostics, PCB mapping, and a troubleshooting process that actually repeats.

6 min read

AI

The failure your code review cannot catch

Our tooling reported changes to files nobody had touched. The cause wasn't a bad AI suggestion - it was an environment quietly serving truncated files, so every tool downstream measured the wrong thing. Review can't catch that, because review reads the same corrupted input. Here's the process we built instead.

5 min read

Security

We stopped trusting filenames

Rename an executable to holiday.png and most systems will happily treat it as a picture. LynxDock now reads the file's actual content signature and refuses anything whose bytes disagree with its claimed type - enforced at the storage layer, with a test that proves it says no.

3 min read

Engineering

Voice and screen sharing, end to end

Real-time audio and screen sharing are done, delivered in five phases - from the call roster all the way through connection-quality indicators.

5 min read

Release

Mission Control: one honest view of the system

A shared status contract, a hub every module reports into, and an event timeline - so the state of the system is observable instead of guessed at.

5 min read

Engineering

Watching the work: session observability in Studio

Development sessions used to disappear into chat history. Now they report into the same hub as the server and the desktop app.

4 min read

Release

Version 2 comes to life: messaging, voice, and sync

The local-first foundation is now a connected app. In the last few days LynxDock gained networked messaging, offline sync, real-time voice and screen sharing, and instant full-text search.

5 min read

Engineering

Why we chose Rust

Privacy and performance aren't slogans - they're architectural choices. Here's why the LynxDock core is written in Rust.

4 min read

Engineering

Genesis UI: building our own component framework

One design language across the website, the desktop app, and Studio - powered by tokens, a theme engine, and a Tailwind preset.

4 min read

Founder Journal

Building a privacy-first platform

Privacy isn't a setting you toggle at the end. It's the constraint that shapes the architecture from the first commit.

4 min read

Founder Journal

Introducing LynxDock

Why we're building a privacy-first ecosystem for communication, development, and automation - and what comes next.

3 min read

Engineering

The Genesis of lynxdock.app

How this website came together - a lightweight, static, mission-control design that feels like an extension of the app.

2 min read

Founder Journal

Why self-hosting matters

The communities people rely on shouldn't be one policy change away from disappearing. Self-hosting is how you keep control.

3 min read

Founder Journal

Why privacy-first, and why now

Privacy isn't a feature we bolt on at the end. It's the constraint we design everything around from the start.

4 min read

Founder Journal

The road ahead: our epic roadmap

We've moved from milestones to epics. Here's the honest sequence from a local app to a full communication platform.

3 min read

Engineering

Self-hosting without the headache

Running your own server used to mean config files and terminal commands. The Guided Setup wizard makes it a few clicks.

4 min read