Pharma Manufacturing Software: Problems, Solutions, and What It Costs to Build

Why batch record software makes or breaks a pharmaceutical manufacturer

A pharma site does not sell tablets. It sells documented evidence that tablets were made correctly. The product is physically finished the day the last carton is packed. It ships two or three weeks later, when a QA reviewer finally signs the executed batch record. Everything between those two dates is working capital sitting in a quarantine cage.

The stack at a typical mid-size site: SAP or NetSuite for materials and financials, a paper or hybrid batch record printed from a Word master, LabWare or STARLIMS for lab results, TrackWise or MasterControl for deviations and change control, AVEVA PI or Ignition for equipment data, ValGenesis or Kneat for the validation packages, and about forty Excel files doing the actual coordination. None of it talks. The sites that call us are usually already paying somewhere between $180k and $400k a year in licenses and validation services across that stack, and still run release off a whiteboard.

Here is what that looks like on a Wednesday at 4pm. Batch 24-0417, a 1.2 million tablet compression run, roughly $2.4M of finished goods. The record arrives at QA as 186 printed pages. The reviewer notices an operator initialed line clearance at 06:12, but the room logbook shows the previous product still on the line at 06:30. That is a data integrity finding, and it opens a deviation. Closing it means pulling the balance printout from the weigh room, the compression force trend out of the historian, the blend uniformity result out of LabWare, and eight years of prior similar events out of TrackWise. Four systems, no shared batch identifier. The batch releases 19 days later. Nothing was ever wrong with the tablets.

Problem 1: QA batch review is a hunt for missing ink, not a quality decision

In the sites we have worked in, a reviewer spends 6 to 9 hours on a solid-dose record, and roughly three in ten go back to production for good documentation practice corrections: a missing initial, a correction without a date, a wrong date format, a yield calculation transcribed one digit off. At 200 batches a year that is about 1,500 QA hours spent proofreading, by people you hired to make quality judgments.

MasterControl and Werum PAS-X both do electronic batch records, and they do them well when your process resembles the process their other customers run. The wall shows up when it does not. If your granulation hold-time rule depends on the previous campaign's product, or you are a CDMO where each client demands a different in-process data set, you configure until you cannot, then you file a change request, then you wait for the vendor's release cycle to give you a field.

A custom build models the process as it actually runs. Entries are captured at execution on a floor tablet: badge login, scanned equipment ID, value range-checked before it can be saved, timestamps from a trusted source. GDP errors become structurally impossible rather than something you catch three weeks later. Then review by exception: QA sees the 11 entries that hit a limit, not all 3,000. That is a 7-hour review turning into about 40 minutes in our builds. Where a site must keep paper for a while, on legacy products or contract lines, an OCR and model pass over the scanned record before QA opens it flags blanks, out-of-sequence timestamps, uninitialed corrections, and calculations that do not recompute. It produces a reviewer worksheet, not a decision. The human stays the recorded signer and the model output goes in as a versioned attachment. That distinction is what keeps it defensible under Part 11.

Problem 2: The deviation investigation is 40 hours of copy and paste

Major deviation on a sterile fill. The investigator opens TrackWise, then spends the week screenshotting a PI trend into Word, printing the LabWare certificate, chasing the environmental monitoring result, and typing a "similar events" section from memory. Thirty to forty-five hours per major, every time we have sat with a client and timed it. A site with 400 deviations a year and 60 majors burns over 2,000 hours on assembly work.

TrackWise and Veeva Vault QMS are excellent records of decision. They are not evidence aggregation systems. They hold what a human types into them. The historian integration is a professional services project quoted separately, and it usually lands as a hyperlink rather than data you can query.

Build it so that entering a batch, an asset ID, and a date range pulls the tag history through OPC UA or the PI Web API, the LIMS results, the EM data, the maintenance work orders on that asset, and eight years of deviations on that product or equipment, into one timeline. Then a model drafts the narrative and the 5-why starting points and returns a ranked similar-event list using semantic search over the historical text, not keyword matching. QA edits and signs. Major deviation cycle time drops from around 35 hours to 10 or 12. The real value is not the drafting. It is that "has this happened before," the question that turns a 483 observation into a warning letter when you answer it wrong, now has an actual answer instead of an anecdote.

Problem 3: Validation makes every change cost more than the change

Adding one field to capture a new in-process check: two hours of work, twelve weeks of calendar. URS revision, risk assessment, design spec, IQ/OQ/PQ authoring, witnessed execution, a deviation on the test script because a screenshot has the wrong date, then approval routing. So the site stops asking. The software freezes while the process keeps moving, and people start running the real process in a spreadsheet beside the validated system. That spreadsheet is the data integrity risk the validated system existed to remove.

ValGenesis and Kneat manage validation documents. They do not reduce validation. And a vendor MES upgrade forces revalidation on the vendor's schedule, not yours.

Build the evidence into the pipeline instead. Requirements live as traceable IDs in the repository, each with automated tests that run on every commit and emit a timestamped, signed execution record tied to the code version. Split by risk, the way GAMP 5 second edition and FDA's Computer Software Assurance thinking allow: release decisions, e-signature, audit trail, and dose calculations get scripted witnessed testing; a report filter or a label gets automated evidence and a written rationale. In our pharma work this turns a 12-week change into a 2-week change and drops validation from roughly 40% of program cost to around 20%. The auditor gets more evidence than before, not less.

Problem 4: The annual product review is three weeks of Excel archaeology

