← Back to blog
PK-SwiftResearchAIDev Log

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.

by Jay··3 min read·PK��SWIFT B.LOG

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.

PK-Swift main app screen running in the browser

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.