CDMO Manufacturing and Client Project Software: How Do You Run Six Client Programmes Through Four Suites Without Losing a Campaign?

Why a CDMO is not a manufacturer with extra customers

A chief operating officer is looking at a scheduling whiteboard on a Tuesday morning. Suite 2 is running a client's clinical campaign that has slipped four days because a raw material release came late. Suite 2 is also promised to a second client from the fifteenth, and their tech transfer batch cannot move because their toxicology study is booked. Between the two campaigns sits a changeover with a cleaning verification that takes three days and a quality release that takes two more. The commercial team has already told the second client the date. The first client's person in plant is standing in the corridor asking why their batch record review is not finished.

The tooling is usually a manufacturing execution system such as Korber PAS-X, Rockwell PharmaSuite, or Emerson Syncade if the site has invested, or MasterControl if the estate is quality led, plus an ERP for materials and finance, plus a project plan per client in Smartsheet or Microsoft Project, plus a shared drive per client, plus the whiteboard. Those MES products are serious and they execute batches well. What they were designed for is a manufacturer running its own products through its own suites. A CDMO runs other people's products, under other people's specifications, to contractual dates, with capacity as the thing it actually sells.

Across CDMO projects we have delivered, the recurring pattern is that the scheduling truth lives with one or two people, campaign slippage is discovered by the commercial team rather than predicted for them, and the gap between what the operations plan says and what the client contract promises is closed by heroics. The commercial exposure is direct. A slipped campaign has contractual consequences, and a suite that sits idle between programmes is the most expensive object in the building.

Problem 1: suite scheduling is a commercial promise, not a production plan

A pharmaceutical manufacturer schedules to demand. A CDMO schedules to contracts, and the schedule is the product. The constraint set is unusual: suites with grade classifications that limit what can run in them, shared equipment such as buffer prep or lyophilisers that cross suites, changeover and cleaning time that depends on the product pair, qualified operator availability per process, quality release capacity, and client supplied material arrival dates you do not control.

MES products do not schedule capacity at this level. They execute a batch that someone else decided to run. The result is a production planner holding the constraint graph in a spreadsheet and their memory, and a commercial team quoting dates from a version of that spreadsheet that was accurate last Thursday.

What a custom build does: model suites, shared equipment, changeover rules per product pair, operator qualifications, and release capacity as an explicit constraint set, then schedule campaigns backwards from committed client dates. The value is not a prettier Gantt chart. It is that when the raw material for one programme slips four days, the system tells you on the day it slips which downstream client commitments are now at risk and what the alternatives cost, rather than the commercial team finding out in a client call three weeks later. A constraint solver over a few dozen suites and a few hundred campaign tasks is entirely tractable, and the honest work is in eliciting the changeover rules, which are usually undocumented.

Problem 2: every client brings their own batch record

A client transferring a process brings their own process description, their own in process controls, their own specifications, and frequently their own opinion about what the batch record should look like, because their regulatory filing describes it. Your quality system has its own template. Reconciling those two is a negotiation that happens for every programme and gets re executed by hand.

Configuring a client specific master batch record in a large MES is possible and it is not fast. Each new programme becomes a configuration project measured in months, which is fine for a manufacturer adding a product every other year and painful for a CDMO adding six programmes a year.

What a custom build does: separate the reusable unit operation library from the client specific assembly. Your organisation owns qualified building blocks with their own controls, prompts, and evidence requirements. A client programme assembles those blocks into a master record with client specific parameters, limits, and additional steps, and only the genuinely novel steps need new authoring. Review and approval sit on the assembled record with your quality unit and, where the contract requires it, the client's. The measurable outcome is that programme onboarding moves from months of configuration toward weeks, which is the thing your commercial team is actually selling.

Problem 3: client segregation is a hard requirement, not a permissions setting

Two clients in your building may be competitors. One of them may have a person in plant walking your corridors. Both have audit rights. Neither may see the other's process, materials, schedule detail, deviations, or even the fact that a particular capability exists on your site. This is a confidentiality obligation with contractual teeth, and it is not satisfied by a role that hides a menu.

What a custom build does: make programme scope a property of the data model rather than the interface. Every record belongs to a programme, every query is scoped to programmes the user is entitled to, and cross programme views exist only for internal roles that need them. Client portals are read only projections of their own programme: campaign status, batch progress against plan, open deviations affecting their material, document packages awaiting their review, and released quantities. Exports are watermarked and logged, because during an audit you will be asked who accessed what and when. Getting this architecture right at the start is far cheaper than retrofitting it after a client's auditor asks how you enforce it.

