I use $30K PK software every day. So I built my own.
A pharmacist's case for why non-commercial pharmacokinetic analysis software is long overdue and what it takes to build one that validates correctly.
The question that started it
A colleague in clinical research asked me: "Do you think someone could build a decent NCA tool for under $1,000?"
My first instinct was to list all the reasons why not. Regulatory compliance. Numerical precision. Data traceability. WinNonlin has a 30-year head start.
My second instinct was to actually think about it.
NCA is, at its core, a math problem. Trapezoidal integration, lambda-z regression, a handful of derived parameters. I've run these calculations hundreds of times. I know what the outputs should look like. I know which edge cases break naive implementations: irregular sampling intervals, BLQ values, and flip-flop kinetics.
The question was not whether it was possible. It was whether I could be the one to build it.
What I actually had to learn
The domain was not the hard part. I already knew the pharmacokinetics.
The hard part was the engineering side: building a tool that is trustworthy enough to use in real work. That meant:
- Numerical precision: floating-point arithmetic misbehaves in ways that pen-and-paper PK never warned me about.
- Edge case handling: what desktop software shows as a warning must become explicit logic, not a silent wrong answer.
- Validation infrastructure: comparing outputs not just to my hand calculations, but to FDA-cited textbook references.
Working in pharma gave me a strong advantage: I knew what "correct" should look like before I wrote code.
Where AI actually helped
I want to be precise here, because "AI built my PK tool" is both wrong and irresponsible.
What AI helped with:
- Translating math to code: expressing terminal elimination regression in a maintainable way.
- Surfacing implementation details: reminding me of numerical pitfalls in interpolation and rounding.
- UI structuring: suggesting table layouts that researchers can read without squinting.
What I brought was judgment. PK calculations have right and wrong answers. Knowing the difference is the job.
The validation milestone
PK-Swift AUC values now match FDA-cited textbook examples to 4 decimal places.
That is not vanity. In bioequivalence work, precision matters. The core point of this project is simple: the math is not proprietary, but the license fee often is.
Practical Tips for Non-Developers
- Write acceptance criteria first. In PK work, define expected values and tolerated error ranges before writing code.
- Build one golden dataset and run it after every meaningful change.
- Keep assumptions visible. If BLQ is treated as zero, say it explicitly in UI and docs.
- Use AI as a sparring partner, not an authority.
- Version prompts and formulas in the same repo as code. Future-you will forget why decisions were made.
What is next
Bioequivalence analysis is next: two-period crossover, geometric mean ratio CIs, and the 80-125% bounds.
The statistical layer is harder, the stakes are higher, and that is exactly why I am building it carefully.
PK��SWIFT B.LOG - Follow along as each experiment unfolds.