Nextora Analytics
About
Nextora Analytics is one engineer. I write the software. Before that I spent time as a pharmacy technician and in hospital settings — enough of the workflow to know why a late result is still a failure, and not a substitute for having run your bench.
- MS Computer Science, Georgia Tech
- BS Biomedical Engineering
- Pharmacy technician experience
- Hospital settings
Who I am
The background is not decoration on the engineering. It is the reason to hire the engineering.
I hold an MS in Computer Science from the Georgia Institute of Technology and a BS in Biomedical Engineering. The combination was deliberate. I wanted to be able to read a protocol and write the system that runs it, without needing a translator in either direction.
- MS in Computer Science, Georgia Institute of Technology
- BS in Biomedical Engineering
- Pharmacy technician work, on the counter and in the workflow behind it
- Time in hospital settings, including volunteering and physician shadowing — useful context, not a clinical appointment
I also grew up close to the operational side of healthcare. My father is a clinical laboratory director and toxicologist; my mother is a pharmacist. That is exposure, not a credential — it does not make me a laboratorian or a pharmacist, and I would not describe it as expertise in either field. What it does mean is that instrument runs, turnaround times, requisitions, verification steps, and the difference between a result and a reported result were ordinary conversation years before they were requirements in a ticket.
Why this combination matters to you
Most engineers who could build your system have to be taught your work first. Most people who understand your work have to hire someone else to build it. Either way you pay for the translation layer, usually in weeks of your own time and in the gap between what you asked for and what arrives.
You will not spend the first two weeks of an engagement explaining to me what a requisition is, why a critical result cannot sit in a queue overnight, why a printed report and a reportable result are different objects, or why "just export it to a spreadsheet" is not a plan. I already know why the workaround exists, and I know that the person doing it three times a day is not the problem.
I still ask a great many questions. Your lab is not the one I grew up around and your practice is not one I have worked in, so the specifics have to come from you. The difference is where the questions start.
How I work
Four commitments that shape every engagement.
-
Scope in writing, before code
We agree on what gets built, what it costs, and when it is finished before I start. If the work turns out to be a different problem than we scoped, you hear that from me early, not in an invoice later.
-
One engineer, no handoffs
You talk to the person writing the code. Nothing is lost between a salesperson, a project manager, and whoever the work was actually assigned to. That also caps how much I can take on at once, which is the honest trade.
-
You keep the system
Engagements end with the code in your repository, handover documentation, and a runbook your team can operate without me. If you need me afterward, it should be because you want the next thing built, not because you are locked in.
-
Plain talk about compliance
I do not claim HIPAA compliance as a product feature. I will tell you plainly what a given piece of work requires — a business associate agreement, a risk analysis, specific safeguards — and what it does not, and when the answer is a specialist rather than me.
Work I do not take
I do not take FDA submissions, 24/7 managed operations, or a multi-year platform that needs a team. If that is the work, I will say so on the first call and point you at a firm that does it. There is a quieter case as well: if you already know exactly what you want built and only need hands to type it, you can buy that for less elsewhere. The reason to work with me is the part where I push back on the specification.
How we build
VoxelEdge is a volumetric medical imaging system designed and built here: a technical MVP for research and evaluation, not a clinical product. It is the clearest available picture of how Nextora designs a multi-service stack. Read the VoxelEdge deep-dive.
Tell me what's breaking
Describe the workflow, the data, or the system that is not working. I read every inquiry myself and reply within two business days.