Problem 4: changeover and cleaning are the capacity nobody schedules

Between two campaigns sits cleaning, cleaning verification or validation depending on the product pair, line clearance, and a quality release of the suite itself. That time is real, it varies by what ran before and what runs next, and in most CDMOs it is a fixed allowance in a planner's head rather than a modelled task with its own resources and evidence.

What a custom build does: treat changeover as a first class campaign object with its own tasks, its own sampling, its own analytical turnaround, and its own release gate. Cleaning validation status per product pair is data, so the system knows when a pairing requires full validation sampling versus routine verification, and it schedules the analytical capacity that implies. This is where sites discover that the analytical laboratory, not the suite, is their real bottleneck. That discovery usually changes the investment plan.

Problem 5: revenue leaks between the manufacturing event and the invoice

CDMO contracts bill against milestones: tech transfer completion, engineering batch, each GMP batch, stability time points, and often reservation fees for held capacity plus charges for client caused delays. The event that triggers a milestone happens on the floor. The invoice is raised in finance, from a spreadsheet, by someone reading a status report.

The leaks are predictable. Client caused delays are not billed because nobody documented the cause contemporaneously. Additional analytical testing requested mid campaign is absorbed. Reserved capacity that a client did not use is quietly released without charge because the conversation was awkward and nobody had the evidence.

What a custom build does: attach billing milestones to the manufacturing events that trigger them, so completion of the event raises a billable item with its evidence attached. Delays get a documented cause code at the time they occur, and a client caused delay produces the record your commercial team needs to have the conversation with confidence rather than from memory. Change requests raised during a campaign carry a price and an approval before the work proceeds. This is usually the fastest payback in the entire build, and it is also the least exciting feature to specify, which is why it gets left out.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape for CDMO operations platforms. A first release covering suite and equipment scheduling with changeover rules, the client programme and campaign structure, segregated data access, and a client status portal runs $120,000 to $250,000 and ships in 16 to 24 weeks. A full platform adding client specific electronic batch records built from a qualified unit operation library, deviation and investigation workflow, materials and consumption with ERP integration, tech transfer intake, quality release, and milestone billing runs $350,000 to $900,000 phased over 12 to 24 months.

• Whether electronic batch records are in scope. Executed GMP records carry validation, audit trail, and electronic signature obligations that roughly double the engineering effort of any module that touches them.
• Number of modalities. Sterile fill finish, API synthesis, and cell therapy have genuinely different campaign models, and one abstraction covering all three is usually a mistake.
• Whether you replace or integrate an existing MES. Integrating PAS-X or Syncade for execution while building scheduling, programme management, and client visibility around it is frequently the right call and is significantly cheaper than replacement.
• Client portal scope. Read only status is straightforward. Client review and approval of documents inside your system brings identity, signature, and confidentiality questions that are real work.

Build versus buy, and when buying is right

Buy, or rather stay where you are, if you run one or two suites for a small number of clients on a single modality. A validated paper or hybrid batch record, a scheduling board, and your ERP will hold, and a large platform build would consume capital that belongs in equipment.

Build when two or more of these are true. You run more than three suites with shared equipment, so scheduling has become a genuine constraint problem rather than a calendar. You onboard more than four client programmes a year and configuration time is limiting how much business you can accept. You have competing clients in the building and your segregation depends on people being careful. Your commercial team quotes dates from a spreadsheet that operations does not trust. Or you know that milestone billing is leaking and cannot prove where. Note that building the scheduling and programme layer while keeping a commercial MES for execution is a legitimate and often superior answer.

How to choose a developer for CDMO software

Ask them to model a changeover before you sign anything. A developer who has done this asks about product pairs, cleaning validation status, analytical turnaround, and suite release, and treats changeover as a scheduled object with resources. A developer who treats it as a fixed buffer between campaigns has built a project planner and will not survive contact with your floor.

Ask how client segregation is enforced. If the answer is roles and hidden menus rather than programme scoping in the data model and in every query, they will fail a client audit and you will pay for the rebuild.

Ask what they have integrated. PAS-X, Syncade, a LIMS, and an ERP are four different integration problems with different protocols and different politics, and the honest answer includes which of them they have not done.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. A system holding your clients' process knowledge and your executed batch records must never be recoverable only through a vendor's cooperation.