JIT
NL
← Notebook
Opinion notes Open SourceArchitectureStrategy

Build like you'll have to leave

Closed software earns its place, but engineer the exit. The line that matters: a moderate lock-in you can leave, a super lock-in that owns you.

I keep coming back to one picture: a KMO finally off the closed-source treadmill, running on open-core and open source for everything its feature set allows. Not out of ideology. Closed software earns its place where it genuinely does the job better. But the thing that quietly sinks a small company isn’t a licence fee. It’s the day the vendor stops being a partner and becomes an anchor.

A moderate lock-in you can leave; a super lock-in owns you

Every dependency is a lock-in; the only question is which kind. A moderate lock-in you can engineer around: pull the box, port the config, move on. A super lock-in is total dependence on one vendor’s private feature set: your whole design only exists inside their product, and leaving means a redesign. The first is a cost you manage. The second is a hostage situation. The entire game is staying on the right side of that line.

Super lock-in total dependence on one vendor Your logic fused into the vendor's private feature set no seam to leave by leaving = a redesign Moderate lock-in vendor-agnostic by design Your logic on the standard · open contracts portability seam Vendor A Vendor B Vendor C swappable implementations leaving = swap the box
Same dependency, two shapes. Fuse your logic into a vendor's private features and leaving means a rebuild; keep it on the standard and the vendor is just the box underneath.

Build on the standard, not the vendor’s twist

You buy moderate lock-in by writing your logic against the standard, not the product. In networking that means leaning on the open standards every box speaks: VRRP, OSPF, BGP, 802.1Q. And refusing the proprietary twist on each one: HSRP, a vendor’s stacking fabric, the “squashed” L2/L3 magic that only lives behind one IOS or EXOS feature flag. Same topology. But now Cisco, Juniper, UniFi and a white-box are interchangeable implementations under a seam you control. The vendor is a tenant, not the foundation.

Your logic, written to the contract, not the vendor standards · interfaces · your test harness, the part you own and keep portability seam, everything below is a swappable implementation Networking, build on the RFC VRRP · OSPF · BGP · 802.1Q open standards any box speaks Cisco Juniper UniFi white-box AI agents, build on the harness harness · tool contracts · evals yours, the model is a slot Claude local open-weight other Swap the implementation by policy or cost, your logic above the seam never moves.
One pattern, two domains. Keep your logic on the contract; let the vendor, a switch or a model, be the interchangeable layer underneath.

The same trick for the AI

It transfers straight to agents. Build the agent logic on top of your own infrastructure logic and a real test harness (the prompts, the tool contracts, the eval suite are yours), and treat the model as a slot you fill. Then you run the model you want per task, not the only one you can: a local open-weight model for the bounded work, a frontier API for the hard call, hybrid by policy with the token bill under control. I wrote that out as “own the baseline, rent the bleeding edge.” It’s the same seam, one layer up, and it’s how the whole agent fleet is wired.

Why the ground is moving

This used to be a nice-to-have. Not anymore. The EU Cyber Resilience Act and NIS2 now push accountability for your software supply chain onto you, and a hard dependency on a partner in a less-than-friendly jurisdiction is a board-level risk, not a procurement footnote. And even a friendly vendor isn’t a constant. An election can turn the trade weather overnight. A founder-led company gets sold to a competitor or to private equity, and once capital takes the wheel from the engineers, the roadmap, the pricing and the support you signed up for can all change in a quarter. The reliable partner becomes the anchor, and you want to be able to cut the line first.

Build for a moderate lock-in you can leave. Never sign up for a super lock-in that owns you.

None of this is anti-vendor. It’s pro-exit. Keep the seam, keep your logic on the standard, and “should we migrate?” stays an engineering decision instead of a hostage negotiation. That’s the homelab I build, and the future I’d build for a KMO.