Independent laboratory software consulting
Small software tools for the work around your LIMS.
I’m Collin, an ICP-MS and metals analyst near Richmond, Virginia. I build practical software tools for the repetitive work that falls between a lab’s LIMS, spreadsheets, email, and people.
A request queue, a checked packing list, or a clearer preparation handoff can be a useful place to start.
Example work
See how a tool handles the details.
Try a sample queue, record a QC observation, or finish a preparation handoff. These independent demonstrations use fictional data.
Sample tracking
A snapshot of the working example.
- Received
- Logged
- Prep
- Analysis
- Review
- Complete
| Sample / project | Method | Analyst | Stage | Due | Status |
|---|---|---|---|---|---|
| DEMO-103Meadowglass Demo Co. · Water study | Metals in water · illustrative | Avery Lane | Prep | 15 Oct | In progress |
| DEMO-105Juniper Demo Works · Soil study | Metals in soil · illustrative | Morgan Vale | Analysis | 15 Oct | In progressHigh priority |
| DEMO-106Meadowglass Demo Co. · Water study | Metals in water · illustrative | Casey Rowan | Review | 14 Oct | Review needed |
Possible starting points
Where does the work repeat?
- Chasing missing request details
A request arrives without the matrix, quantity, or due date. Someone has to follow up and keep track of the answer.
A possible tool: a structured request form with missing fields flagged for staff review.
- Copying bottle or kit requests
Details move from an email into a spreadsheet, then into a packing list. Changes need to be carried across by hand.
A possible tool: one request queue that produces a packing list for staff to check.
- Asking who has the next step
A follow-up lives in someone’s inbox. The rest of the team has to ask whether it is waiting, assigned, or finished.
A possible tool: a shared list showing the owner, next action, and unresolved questions.
How I work
Start with the task as it happens today.
In our first conversation, I’d ask you to walk through a recurring task: who does it, how often, where information is copied, and what happens when something is missing or changes.
Choose a useful improvement
Compare a small tool with the options already available in your systems. Identify what would improve and how your team could check it.
Agree before development
Set the scope, cost, timing, access requirements, testing and acceptance criteria, and support arrangements in writing.
Test and hand over
Check the agreed behavior, including mistakes and exceptions, with the people doing the work. Document use, maintenance, and the handoff responsibilities.
About Collin
A lab professional who builds software.
Based near Richmond, Virginia
I work in ICP-MS and metals analysis and have a B.S. in Chemistry with an Environmental Engineering minor. Daily lab work has made me attentive to sample identity, preparation details, QC exceptions, and the information someone needs at the next step.
I’ve developed an internal laboratory workflow application covering sample tracking, preparation and analysis queues, electronic notebooks, QC and review, labels, document generation, and automated data checks.
Smith Lab Systems is my independent consulting business. I create new software for this work; the public examples are built independently.
A few practical questions
Before adding another tool.
Can a tool work with our existing LIMS or spreadsheets?
Possibly. I’d first check the files, supported import/export options, permissions, and vendor restrictions involved. Sometimes a standalone request list is enough. Sometimes an existing feature or a process change is the better answer.
I would not assume an integration is possible before checking those details with your team.
What about traceability, testing, and our quality system?
I’d need to identify the records involved, required review steps, and evidence your lab needs before agreeing on a build. Where relevant, that includes who can change a record and how changes should be recorded.
Testing software against agreed requirements is separate from your laboratory’s validation or compliance decisions. Your quality and technical reviewers would need to determine the applicable requirements and approvals.
Where would the software and data live?
That depends on the workflow and your IT requirements. Hosting, access, backups, recovery, data export, and responsibility for maintenance need to be worked out before development. There is no default assumption that your lab should move its data to a new cloud service.
What happens after the tool is built?
Documentation, correction terms, maintenance responsibilities, and any ongoing support are agreed for the project before development. See my availability and support limits.
Does the software need AI to run?
No. I use AI to assist development, including code and wording. The tools I offer use explicit rules and checks that people can review; they don’t need generative AI to interpret lab data or make analytical decisions. Exceptions stay visible for human review.
I don’t put client laboratory data into development prompts.
Get in touch
Tell me about one task that keeps taking extra time.
You don’t need a software specification. A few sentences about what happens now are enough to start.
collin@smithlabsystems.comOpens your email application. You’ll be talking directly with me.
A useful first note
- What task keeps repeating?
- Where does the information live now?
- What makes the current process difficult?
Keep it high-level. Please leave out sample data, customer records, credentials, and other confidential information.