Dean Biscocho

The distribution center ran on paper. A pick batch printed out, went to the floor, and came back when it was done. No one could see where a batch was or who had it. Pickers walked the same shelf three times for three orders. Serial numbers got scanned at a desk after the fact, so the system never knew what actually left the building until later. The inaccurate manifests it produced drove carrier adjustment fees projected at a minimum of $200K a year.

I led the build that replaced it and owned the entire React iPad app. Pickers work off a real-time status board now. They scan the location to confirm position, scan the item to confirm it's right, and get an audible beep on success or a different tone on error. Serials are captured at the shelf. Pick Groups combine orders that share locations so a route gets walked once instead of three times.

The system captures accurate shipment data at pick time so declared packages match physical reality. That removes the carrier dimension-and-weight adjustment fees inaccurate manifests were driving. That is the immediate win, not the full benefit.

Stack: React frontend on iPads with Bluetooth scanners, an ASP.NET Core 8 pass-through API, stored-proc-driven SQL Server, integrated with the ERP as the system of record. This was a multi-engineer build; I owned the frontend end to end and several read-only endpoints, and worked alongside the engineer who owned the backend and ERP integration.

New products used to reach the sales team up to three months late. Someone exported product data from Salsify by hand on a quarterly cycle, so reps couldn't quote new products until the next manual push.

I built and deployed the .NET 8 Web API middleware that automated it. A Salsify webhook fires when a product hits the right PLM stage, the middleware picks it up, and it writes the product and its pricebook entries into Salesforce over the REST API with retry and circuit-breaker handling. I owned the middleware design, build, and deployment.

One design tradeoff worth naming: the initial version syncs on the trigger event, so changes after that point don't re-sync yet. The on-change re-sync is a planned next phase.

Postgres exposes rich performance data, but reading it means running raw SQL and interpreting text output. QueryIQ turns that into visual dashboards. A developer connects their database and gets charts for query performance, cache-hit ratio, index usage, and table sizes, plus the ability to paste any query and see its execution plan rendered as panels.

It's open source, built under the OSLabs accelerator, live at query-iq.com, with 66 GitHub stars. I owned the public landing site end to end and a chunk of the frontend app, and integrated the frontend against the Grafana-backed dashboard API.

One design decision worth noting: rather than build a charting layer, QueryIQ drives a local Grafana instance programmatically, composing an existing best-in-class tool instead of reinventing it. Because Grafana runs locally, database credentials never leave the user's machine.