Skip to main content
Kevin Mastriano

// BUILDING

I'm not a programmer. I built my lab's software anyway.

That first sentence isn't modesty. I never coded. I can't read most of the code. If you opened the files and asked me to walk you through them, I couldn't. But the day there was a model decent enough to build with, I started building — because I'm about efficiency at my core, and AI at its baseline is efficiency. I drive the ideas. It drives the doing.

This page is about why not being a programmer stopped mattering — and the posts below are the build log, ugly steps included.

// WHAT LABHQ IS

Software for one lab: mine

LabHQ is the software that runs Custom Calibration — the work orders, the FIFO board, the numbers I check every morning, the paper trail an ISO 17025 lab lives and dies by. And underneath all of that, it's something more specific: one centralized database that every other tool in my business reports to.

Here's what twenty years of buying software taught me: the perfect software is a unicorn. It doesn't exist. You either compromise on how you run your business, or you run five tools at once and stitch them together with clumsy connectors. I did both, for years.

For calibration, IndySoft was the answer to my prayers — a genuinely great, powerful piece of software, and it's still in the building. But it isn't perfect for me. Operationally it doesn't work the way my lab works, and it was the one tool I owned without an API. Those gaps are exactly where LabHQ was born. I had to build the integration myself — and once I had, I didn't stop. Every day it gets better. More integrations, more of the business inside it. LabHQ is the workhorse now.

// THE PURCHASING RULE

If it can't talk to LabHQ, I don't buy it

My sole reason for purchasing new software now is that it has an API or an MCP I can port into LabHQ. That's the whole evaluation. Not the demo, not the feature list — can it feed the hub.

What's already wired in: our GPS and vehicle monitoring, our phone system, our Google accounts, our payroll. Every one of them lands in the same centralized database, so the business has one source of truth instead of six tabs that almost agree.

// HOW A NON-PROGRAMMER BUILDS SOFTWARE

The honest workflow

What I can't do: write code, read most of it, or debug it line by line. What I can do — and it turns out to be the whole job — is know exactly what my lab needs and say it in plain English.

So the loop looks like this. I describe what I need the way I'd brief a person standing in the lab. The AI writes the code. I look at the result on the screen — not the code, the result — and judge it the way I judge everything else in my business: does this match reality? Where it doesn't, I push back, in English, until it does. Then I ship it.

Where it goes wrong, because it does: the AI is confidently wrong in ways a confident person would be fired for. It shows numbers that look plausible and aren't. It fixes one thing and quietly breaks another that worked yesterday. My defense isn't reading the code — I can't. My defense is knowing my business cold. Wrong-but-tidy data might slip past a programmer who doesn't know the lab. It doesn't slip past the guy who knows what the board should say before the screen loads.

Why I ship anyway: the customer is me. This software runs in front of people who know the work cold, so wrong gets caught in hours and fixed the same day. That's a luxury a software company selling to strangers doesn't have — and I'm going to keep spending it.

// WHY THIS MATTERS BEYOND ME

The barrier moved

For my entire working life, custom software was a barrier twice over. The obvious one: hiring developers, writing specs, and waiting — a price that made sense for big companies and no sense for a calibration lab in North Haven. So owner-operators like me lived inside software that almost fit, and we adjusted ourselves to it, daily, forever.

The deeper barrier was how my brain works. I'm a builder at heart, and it's hard for me to spec something out without getting my hands dirty — I don't fully understand what I need to build until I'm building it. The old way demanded a finished spec before anyone wrote a line. That was never going to work for me. Building with AI runs the other direction: I build a rough version, look at it, see what's wrong — and now I know what I actually needed. That loop fits how I think.

Because the knowing was never the problem. Nobody on earth knows what my lab's software should do better than I do — and the same is true of you and your shop, your practice, your restaurant. The barrier was code, and specs, and waiting. The barrier just moved.

I'm a guy with a 1.6 GPA and no degree, shipping software that runs a real company. If you run a business and you've been living inside tools that almost fit, you can now do something about it without becoming a programmer. I'm the test case, documented below — including everything that breaks.

// WHERE SOFTWARE GOES NEXT

The end of the behemoth

Here's where I think this goes: nobody is going to need the one-off behemoth software package. The future is boutique software with MCPs — sharp little tools that do one thing well and plug in anywhere — and everyone running their own custom software on top, with the connectors that fit their business instead of building everything from scratch.

It's like buying the Lego kit and building the front end out however you want. At eight I built the battleship with no kit and no instructions, because that was the only way to get the thing in my head onto the table. Now the kit comes with the bricks — and you still decide what it becomes.

And a step past that, I don't think we'll need front ends at all. You'll open a chat window, say what you need, and it gets done. That's already how I build LabHQ. Soon it's how you'll run your whole business.

// BUILDING — POSTS

How I Ship Without Knowing How to Code

The recurring loop a non-programmer uses to build real software: say it in plain English, judge the result on screen, push back, ship — the failure mode included.