When the business doesn’t fit the software.

01 / The problem

Plant tissue culture is fundamentally different from conventional inventory.

The system needed to account for biological uncertainty, customer ownership, and commercial commitments together.

• A Service for Others: Customers provide source material to us with the expectation that we will turn it into a much larger quantity of finished product. That material remains associated with the customer throughout production, while the resulting inventory may pass through dozens of locations and production stages.
• Different Types of Service: Customers purchase different services, each with its own workflow, labor requirements, expected outcomes, and pricing. Some involve straightforward production; others require specialized processing or experimental techniques. The system needed to track the specific service agreed upon for each customer and apply the corresponding pricing and fulfillment rules.
• Physical Product Sales: We propagate our own material and sell seedlings to wholesale nurseries or via online retail outlets, often at agreed upon prices that may vary depending on the relationship. We wanted a way to track those agreements, collect deposits, accurately invoice customers, issue refunds, credits and gratis work.
• Uncertain Product and Fulfillment: Production outcomes vary dramatically. One production event might yield tens of thousands of units; another might yield only a handful or nothing at all. Customer orders therefore cannot be treated like conventional inventory reservations: fulfillment depends on what production actually produces. We needed to track expected output, actual output, customer commitments, deposits, and eventual fulfillment as one connected process.
• Trust, Ownership, and Information Boundaries: Customers were entrusting us with valuable source material, and there was understandable concern about laboratories propagating or selling customer-owned material without authorization. We therefore needed to track ownership and permissions while limiting unnecessary information about customer material to the people and processes that required it.
• Attributing Failure: When production failed, the cause mattered. A failure could originate in our own process, in how material was prepared or delivered by the customer, or in the underlying biological material itself. Those situations had different operational and commercial consequences. We therefore needed to record the best available explanation for failure and connect that information to customer agreements, pricing, deposits, and operational analysis. Over time, this also allowed us to distinguish recurring operational problems from problems inherent in particular inputs or production methods.
• Optimization: Growth rates, contamination rates, production techniques, and customer preparation practices all varied. We needed data to run experiments, identify patterns, understand failure rates, and determine which methods worked best.

These questions and problems aren't independent.

A change in production affects inventory. Inventory affects customer commitments. Commitments affect orders. Orders affect shipping and invoicing. And all of those processes depend on maintaining accurate identity and provenance throughout the production cycle.

The existing software available to the business treated these as separate problems.

Our business did not.

02 / Building the system

Building the System Around the Operation

We started with the operation itself, mapping the data model and the relationships between customers, materials, inventory, services, and invoices.

The resulting system, Culture Manager, became a shared operational database and application for the laboratory.

Every significant object in the business could be connected to the others.

• A customer could have an order.
• An order identifies the material a customer has ordered.
• Material is linked to a plant type with specific cultural requirements, including light and growing media.
• An order may be fully fulfilled, partially fulfilled, or not fulfillable, with inventory and fulfillment history retained.
• Inventory has a physical location, a production timeline, and quality expectations.
• When material becomes part of a shipment, the system retains its connection back through the entire chain.

This turned what had previously been a collection of disconnected records into a coherent model of the business.

03 / The physical operation

Making the Physical Operation Part of the Software

The work was not entirely digital. Each unit needed rich context: Latin names, customer identifiers, locations, dates, and growing media. Writing all of that by hand for hundreds or thousands of units was impractical.

People were physically moving units of inventory through the laboratory as they progressed through different stages of production. Material was being divided, moved between shelves, replated, evaluated, treated for quality, and eventually shipped.

The software therefore had to work in the physical environment rather than simply documenting what happened afterward.

We introduced barcode identification and scanning so that identifying material and recording its movement became part of the normal laboratory workflow.

The goal was to minimize data entry and administrative tasks while capturing the lifecycle information needed for analysis and operational decisions.

04 / Production to customer

From Production to Customer

Once the underlying operational model existed, other capabilities could be built on top of it.

Culture Manager connected production and inventory with:

• customer and order management
• batch and flask tracking
• barcode labeling and scanning
• contamination and quality tracking
• shipping manifests
• customer-facing order visibility
• pricing and customer rates
• invoicing
• reporting and analytics

The important part wasn't any individual feature.

It was that they all operated from the same underlying data.

A production decision could therefore become an inventory update. An inventory update could affect an order. An order could feed fulfillment and invoicing without requiring someone to reconstruct the information in another system.

05 / Learning and adapting

Designing for a Business That Changes

The system also had to accommodate the reality that Standard Orchid was still evolving.

There was no perfect set of requirements waiting to be implemented, and no perfect first version of the system. Using it in the laboratory revealed gaps, awkward processes, and the parts of the operation that were now running smoothly.

The business itself was learning what worked.

As the system made the operation more visible, our understanding of the business changed as well. We learned which customer agreements worked commercially, where pricing models broke down, which production practices generated better results, and where quality expectations needed to change.

That meant the software couldn't simply automate a fixed process. It needed to provide a foundation that could evolve as the business learned.

In fact, the relationship went both ways: better software produced better data; better data produced better understanding; and that understanding led to changes in the business that the software then needed to support.

Operational software is rarely finished when the first version launches.

The most useful systems become part of the organization's operating model and evolve as that model becomes better understood.

06 / The result

The operational backbone of the laboratory.

Culture Manager became the operational backbone of the laboratory.

More important than the time saved was confidence in what we were handling. We eliminated mistaken or misattributed material and labeling errors in our operation, avoiding the resulting risk of giving a customer the wrong product.

Instead of relying on disconnected spreadsheets, manual labels, separate systems, and institutional memory, Standard Orchid could maintain a common view of what was happening across production, inventory, customers, orders, and fulfillment.

At its peak, the laboratory was managing thousands of flasks simultaneously, with production cycles extending many months and potentially hundreds of thousands of eventual plants represented within those production workflows.

The system wasn't built because Standard Orchid wanted to become a software company.

It was built because the software market didn't adequately represent the business.

The details of Standard Orchid are unusual. The underlying problem isn't.

Many businesses reach a point where their processes have become more sophisticated than the systems supporting them. Information exists across spreadsheets, SaaS applications, databases, documents, and people's heads. Each system works reasonably well on its own, but the relationships between them aren't represented anywhere.

Standard Orchid gave us the opportunity to build a system around those relationships rather than forcing the business into the shape of an existing application.

We had to understand the workflow, decide what information mattered, build the underlying data model, design the user experience, deploy the system, use it in production, discover what we'd gotten wrong, and then change it.

That experience shaped how we approach technology work at Radix Paradigm.

We start by understanding how the business actually works.

Sometimes the answer is better process, integration, or better data. Sometimes an existing system can be extended. And sometimes the right answer is to build something new.

The important part is determining which problem you're actually solving before deciding what technology belongs in the solution.