From an Chemistry Lab to FastAPI: Why I Built the LabTrack API

Luiz Fernando C. Castilho — Tue, 18 Aug 2026 16:00:34 +0000

Before I wrote a single line of code professionally, I spent years inside an analytical chemistry lab. I did my Master's in Chemical Biology at UNIFESP (Federal University of São Paulo), working with NMR (nuclear magnetic resonance) for hydrogen, carbon, and two-dimensional experiments, plus HPLC (high-performance liquid chromatography). The LabTrack API, my project built with Python, FastAPI, and PostgreSQL, came out of a very specific problem I lived through during that time. It wasn't a portfolio idea thought up from the outside. It was a real pain point.

The problem: every lab speaks a different language

My lab handled the analytical side: we isolated and characterized compounds. But we didn't do everything alone. To know if a compound had antimicrobial activity, we needed a partner lab specialized in microbiology. To evaluate effects on cells, we needed a lab working with cell culture. Sometimes these partners were in another country.

The result was that each lab had its own protocol for the same type of task. That alone created friction: every new student joining had to be trained not just in the technique, but in how that specific lab recorded things.

The second problem: nobody knew what anyone else was doing

Communication between partner labs happened mostly through email. No shared calendar, no visibility into what each team was running at that moment. To know if an experiment had already been done, when, by whom, and with which reagents, you had to ask the person directly. If that person didn't reply quickly, the experiment simply waited.

This matters more than it sounds, because eventually that data becomes a scientific paper. To publish, you need to know exactly who did what, when, and in which lab, since that goes into acknowledgments and authorship. If the record is informal and inconsistent, reconstructing that history later is pure rework.

The third problem: no standardization even within the same lab

Even inside my own lab, two people using the same HPLC could log its use differently. Without a recording standard, every entry became an individual's interpretation of how to document an experiment.

Where the LabTrack API comes in

The LabTrack API is my attempt to address this with what I'm currently learning: Python, FastAPI, and PostgreSQL. The core idea is simple: a system where every experiment is logged in a standardized way, with authorship, date, reagents used, and status, accessible to partner labs without depending on email to know what's happening.

It's not an ambitious attempt to reinvent a full LIMS (Laboratory Information Management System). It's a learning project, built commit by commit, but solving a problem I know from the inside, not one invented just to have something on GitHub.

Why this matters for my career transition

I moved from the lab bench to the code editor, but the analytical thinking I developed reading NMR spectra and chromatograms is the same thinking I use now to model a database or design an API route: understand the problem before jumping into a solution.

The LabTrack API isn't just a technical project for me. It's proof that this career change doesn't erase my previous experience, it becomes the foundation for thinking through the problems I'm solving now.

From the Lab Bench to the Codebase: What Scientific Research Taught Me About Debugging

Luiz Fernando C. Castilho — Wed, 05 Aug 2026 16:33:49 +0000

For over five years, my "bugs" weren't in code. They were in DNA sequencing runs that came back with unreadable peaks, PCR reactions that refused to amplify, and antioxidant assays that gave inconsistent results across replicates.

I have a background in Biotechnology and a Master's in Chemical Biology. I spent years in research labs analyzing experimental data, documenting processes, and trying to figure out why something that worked yesterday suddenly didn't work today.

Now I'm a career changer, studying Systems Analysis and Development and building my first real projects in Python. And the thing that surprised me most about learning to code wasn't the syntax. It was how familiar the process of debugging felt.

The scientific method is a debugging method

In the lab, when an experiment failed, you didn't just try random things until it worked. You had to:

Isolate the variable that changed
Form a hypothesis about what went wrong
Test that hypothesis in the smallest possible way
Document what you tried, even when it didn't work

That's... exactly what debugging is. When my first FastAPI project threw an error I didn't understand, I caught myself doing the same thing I'd done hundreds of times in a lab: change one thing, re-run, observe, repeat. Don't guess wildly. Narrow it down.

Reproducibility matters more than you think

One of the hardest lessons from research was that a result nobody else can reproduce isn't really a result. If I couldn't explain exactly what I did, in what order, with what parameters, my data was worthless to anyone else, including future me, six months later, trying to remember what I did.

That obsession with documentation carried straight over into version control. Writing clear commit messages, keeping a README that actually explains what a project does and why, structuring code so someone else (or future me) can follow the logic, none of that felt like a "best practice" I had to learn from scratch. It felt like something I already knew was important, just applied to a new domain.

Patience with things that don't work

Research trains you for a strange kind of patience. Most experiments don't work the first time. Most don't work the tenth time either. You learn to treat failure as information, not as a verdict on your competence.

I won't pretend that switching careers has been easy or that this patience makes learning to code frictionless. It doesn't. But I notice that when a script fails for the fifth time in a row, I don't spiral the way I might have if this were my first experience with something not working. I've been here before, just with different tools.

What I'm building now

Right now I'm working on LabTrack API, a FastAPI + PostgreSQL project for managing lab experiment data. It's a small, deliberate way of connecting both halves of my background: using the software skills I'm building now to solve a real problem I actually lived through in research.

I'm also getting more into applied AI, using tools like Claude Code to automate parts of my own workflow (including, a little ironically, my job search).

If you're also switching into tech from somewhere else

You're probably bringing more transferable skills than it feels like some days. The specific tools change, but the thinking underneath is often the same: isolate the problem, test a hypothesis, document what you learn, be patient with failure.

I'd love to hear from anyone else on a similar path. What did your previous field teach you that turned out to be surprisingly useful in tech?

DEV Community: Luiz Fernando C. Castilho