Web & mobile applications
Product-grade apps with thoughtful UX, from marketing sites to complex, data-heavy dashboards.
Software and embedded systems, one team
From one meeting to a validated spec., a tested feature., a deployed release., a working prototype.
We build custom software and hardware, and we built the delivery platform that makes it fast. Requirements are extracted, not guessed, every handoff is schema-validated, and nothing reaches a pull request without passing a security gate first.
330 tests gating the pipeline16 schema contractsDartmouth College alumni
0
Test functions gating the delivery pipeline
0.00%
Median token reduction, measured on paired runs
0.0M
Rows migrated with zero reconciliation failures
≤0s
Meeting to draft requirements, p95
The delivery engine
Watch a meeting become shipped software
Six stages, eight modules, and a schema gate between every one of them. These are the real module names and the real events they emit.
Intake01 / 06
/bot-run stock-alerts --assignee @tanaka --research acknowledged in 2.1s- Google Drive4 documents matched
- Gmail2 threads matched
- Calendar1 meeting transcript
- Confluence3 pages matched
- Private sourcesredacted from preview
Selected work
Two systems worth showing
One we built for ourselves and now run every project through. One we built to replace software older than most of the people using it.
Delivery platform
How a Slack message becomes shipped software
Eight modules, six review agents, and a schema gate between every handoff. Built so that going faster increases margin instead of cutting the invoice.
- 330
- tests gating modules 02 and 03
- 84%
- median token reduction
- 16
- schema contracts enforced
Rebuilding 25 years of supply chain back office
A Sydney parts distributor ran on 1,451 JSP pages and MySQL 4.0, on one PC in the office. We replaced it with something that installs from a single file.
- 4.6M
- rows migrated, zero failures
- 257→93
- database tables
- 209→7ms
- catalogue search
Capabilities
What we build
Two disciplines, one delivery team, so software and hardware are designed to fit together.
Software
APIs & backends
Reliable services, data models, and integrations.
Workflow automation
Cut manual steps with tailored automation.
Embedded / SoC
System on Chip (SoC)
Board bring-up, drivers, and low-level integration.
Firmware & RTOS
Robust, real-time firmware built to spec.
Sensors, IoT & hardware automation
Connected devices and automated hardware, from prototype rigs to production test benches.
How we work
From idea to something that ships
The same four steps whether the deliverable is a web app, a firmware image, or both talking to each other.
- 01
Discover
We map the problem, constraints, and success criteria before writing code or cutting a board.
Requirements come out typed and scored, with anything uncertain raised as an open question rather than assumed.
- 02
Prototype
Fast, tangible prototypes — a working screen or a bench rig — to validate direction early.
Work is sized before it starts: nothing larger than a two-hour change reaches a developer or an agent.
- 03
Build
Production engineering across software and hardware, tested and integrated as one system.
Security scanning runs before code review, and a failing scan blocks the pull request outright.
- 04
Ship & support
We deploy, measure, and keep improving after launch.
Every stage emits a completion event, so the whole delivery is auditable months later.
Why it holds up
Fast is easy. Fast and correct needs gates.
Anyone can point a model at a codebase. The interesting engineering is in what stops a plausible-looking wrong answer from reaching production.
Schema contracts, not conventions
Sixteen JSON schemas sit between the stages. A handoff that does not validate never reaches the next module, so a bad output fails loudly at the boundary instead of quietly downstream.
Two reviewers that only review
Four agents produce the specification and test plan. Two more, on different model families, exist purely to return pass, warn, or block on what the first four wrote.
Security before review, not after
Semgrep runs against every pull request ahead of code review. Findings go through an automated fix loop with three attempts, and a failure blocks the merge rather than filing a ticket.
Rebuilds proven against the original
When we replace a legacy system we run both side by side and compare outputs. On the most recent rebuild that meant 2,966 comparisons and no disagreements on verified behaviour.
Questions
Reasonable scepticism, answered
No. Agents do the mechanical work — first drafts, test scaffolding, migrations, repetitive refactors — and every output passes through schema validation, security scanning, and human review before it merges. An engineer owns the architecture and the judgement calls. The speed comes from removing the retyping, not from removing the engineer.
Structurally, rather than by hoping. Agent output has to validate against a JSON schema or it is rejected at the boundary. Two independent reviewer agents on different model families return an explicit pass, warn, or block. Security scanning gates the pull request. Anything the extraction step is unsure about becomes a written open question instead of an assumption.
They become typed, individually identified items — functional, non-functional, constraint, risk, open question — each carrying a confidence score and a link back to the source it came from. That evidence map is what lets you audit, months later, why a particular thing was built the way it was.
Yes, and usually together. Board bring-up, drivers, firmware and RTOS work, sensors and IoT, production test rigs. The reason we keep both disciplines in one team is that the expensive problems tend to live at the seam between them.
That is a large part of what we do. We profile the real data first, build a repeatable migration with reconciliation counts, and run the old and new systems in parallel until the outputs agree. The legacy system stays available read-only after cutover, so there is always a way back.
Fixed price against a defined scope wherever the scope can be defined, which is most of the time once requirements have been through the extraction and review pass. That aligns the incentives properly: when delivery gets faster, you get the software sooner rather than a smaller invoice for the same work.
About
One team, both sides of the stack
Little Lab Rats is an engineering studio that designs and builds custom software and embedded systems. We are a team founded by engineers with experience across a range of industries, alongside Dartmouth College alumni, bridging research and real-world industry application. Whether you need an application, a connected device, or the firmware and automation that ties them together, we take it from idea to something that ships.
Tell us what you’re building
Bring us a problem, a half-formed idea, or a system that has outlived its stack. We will tell you honestly whether we are the right team for it.