Production AI · IoT & telematics · Operational systems
Find the gaps between what your system reports and what it does.
Founder & hands-on CTO of a fleet-tracking platform · Previously VP of AI & Engineering, Target Test Prep
Taking audit engagements: two weeks, one system, fixed price.
MEET THE PERSON BEHIND THE SYSTEMS
Hello, I’m Henry.15-second introduction · AI avatar & my saved voice
Read the introduction
Hi, I’m Henry. I build AI tools and business systems that solve real operational problems. Explore my work, ask a question, or connect with me on LinkedIn.
We record page visits and interaction counts. AI conversations are saved and may be reviewed privately by Henry to understand questions and improve the experience. Please leave out confidential information.
Describe a system or a decision you need evidence for. Ask how Henry could help.
Suggested starting points · prepared guides
I’m Henry’s AI assistant. What brings you here: a role to fill, a process to improve, or something you’d like to understand? Ask below, or choose a suggestion above.
Claims-vs-reality audit. Two weeks, one operator, one system. Fixed scope and fee agreed after a 20-minute call.
A findings table comparing agreed high-risk claims with observations, evidence and confidence
The measurements behind each finding: the command, query or reading that produced it
An agreed automated check, installed and tested with your team, with ownership and maintenance instructions
A 90-day action list prioritized by operational impact
Scope: One production system and a written set of high-risk claims agreed before work begins. The two-week engagement starts once the required read-only access, evidence and technical contact are available. Changes to production checks require your approval. Ongoing monitoring and maintenance are separate from the engagement.
Good fit: Teams with a production system and an important decision held up by conflicting dashboards, stale documentation or unverified AI output.
Outside scope: Ongoing backlog delivery, a full code rewrite or a comprehensive security or compliance audit.
What I build
Systems that do useful work, and the measurements that prove it.
Three real cases: a tracker that "dies at 26% battery" and actually goes quiet at 3.60 V, a vendor reference that was 30% incomplete and looked whole, and six architecture docs measured against production. Summarized observations, limits and follow-up checks.
MeasurementFirmwareDocumentation drift
Target Test Prep
AI content workflows
Built TAEGIS for AI-powered exercise analysis and worked on lesson generation and automated content workflows. Connected LLM services to the content process and checked output quality.
LLM integrationContent automationQuality review
DiTrack · engineering since 2025
From GPS signals to useful alerts
Built a Rails fleet-management application with PostgreSQL and Python ingestion services. Connected tracker protocols to tracking, geofencing and alerts, and handled deployment and production troubleshooting.
Ruby on RailsPythonPostgreSQL
Suggestion Ox
Core platform improvements
Led projects on a multi-tenant Rails platform, refactored core business logic and improved the test suite. Took substantial projects from planning through release and mentored developers and QA colleagues.
Business logicTestingDelivery
Experience
2025–Present
Founder & CTO (hands-on) · DiTrack
Own the technical direction and hands-on development of DiTrack’s fleet-management platform: Rails, PostgreSQL, Python ingestion and GPS tracker integrations. Responsible for architecture, deployment and production troubleshooting. Founded the business in 2011; hands-on technology leadership began in 2025.
Jul 2024–Mar 2026
VP of AI & Engineering · Target Test Prep
Built AI tools and automated workflows for educational-content production while leading a distributed engineering team. Work included TAEGIS, lesson generation, LLM integration and output-quality review.
Sep 2023–Jul 2024
Lead Engineer · Suggestion Ox
Refactored core business logic and improved the test suite on a multi-tenant Rails platform. Led projects through release and mentored junior developers and QA colleagues.
Aug 2022–Aug 2023
Technical Lead · BairesDev
Worked with stakeholders to turn requirements for a logistics product into a working MVP, coordinated delivery and handled knowledge transfer at client handoff.
Jun 2019–Sep 2022
Senior Full Stack Engineer · Self-employed
Built Rails applications, backend APIs, PostgreSQL data models and frontend features for clients. Handled cloud deployment and ongoing changes.
Mar 2011–Present
Founder & CEO · DiTrack
Founded DiTrack (formerly GEPESAT) in Peru and built the operations around the fleet-tracking business. Software engineering work began separately in 2025.
How I work
I start from what the system claims about itself, then measure. Every finding carries the command, query or reading that produced it; if it can’t be measured, it’s labelled a hypothesis. Running a business shapes the rest: the software has to be useful to the people doing the work.
I use Claude Code and Codex throughout development, with hands-on responsibility for architecture, code review, testing and production behavior.
Ruby on RailsPythonPostgreSQLAPI integrationsLLM integrationDigitalOceanClaude CodeCodex
People I’ve worked with
“Henry takes complete ownership of everything he does and doesn’t require any “managing.” If he says he’s going to do something, it gets done.”
“Henry is a self-starter and quick study. He was able to join the team in a leadership capacity on a product that he had no prior experience with and get up to speed quickly and get the project completed.”
A vehicle leaves its depot. The system detects the event and hands off an alert—while tracking keeps moving.
DiTrack / workflow explorerInteractive illustration · synthetic data
Inside depotGPS → event → delivery
WHAT THE SYSTEM DOES
Ready when you are.
Run the example to follow a location update through to an alert.
01 Receive location
02 Record boundary crossing
03 Queue notification
04 Track delivery
A simplified explanation of the architecture, not a live tracker or a production performance claim. No messages are sent.
THE ENGINEERING DECISION
Keep tracking independent of delivery.
Separate notification work from vehicle processing. Handle supported transient failures through retries, and record delivery status so failures can be investigated.
Based on DiTrack’s local implementation: Rails jobs, notification services and delivery records. This illustration does not establish the current production deployment.
“Henry takes complete ownership of everything he does and doesn’t require any “managing.” If he says he’s going to do something, it gets done.”
AI-generated discussion starter, not a delivery commitment. Questions are processed by AI and saved for conversation continuity. Leave out confidential information.