The unglamorous infrastructure tax every cross-border operator pays
Cross-border e-commerce gets romanticized as a growth game — new markets, new channels, new ad platforms. But anyone who has actually run an operation across time zones knows the real tax is operational friction: the tiny, recurring failures that eat thirty minutes here, two hours there, and compound into a team that spends its best hours re-doing work a machine should have remembered. A warehouse manager whose scanner layout resets after every OS update. A designer whose color-calibrated monitor arrangement flips after a laptop sleeps. A customer support lead juggling three regional dashboards that never open in the same place twice. None of these show up in a P&L line, which is exactly why they never get fixed — and why a $19 macOS utility that solves one sliver of this problem is worth reading as a case study rather than a product review.
Many Displays, built by indie developer Martín Acuña Lledó, is a small tool with a narrow job: remember your monitor layout and window positions per hardware configuration, and restore them automatically. On its face that has nothing to do with Shopify or Amazon. But the design decisions behind it — how it identifies hardware, how it stores state, how it prices, how it handles privacy — map almost one-to-one onto problems cross-border operators face in their own tooling stacks. That’s the lens I want to use here.
What problem it actually solves (and why it’s harder than it sounds)
The founder’s origin story is almost comically specific: two identical LG 4K monitors that swapped places after every sleep, with every window piling onto one screen. The root cause is a genuinely nasty piece of systems trivia — many monitors ship with the same EDID serial, so macOS literally cannot tell two identical panels apart. DisplayPort monitors also “disconnect” when the Mac sleeps, which means the OS re-enumerates them on wake and has no reliable memory of which was which.
Many Displays solves this by keeping one saved layout per combination of displays. When you plug into a given desk, it recognizes that configuration and restores arrangement, resolution, rotation, and HDR first — then puts every window back where it belonged. It distinguishes identical monitors by system UUID first, then by physical port (on Apple Silicon), and only falls back to position if those fail. In the comments, the founder confirms it handles multiple locations — three desks, three separate remembered layouts, nothing to manually save or pick, with new setups seeded from the closest known configuration.
There’s a real engineering choice buried in there that most users will never notice: it reads the window server’s list directly — roughly 20 ms for hundreds of windows — instead of querying every app through Accessibility APIs. That means a busy or hung app can’t stall the restore. For anyone who has watched a “smart” automation tool freeze because one background process stopped responding, that’s the difference between a tool you trust and a tool you disable.
Why this is a state-management problem, not a display problem
Strip away the macOS specifics and this is the same architecture every serious operational tool needs: fingerprint the environment, store state keyed to that fingerprint, restore deterministically, degrade gracefully when the fingerprint is ambiguous. That’s precisely what a good multi-warehouse inventory system does, what a multi-storefront pricing engine does, and what a returns portal does when it has to reconcile the same SKU across three marketplaces. The display-swapping bug is just a vivid, low-stakes example of what happens when your system can’t tell two identical-looking things apart.
How it differs from the incumbents you’d actually compare it to
The obvious comparison set is the macOS window-management category. Rectangle is the free, open-source standard for keyboard-driven window snapping — excellent at placing windows, but it doesn’t persist layouts across display changes. Magnet does the same snapping job for a one-time App Store price. Neither is really trying to solve the “identical monitors swap after sleep” problem; they’re input tools, not state-restoration tools.
The closer competitor is Display Maid, which saves and restores window positions per display configuration — genuinely the same problem space. The differentiator Many Displays claims is the identical-monitor disambiguation via UUID and physical port, plus the window-server read path that avoids Accessibility stalls. Whether that holds up across docks and three-plus-monitor rigs is exactly what the founder is asking testers to break.
Then there’s the pricing and licensing posture, which is where this gets interesting for operators. It’s $19 one-time with a year of updates, after a 14-day trial with no account required. No network calls, no analytics, and the source is on GitHub under the FSL, converting to MIT after two years. Compare that to the prevailing SaaS norm — Setapp bundles, subscription-only utilities, telemetry-by-default — and you’re looking at a deliberately old-school model: pay once, own the binary, audit the code, no phone-home.
The licensing model is the actual product lesson
For a cross-border seller, the FSL-to-MIT structure matters more than the window math. When you’re stitching together a stack across Shopify, Amazon Seller Central, and a fulfillment provider, vendor lock-in is a slow-acting poison. A tool whose source you can read, whose network behavior is verifiably zero, and whose license eventually opens up is a tool you can build operational muscle memory around without fearing a pricing rug-pull or an acquisition that kills it. That’s not a small thing when your team has standardized on it.
What cross-border sellers can borrow from it
1. Fingerprint by stable identity, not by appearance
The core lesson: two things that look identical are not the same thing. macOS failed because it matched monitors by EDID serial, which is often duplicated. Many Displays fixed it by layering identity signals — UUID, then physical port, then position as fallback. Every operator with multi-channel inventory has felt the analog: the same SKU listed on Amazon, TikTok Shop, and Temu with slightly different titles, images, and identifiers, and a reconciliation process that assumes they’re “the same product” because they look the same. They aren’t — they’re different listings with different fees, return policies, and ranking histories. Build your internal SKU mapping the way this tool builds monitor identity: a primary key, a secondary physical/logistical key, and a documented fallback. Never let “it looks the same” be your join condition.
2. Read the cheap source of truth, not the expensive one
The window-server read (~20 ms for hundreds of windows) versus per-app Accessibility queries is a masterclass in choosing your data path. The expensive path is more “correct” in theory but stalls under load. The cheap path is fast and resilient. Cross-border operators make this trade-off constantly and usually get it wrong — pulling real-time inventory from every marketplace API on every page load instead of syncing to a local ledger and reading from that. The tool’s choice is the right default: maintain a fast local state, reconcile against the authoritative source on a schedule, and never let a slow third-party call sit in the critical path of a user-facing action.
3. Price for trust, not for extraction
$19 one-time, a year of updates, no account, no analytics, source available. That’s a pricing model that says “I want you to adopt this and forget about it.” Most B2B SaaS aimed at e-commerce goes the other way — seat-based, usage-based, upsell-gated. There’s a place for both, but the operators I respect most are increasingly allergic to tools that require an account just to try, or that meter the exact feature that made the tool useful. When you evaluate your own stack this quarter, ask which vendors would survive a “no account, no telemetry, pay once” test. The ones that wouldn’t are the ones you’re renting your operational memory from.
Why Amazon sellers should care more than Shopify ones
A Shopify DTC operator typically works from one or two screens in one office. An Amazon FBA brand owner with a Helium 10 dashboard, a Seller Central tab farm, a Keepa window, and a Klaxoon-style ops board open across a multi-monitor rig is exactly the user whose layout collapse costs real money — because the cost isn’t the thirty seconds of rearranging, it’s the mis-click on the wrong campaign or the wrong SKU that follows. Window-state loss is a small bug with an outsized blast radius when the windows in question control ad spend.
Where my judgment says it falls short
Let me be blunt about the limits, because the founder himself invites it — he explicitly asks for setups where it fails: docks, three or more monitors, odd Spaces configurations. That’s an honest signal, but it’s also a warning label. Multi-monitor-plus-dock is the normal configuration for a serious operator, not an edge case. If the tool is still soliciting failure reports on exactly that setup, it isn’t yet a “set and forget” purchase for a team standardizing on it.
The platform lock is the bigger issue. This is macOS-only. Your warehouse ops lead is probably on Windows. Your customer support team might be on Chromebooks. A tool that solves a universal operational problem for exactly one OS is a personal productivity win, not an organizational standard — and cross-border teams are, by definition, distributed across devices and geographies. The FSL license is a genuine plus for auditability, but “source available under FSL” is not the same as “open source you can fork today”; the MIT conversion is two years out.
And the honest framing: this is a $19 tool solving a $19 problem. It is not going to move your conversion rate or your ad ROAS. The reason it’s worth an essay is not the product’s impact — it’s the design pattern. Don’t buy it expecting operational transformation; buy it (or don’t) because the way it thinks about identity, state, and trust is a template you can apply to tools that do move the needle.
Where the math breaks
The one-time-plus-a-year-of-updates model has a known failure mode: update revenue dries up, the developer moves on, and your “owned” binary slowly rots against new macOS releases. The FSL safety valve helps — after two years the code is MIT, so the community can maintain it — but “can” is doing a lot of work in that sentence. For a solo indie developer (the founder also makes Tangible), this is a sustainable hobby-scale business. For a team betting its workflow on it, it’s a dependency with a single point of failure. Price accordingly in your risk model.
What I’d watch / test next
Three concrete things an operator can do this week, none of which require buying anything:
- Audit your own “identical monitor” problems. List every place in your stack where two things that look the same are joined by appearance rather than a stable key — duplicate SKUs across marketplaces, near-identical campaign names, overlapping customer records across regions. That list is your real reconciliation debt, and it’s bigger than you think.
- Run the “no account, no telemetry” test on your current SaaS. For each tool your team touches daily, ask: can I try it without an account? Does it phone home? Would it survive a pricing change? Flag the ones that fail. That’s your lock-in exposure.
- If you’re a Mac-shop operator with a multi-desk setup, the 14-day no-account trial is a free way to stress-test the dock and three-monitor cases the founder is asking about — and to see whether the “cheap read path” philosophy holds up under your real workload. Report back to him; that’s how small tools get good.
The broader watch item: whether the FSL-to-MIT model spreads. If more indie utility developers adopt “pay once, source available, converts to open” as a default, the long tail of operational tooling gets meaningfully more trustworthy — and cross-border operators, who live and die on the reliability of a dozen small tools stitched together, are the biggest beneficiaries.
