DEV Community: Daniel Lowery

Most Production Bugs Don’t Live in Your Code. They Live Between Systems

Daniel Lowery — Fri, 13 Mar 2026 00:23:35 +0000

Everyone loves talking about writing code.

Clean code. Fast code. AI-generated code. Boilerplate-free code.

But in a lot of real systems, that is not where the hardest problems live.

The hardest problems usually show up between systems.

Not in the controller.

Not in the stored procedure.

Not in the API method you wrote last week.

They show up in the handoff between one system that “successfully sent” something and another system that definitely did not process it the way anyone expected.

That is why I think one of the most underrated engineering skills is this:

Tracing failures across systems

Not just debugging code.

Not just reading logs.

Not just finding the stack trace.

I mean figuring out where truth broke as data moved from one boundary to another.

A request can be valid in System A, transformed in middleware, partially enriched in System B, rejected silently in System C, and then reported back to the business as “completed” because one status flag looked fine at the wrong layer.

That kind of failure is why so many production issues are painful to explain. The issue is not always that one component is badly written. The issue is that distributed systems spread cause and effect far enough apart that the failure stops being obvious.

OpenTelemetry’s observability docs describe distributed tracing as a way to observe requests as they propagate through complex distributed systems, and they specifically note that it helps debug behavior that is difficult to reproduce locally.

The same idea shows up in enterprise integration platforms. SAP documents that the Message Processing Log stores data about processed messages and information about individual processing steps, and that the message monitor lets you inspect individual messages on a tenant. In other words, the platform itself assumes that understanding message flow step by step is essential.

That is the part people do not hype enough.

The engineer who can trace a failure across boundaries is often more valuable than the engineer who can write the next endpoint quickly.

Because in production, the real challenge is often not “can we build this?”

It is:

What actually happened?
Which system is the source of truth?
Was the payload wrong, or was the transformation wrong?
Did the receiving system reject it, ignore it, or accept it and fail later?
Are we looking at a business-process failure or just a misleading status?

That work requires a different mindset.

You have to stop thinking like a builder for a minute and start thinking like an investigator.

You need timestamps. Correlation IDs. Payload versions. Processing steps. Retry history. Side effects. Context propagation.

OpenTelemetry describes context propagation as the mechanism that allows signals like traces, metrics, and logs to be correlated across distributed boundaries. That is a technical way of saying something very practical: if your systems cannot carry context forward, your debugging story gets much worse.

This is also why “works on my machine” is such a weak comfort phrase in integration-heavy environments.

Of course it works locally.

Locally, you usually do not have:

asynchronous retries
middleware transformations
environment-specific credentials
downstream validation rules
race conditions between systems
stale reference data
a workflow engine quietly making a different decision than the one you expected

By the time a failure reaches production, it often is not a coding problem anymore. It is an observability problem, a systems-thinking problem, or a handoff problem.

That is my main takeaway:

Senior engineering is not just about building systems. It is about explaining how they fail.

And the people who get really good at that tend to become the ones everyone pulls into the hardest incidents.

Not because they write the fanciest code.

Because they know how to follow the truth across boundaries.

Sources

Unit Connect: A Veteran-First App for Nearby VA Support, Local Community, and AI-Powered Next Steps

Daniel Lowery — Fri, 27 Feb 2026 19:06:38 +0000

The Community

I built Unit Connect for the U.S. veteran community, including veterans, family members, and local supporters helping with care navigation and connection.

The main problem this app addresses is fragmented access to help. Veterans often need healthcare, benefits guidance, and peer community at the same time, but those resources are usually spread across different tools.

What I Built

I built a complete MVP web app with three core experiences:

1) Find Support Near Me

Search by ZIP or GPS location
Live VA Facilities API integration (server-side only)
Filters for:
- VA health facilities / clinics
- Vet Centers
- benefits offices
Actionable result cards: call, directions, website, save to “My Plan”

2) Find Veteran Community

