Custom software for engineered products.

Schneider Labs builds the software your operation needs when off-the-shelf doesn't fit.

Trey Schneider

Trey SchneiderEngineer & architect
Roswell, GA

The gap

Your engineers turn a customer's drawings into a bill of materials. Your plant builds it, tests it, and puts it on a truck. Up to that moment, you know everything about every unit.

Then it reaches the site, and the record stops. Crews work from paper and memory. Questions come back by phone. Six months later, nobody can say with certainty what was installed where, and the answer lives in three spreadsheets and someone's head.

The systems that run your plant were never meant to follow the product out the door. Every operation has a version of this gap, and closing it is a job of its own.

How it works

Every engagement starts with three weeks of discovery, so you see a working prototype against your real data before you commit to a build.

Step 1

Discovery

Three weeks · fixed price

You bring the problem, your drawings, and whoever knows the process best. Three weeks later you have a working prototype built on your actual data, a data model and integration specification, a scoped roadmap, and a priced statement of work for the build. All of it is yours to keep. You could hand the SOW to any vendor. Most people hand it back.

Step 2

Build

Fixed capacity · two-week sprints

The build runs time-and-materials with a not-to-exceed cap, so you have flexibility without losing budget certainty. Every sprint ends with a working increment you can see. Scope changes are written down and agreed before they're built.

Step 3

Pilot

One real project · then hypercare

The software goes live on a single real project with real users, followed by a defined hypercare period. You get the backlog, the source code, the runbooks, and a recorded walkthrough of every major release.

Pricing for discovery is quoted after a short call.

Work

Where the client has described the work publicly, it's named. Otherwise the problem is described as it was found.

Utility-scale solar · electrical equipment

Scan-to-install for a manufacturer of utility-scale solar electrical equipment

Product shipped to utility-scale solar sites with no scannable identity. Installers found and verified material by hand, and the manufacturer had no unit-level record of what was installed where. Discovery turned the manufacturer's own engineering submittal into a complete model of the site, then demonstrated the full flow with a simulated set of serial numbers: scan a box and see what's inside and where it goes; scan a cable assembly and mark its place on the drawing as installed; receive an entire truckload in one scan; watch site-wide progress update in real time. The build carried that into a production mobile application with offline capture, plus the factory-side specifications for QR codes, label printing, and shipping manifests.

U.S. Army · Georgia Tech Research Institute · wearable physiological monitoring

Real-time heat-injury monitoring for Army trainees at Fort Benning

Trainees at Fort Benning face some of the Army's highest rates of heat injury, and the warning signs live in heart rate and skin temperature long before anyone falls out of a march. As part of GTRI's engineering support for the Army's Health Readiness and Performance System, each trainee wore a chest sensor, and the job was everything between that sensor and a screen: Bluetooth capture into ruggedized field gateways running a LoRa network, an LTE uplink to a message broker on AWS, raw streams landing in a research data lake, and processed events reaching an operational database within seconds. On top sat a live browser leaderboard where cadre watched every trainee's physiological status roll up in real time, at dawn, in fog, miles from a wall outlet. It's the same shape as a factory-to-field problem, with harder terrain and higher stakes.

About

I'm Trey Schneider. I've spent 13 years as a software engineer and architect, most recently leading engagements where a manufacturer's field problem became a production application: parsing engineering submittals, building mobile tools that work without signal, and wiring factory systems to the software installers actually use. Before that I was at the Georgia Tech Research Institute, where I was project director and architect for HRAPS Cloud, the platform behind the Army's heat-injury monitoring program at Fort Benning, and built the HIPAA-compliant cloud infrastructure, Kubernetes clusters, and deployment pipelines that GTRI's Health Analytics center ran on.

I started Schneider Labs because the best work I've done started with a prototype, not a proposal, and I wanted to build a company around that.

When a build needs more hands, I bring in engineers I've worked with for years and stay the architect and your single point of contact.

How I think
  • A prototype is a better conversation than a deck.
  • Scope changes get written down before they get built.
  • The people who know the process are usually not the people in the meeting. Go find them.
  • Software that works at a desk and fails on a job site is not finished.
Contact

Tell me the problem in three sentences.