Beyond Ordinary was brought in to write the server and advise on a multi-year technology plan for a pre-IPO biotech. We built a Laboratory Information Management System on Jetty that pushed XML to the client and rendered it with stylesheets in the browser — an architecture that scaled with the company while everyone else was burning servers on template rendering. The client is now a multi-billion-dollar publicly traded biotech.
For biotech, pharma, and research-org leaders who need lab systems that grow with the company.
Architecture that survived the IPO. Tech choices that earned their keep.
Sample tracking, instrument data capture, workflow orchestration, results reporting — the core LIMS surface that lab scientists, ops, and downstream analytics teams all relied on. The client was racing toward IPO; we were the team responsible for making sure the systems behind the science wouldn’t become the bottleneck. They didn’t.
Both decisions cut against the conventional wisdom of the early 2000s. Both turned out to be the right ones — and both reduced the bill the client had to pay for hardware, licenses, and operations as they scaled.
We sent raw XML to the client and let the browser render it through stylesheets. In an era when most shops were doing JSP- or ASP-style server-side templating — an operation that turned out to be surprisingly expensive at the time — we moved that work off the server entirely.
The result: the same backend hardware could serve far more concurrent lab users than a server-rendered equivalent. The client’s capacity ran ahead of their hiring curve, not behind it. Nobody else was doing this at the time; it took a while for the rest of the industry to catch up.
The conventional pick in the early 2000s was JBoss or WebLogic — heavyweight application servers with sprawling configuration, large security surfaces, and license fees to match. We picked Jetty instead.
Jetty was small, easy to configure, easy to deploy, and inexpensive. The features the LIMS actually needed were there; the features it didn’t need weren’t a security liability waiting to happen. The client got a server stack they could reason about, harden, and operate — not a vendor relationship.
Pick servers that fit the load — not servers that signal seriousness. Choosing Jetty in the JBoss/WebLogic era felt risky to people who confused weight with rigor. It wasn’t. The pattern repeats every decade with whatever the heavyweight pick currently is. Picking the right-sized tool is a discipline, not a style.
Push work to the client when the client has the budget. User machines were getting more capable; server cycles were the expensive resource. Moving template rendering to the browser was an architectural arbitrage — we’ve been making analogous calls ever since, with whichever resource happens to be cheapest at the time.
Architecture choices have multi-year consequences. The decisions we made in early-2000s engagements still showed up in client codebases a decade later. That’s why we advise on technology plans, not just write features. The right call early compounds; the wrong one taxes everyone downstream for years.
Whether you’re a biotech racing toward a milestone, a research org modernizing instrument capture, or a regulated lab whose LIMS is now older than the people running it — we’ve been in this shape of problem before. Bring it to the 30-min call.