Community-powered local directory (Prisma + SQLite/Postgres-ready)
Search by city/state/ZIP/tags
Listing detail page
Submit group flow (PENDING moderation state)
Report listing flow
Admin moderation page:
- PENDING | APPROVED | REJECTED
- VERIFIED_ORG | VERIFIED_COMMUNITY

3) Mission Buddy (AI Assistant)

Turns user needs into practical next steps:
- top contacts + rationale
- call scripts
- document checklist
- 7-day connection plan
Uses retrieved resources when available
Includes crisis guardrails (988 Veterans Crisis Line response)
Includes non-medical/legal disclaimer
Falls back gracefully when external AI quota is unavailable

Privacy/Safety

No sensitive personal data storage
No location history storage
Client-side “My Plan” only
Server-side key handling (no API keys exposed to browser)

Demo

unit-connect-app.vercel.app

Code

DesignByDevDan / Unit-Connect-App

Unit Connect

Unit Connect is a Next.js MVP that helps U.S. Veterans:

Find nearby VA support resources (VA health facilities, Vet Centers, benefits offices)
Discover local veteran community groups
Generate an AI-assisted "Next Steps" plan using retrieved resources

Stack

Next.js 14 (App Router) + TypeScript
Tailwind CSS
Prisma + PostgreSQL (recommended for deployment)
Zod validation
OpenAI API (server-side)
Vitest unit tests

Features

Support search (/support)
- ZIP or lat/long + radius search
- VA Facilities API proxy (/api/va/search) with server-side apikey header
- Filter by VA health / Vet Center / benefits
- Save resources to local "My Plan" (localStorage only)
Community search (/community):
- Search approved listings by city/state/zip/tags
- Sort by closest/newest/verified
- Listing details page
- Report listing flow
Community submission (/community/submit):
- Creates PENDING listing
Admin moderation (/admin):
- Password-protected via ADMIN_PASSWORD
- Approve/reject pending listings
- Toggle verification (VERIFIED_ORG / VERIFIED_COMMUNITY)
- Review and resolve reports
…

View on GitHub

How I Built It

Next.js 14+ (App Router) + TypeScript
Tailwind CSS
Prisma
Zod validation
OpenAI API (server-side route)
Vitest for unit testing

Architecture

Provider layer:
- VAFacilitiesProvider
- CommunityDirectoryProvider
- TwoOneOneProvider (stubbed adapter)
Normalized shared Resource model for UI and assistant retrieval
ResourceTriage ranking + crisis signal detection

Build Notes

Implemented robust VA lookup flow with ZIP/GPS reliability handling
Added graceful fallback plan if AI API is unavailable
Added moderation workflow to keep community listings safe and useful

Thanks for reading!

# Transcripto - AI-Powered Transcription Application

Daniel Lowery — Mon, 18 Nov 2024 14:46:24 +0000

*This is a submission for the AssemblyAI Challenge: No More Monkey Business.

What I Built

Transcripto is an AI-powered transcription web application designed to simplify the process of uploading and transcribing audio files or URLs. The application also allows users to download transcriptions and view a history of past transcriptions. Check out the code at the link below.

GitHub Repository

Features:

Live Transcription: Real-time transcription capabilities for audio uploads or URLs.
Transcription History: A list of previously uploaded and transcribed files with options to download the results.
Responsive Design: Built with React and Tailwind CSS to ensure usability across all devices.
Downloadable Transcriptions: Users can download transcriptions directly from the interface.

Screenshots

Main Interface (Live Transcription)

Journey

The project was implemented with the following technologies:

Frontend: React, Tailwind CSS, React Router.
Backend: Placeholder (intended integration with AssemblyAI).
State Management: React hooks for simplicity and scalability.
Deployment: Easily scalable for future use with backend APIs.

How I built it:

Designed a clean and accessible user interface using Tailwind CSS.
Added functionality to upload audio files or input URLs for transcription.
Created a history page to view and download previous transcriptions.
Implemented routing with React Router to navigate between pages seamlessly.

Acknowledgments

This project is part of the AssemblyAI Challenge hosted on DEV Community. Special thanks to the organizers for providing the opportunity to build and showcase this application.