Looking back over my career, a few projects stand out as the ones that taught me the most. Some of those lessons came years ago, on projects I still think about. One in particular taught me to question an assumption before spending money on it, and it is as good an example as any of what doing the right thing looks like in engineering.
It was a greenfield biopharma facility, and by the time the question came up, we were already in detailed engineering. The layout was finalized and a good part of the design and control philosophy was locked in. That is the phase where changes stop being cheap. So when the question landed about whether the final purification area needed an additional chromatography skid, it carried real weight. An extra step at that point would have rippled through the layout, the design basis, the schedule, and the cost. The team was understandably anxious about what it would do to overall capacity and timelines, and nobody wanted to reopen decisions that were already settled.
The easy answer and the better one
A lot of process modeling runs on default process descriptions and assumptions. There is nothing wrong with that. Defaults are usually conservative, and conservative is safe. If you size a purification train on cautious numbers and add equipment whenever the model says you are tight, you will rarely be wrong about capacity. You will just spend more than you had to, and sometimes you will spend it on steel and floor space you never needed.
The harder answer is to ask whether the assumption itself is true for this process, not for a generic one. That is the question I wanted to answer before anyone committed to a second skid.
What actually got checked
Whether a single chromatography skid enough comes down to cycle time more than anything else. If each cycle takes a long time, you fit fewer of them into the batch window, the step turns into a bottleneck for downstream, and the obvious fix is to add a second skid running in parallel. So the real question was not how much the column could hold. It was how long one cycle actually took.
The deciding detail turned out to be the elution. Gradient elution is usually designed and modeled to run over a set number of column volumes, the full programmed gradient from start to finish, and that is what most skid sizing quietly assumes. But the technology transfer data showed something the default does not capture. The product eluted well before the gradient was complete. Once the peak was off the column, there was no reason to keep running the remainder of the gradient before moving on to strip and regeneration.
That one observation changed the cycle time. Ending the elution when the product has actually come off, rather than at the end of the programmed gradient, means less buffer per cycle, a shorter step, and a shorter overall cycle. A shorter cycle means more cycles fit inside the same batch window, and more cycles per window means more throughput from the column you already have. So instead of running the simulation on the default full-gradient elution, I built it in SuperPro Designer around the actual elution behavior from the lab and that I did it myself checked the process design and description against how the step genuinely performed rather than how a generic version of it would.
When that real elution profile went into the model, the picture changed. The existing column could meet the required capacity by running more cycles, so a second chromatography skid was never needed. The one piece of equipment the optimization did call for was an additional elution collection tank, to pool the eluate coming off those extra cycles. A tank is a different order of cost and footprint altogether. We traded a full chromatography skid, with the columns, pumps, valves, instrumentation and controls that come with it, for a single collection tank that takes up a fraction of the space. Just as useful, it took away the uncertainty the team had been carrying about that one step, at exactly the phase where late changes hurt the most.
What I take from it
The point here is not the tool, and it is not any one decision. SuperPro gave me the numbers, but a simulation only repeats the assumptions you feed it. If I had fed it the defaults, it would have agreed that we needed another skid, and it would have been wrong in a confident and expensive way.
What changed the outcome was treating the assumption as a question instead of a given, going one level deeper into the process design, and pairing the right tool with the actual data and some process experience about which numbers were worth trusting. That combination is what tends to solve the genuinely hard project problems, and it is worth more than any single piece of software.
Years later, what stays with me is not the cost we saved. It is that we did the right thing by the process rather than the convenient thing, and the project was better for it. That kind of decision does not always feel comfortable in the moment, especially late in a project when everyone wants the design to stop moving. But it is the one you are still glad you made long after.
If there is a takeaway for anyone doing this kind of work, it is this. Before you add equipment to cover a number you are unsure about, find out whether the number is real. The cheapest capacity you will ever add is the capacity you discover you already have.
