Week in review: sign-in, search, and a clearer paper trail on every container

This is the first in what is meant to be a regular weekly habit: a short, plain-language look back at what actually shipped on ZQX in the last week, written for anyone using or considering the platform rather than for other engineers. It will not read like a changelog. It will not walk through how anything was built. The point is simply to keep the people who rely on ZQX, or are deciding whether to, in the loop on what changed and why it matters to them, at a level of detail that respects both their time and the fact that not every implementation decision needs to be made public to be worth knowing about.

The most visible change this week was to how people sign in. Previously, a returning user landed on a page offering several sign-in methods at once, laid out with roughly equal visual weight, which made the common case, a returning user typing their password, more cluttered than it needed to be. Sign-in is now a single, clear entry point: the common path is right there, and every other supported method, including passkeys and one-time codes sent by email, sits behind a plainly labelled "more ways to sign in" option for anyone who wants it. Nothing was removed. The methods that were available last week are all still available. What changed is which one is presented first, and how much visual noise a returning user has to wade through to get back into their account.

Alongside sign-in, we shipped fast, cross-entity search, available from anywhere in the application with a single keyboard shortcut. Before this, finding a specific container, booking, or job usually meant navigating to the right section first and then filtering or scrolling. Now, typing a reference, even a partial one, from any screen surfaces the matching record directly, regardless of which part of the platform it belongs to. For anyone managing more than a handful of active containers at once, this is a genuine change in how quickly a specific record can be found, not a cosmetic addition.

A less flashy but arguably more important change went into how communication around a container is recorded. ZQX now keeps a proper log of correspondence tied to the container it concerns, visible on the relevant detail pages, rather than leaving that history to live in someone's email inbox or a phone call nobody wrote down. This matters most when something goes wrong later and the question becomes who was told what, and when. A platform that computes a container's status from evidence and holds is only as trustworthy as the record behind it, and a documented communication trail is part of that record, not a nice-to-have layered on top of it.

On the operational side, a Job that had already been marked complete can now be reopened when that turns out to be premature, rather than requiring a workaround or a support request to correct. This is a small change in scope but a meaningful one in practice: operations do not always finish cleanly the first time, and the platform now reflects that reality instead of treating "complete" as an irreversible dead end.

It is worth being explicit about why a change this small is worth mentioning at all in a weekly recap otherwise focused on bigger, more visible work. A platform that tracks operational status for a living has to be honest about the fact that real operations are messy: a job gets marked done before a discrepancy surfaces, a container gets released before a late hold clears, a step gets recorded out of order because the person recording it was standing at a gate, not a desk. The measure of a good operational system is not whether it prevents every one of those situations, which is not realistic, but whether it gives someone a clean, accountable way to correct the record when one happens, rather than forcing a workaround that leaves the true history harder to reconstruct later.

Transport leg detail pages now show the cargo content associated with each leg directly, rather than requiring a lookup elsewhere to answer a question as basic as "what is actually in this leg of the move." Saved views, the filtered lists people build to track the specific slice of containers or jobs they care about, can now be renamed in place instead of having to be recreated from scratch when a name stops fitting what it has grown to track. Neither change is dramatic on its own. Both are the kind of friction that adds up over months of daily use, and both came directly from real usage rather than from a speculative feature list.

We also added a straightforward way to reach us from inside the product itself: a collapsible contact widget for reporting a problem or asking a question, available wherever you are in the application rather than requiring a detour to a separate support channel. For a platform still earning trust in a market used to picking up the phone, making it easy to reach an actual person when something looks wrong is not a minor detail.

On the platform side, work went into a controlled way of rolling features out to specific regions rather than switching them on everywhere at once. This is largely invisible to any single user, but it is what allows a change to be tested carefully against a smaller, defined group before it reaches everyone, which matters more as the platform's footprint grows across different operating environments and regulatory contexts.

A meaningful share of this week's work was not user-facing at all, and is worth naming precisely because it will not otherwise show up anywhere: platform hardening. Automated secret scanning and push protection are now enabled across the codebase, catching credentials before they can be committed rather than after. Continuous integration checks, the automated tests and verifications that run against every change before it can ship, were moved onto infrastructure we control directly, which reduces reliance on shared third-party build capacity and gives us more headroom to run those checks thoroughly rather than sparingly. Neither change adds a feature anyone will click on. Both reduce the odds of an avoidable mistake reaching production, which is exactly the kind of investment that only shows its value on the week it prevents something from going wrong.

We also spent time building a proper staging environment, a separate, production-like copy of the platform where a change can be exercised end to end before it reaches anyone actually running operations through ZQX. Until this week, most verification of a nontrivial change happened either in a local development setup or, further along than it should, in production itself. A working staging environment closes a real gap in how carefully changes can be verified before they matter, and it is the kind of infrastructure work that is easy to defer indefinitely and genuinely worth not deferring.

The page you may be reading this on is itself part of this week's work. We built an ecosystem updates hub, gathering what has actually shipped across every part of ZQX in one place, generated from our own real development history rather than hand-maintained as a separate marketing artefact that quietly drifts out of date. It is also, not coincidentally, what makes a habit like this weekly recap sustainable: a single source that already knows what shipped, rather than a founder trying to reconstruct a week from memory every Friday.

None of the above is a claim that every one of these changes is individually significant. Some, like the sign-in redesign and cross-entity search, will be immediately obvious to anyone using the product day to day. Others, like the staging environment and the platform hardening work, are quietly foundational and will mostly be noticed by their absence if something ever goes wrong that they would otherwise have caught. Taken together, they describe a platform that is being built the way a solo-founder-run, operationally serious product should be: carefully, incrementally, and with a bias toward the boring infrastructure work that makes the more visible features trustworthy rather than merely impressive. That bias is deliberate rather than a resource constraint dressed up as a virtue: a platform asking operators to trust a computed status over a phone call has to earn that trust in how it is built, not only in what it displays on screen, and this week's mix of user-facing and infrastructure work reflects that ordering of priorities rather than an accident of what happened to be ready to ship.

That is the shape this weekly post is meant to take going forward: what changed, why it is worth knowing about, and enough honesty about scope that a quiet infrastructure week reads as a quiet infrastructure week rather than being padded out to look more exciting than it was. If you want the fuller, always-current picture between these weekly posts, the updates page linked above reflects what has shipped as it ships, across every part of the platform, not just the parts that make for an easy headline.