211.180(e) in the US, the PQR in Europe. Forty SKUs, each needing twelve months of batches, yields, OOS results, deviations, complaints, returns, stability, and change controls. Someone in QA exports SAP, LabWare, and TrackWise into three workbooks and VLOOKUPs on a batch number that is formatted differently in all three, then builds control charts by hand. Three weeks per product family. Two people, permanently. And because nothing trends in between, the first time anyone notices dissolution drifting is at review time, eleven months late.

No packaged tool fixes this, because the blocker is that the batch number is a different string in every system and the only mapping lives in the head of the person who has done it for nine years.

The build establishes a canonical batch identity: one master record every system's identifier resolves to, mapped once at ingestion. After that the review is a query, not a project. Cpk and Ppk trends run nightly instead of annually, alerting when a parameter drifts inside spec but outside its historical distribution, which is where you actually catch problems. The model drafts the narrative sections, QA reviews the statistics and signs. Three weeks becomes two days.

Problem 5: Nobody can answer "what does this change touch"

You want to qualify a second filter supplier, or move a product to line 3. Change control asks for an impact assessment. The honest answer is that no one knows which of your 2,800 SOPs, 400 specifications, 60 validated systems, and filed dossier sections reference that supplier or that line. So the QA manager emails eight department heads and waits six weeks for something that should take an afternoon. Occasionally one gets missed, and the miss surfaces as a filed-versus-actual discrepancy during a pre-approval inspection.

Documentum and MasterControl store documents. They do not store a dependency graph between an equipment ID, an SOP, a method, a validated system, and a dossier section, because that relationship only exists inside the prose.

So build the graph. Every SOP, spec, method, asset, material, and dossier section becomes a node, and references become edges, extracted once from the legacy document set with document parsing and a model, verified by SMEs, then maintained at approval. Impact assessment becomes a traversal that generates the affected list with the responsible owner for each node. The extraction pass is usually where clients get their first surprise: a couple hundred live SOPs referencing equipment decommissioned in 2019.

What this costs and how long it takes

Across 2,000-plus projects, our delivery experience: a focused first release lands at $60k to $130k and ships in 12 to 16 weeks. In pharma that first release is one thing done properly, an electronic batch record for one product family on one line, or the deviation evidence layer, or the change control graph. Not three. A full platform runs $150k to $400k phased over 6 to 12 months.

What pushes price up in this category specifically: validation scope, because custom software is GAMP 5 Category 5, so budget 20% to 30% of the program for traceability, risk assessment, evidence, and a CSV lead. If your quality unit refuses a risk-based split and insists on fully scripted testing for every function, add another 15%. Part 11 depth costs 3 to 5 weeks of engineering that has nothing to do with your process and is not optional: audit trail on every table, no hard deletes, signature meaning and manifestation, trusted time, and the audit trail review tooling. Integrations are real work, roughly 2 to 4 weeks for SAP via IDoc or OData, 2 to 3 for a historian, more for LabWare or STARLIMS if the vendor controls the schema. Direct equipment or serialization line integration is where estimates die: get the vendor's interface specification in writing before you sign. Aseptic and Annex 1 scope adds 30% to 40% over solid dose. Two sites with a European QP release model plus US release means two release workflows and a data residency conversation.

The largest overrun we see is never code. It is master data. If equipment IDs, material codes, and batch numbers do not reconcile across systems, that reconciliation is its own project, typically 4 to 8 weeks, and it has to happen first.

Build versus buy: when MasterControl or PAS-X is the right answer

Buy if you are one site, one dosage form, under roughly 150 batches a year, and your process looks like the vendor's model. And buy document control and training records regardless of your size. Nobody should build an SOP repository or a training matrix. Veeva Vault QualityDocs and MasterControl solve that better than you will, and it is not where your margin lives.

Build when three or more of these are true: you are running the real process in Excel next to the validated system; you have paid a vendor for a change request twice in 18 months just to add a field; your differentiator has nowhere to live in the vendor's data model (CDMO with a per-client data set, cell therapy with a patient-linked batch of one, continuous manufacturing); your release cycle exceeds five days after the last operation for paperwork reasons rather than testing reasons; or you have multiple sites that each configured the same vendor system differently, so you cannot compare them.

The clearest signal is competitive. If your position depends on how the process runs, the vendor's roadmap serves 400 other customers before it serves you. A CDMO that onboards a new client in six weeks instead of six months wins contracts, and no amount of configuring a packaged MES gets you there. Note that hybrid is the normal end state, not a compromise: most of our pharma clients keep Vault or MasterControl for documents and training, keep LabWare for the lab, and build the layer that is theirs, which is execution, evidence, and release.

How to choose a developer for pharma manufacturing software

Make them draw your data model on a whiteboard before you sign. Batch, lot, sublot, campaign, phase, equipment, material, and the difference between a specification, a limit, and an alert level. If you have to explain those terms, they will learn on your budget, and the mistakes will be structural rather than cosmetic.

Ask what validation evidence they hand you, and who writes it. A real answer names deliverables: a URS with a traceability matrix, a functional risk assessment, IQ/OQ/PQ or a documented automated equivalent with rationale, and a CSV lead who has sat across a table from an investigator. "We will support your QA team with the documents" means you pay twice, once for the build and again for a validation firm. The firms our clients bring in bill $180 to $250 an hour.

Demand a specific integration story, not a logo slide. Not "we integrate with SAP." Ask which interface, what the batch confirmation payload looked like, what broke, and how long reconciliation took. Anyone who has actually shipped a pharma integration has a story about a two-week argument over a unit of measure or a batch number with a leading zero.

Settle the exit on day one. Source code, database schema, infrastructure definitions, and the validation package should sit in your repository and your cloud account from the first sprint, not get handed over at completion. In a category where your software is inspected evidence, whoever holds the code holds your release. Get it in the contract.