The person behind the lab.

My day job involves pharmacokinetics, clinical research, and a lot of spreadsheets. At some point I started noticing the same pattern everywhere: real problems that existing tools either ignored or handled poorly. The PK analysis software available to researchers was either prohibitively expensive, locked behind institutional licenses, or both.

I didn't set out to become a developer. I set out to solve a specific problem I understood better than most developers ever could. The fact that I had no CS background turned out to be mostly irrelevant. What mattered was knowing the domain deeply enough to define the problem precisely — and using AI as a collaborator to close the gap between idea and implementation.

Each tool here came from a genuine need or curiosity, not a market gap spotted on a spreadsheet. PK·Swift from daily work. VORA from meeting fatigue. CryptoBacktest from wanting to trade smarter before risking real money. Domain first. Code second.

The blog documents the whole process — including the parts that didn't work. If you're building something outside your official lane, you're in the right place.

Developers who have spent years inside the conventions of software engineering often have strong intuitions about what's supposed to be hard, what's supposed to take months, and what's not done by someone without credentials. Those intuitions are usually right — and sometimes they're exactly what slows things down.

Not knowing the rules means I don't know what I'm “not supposed to” attempt. Every Vibed Lab project started from a question of what does this actually need to do, not what is the standard architecture for this type of application.

AI is the collaborator that closes the implementation gap. But the domain expertise, the problem definition, the judgment about whether something is actually correct — that part still requires a human who understands the field. That's the part I bring.