Why Building an Internal Tool for a Second User Is Harder Than the First

A developer built a lightweight internal tool that processes photos and generates priced drafts, running in a 239 MB container at fractions of a cent per item by offloading all heavy compute to external local services. The architecture keeps data on a private LAN, with no model weights or browser bundled inside, making dependencies swappable via environment variables. When a second user needed access, the project crossed into multi-user territory, exposing security and data-isolation challenges that a single-user tool never faces. The developer implemented a scoped data layer that makes tenant-less database queries impossible to write, preventing accidental data leakage across users. The experience highlighted that authentication defaults are silent rather than enforced, and that proxy-based auth only works if the underlying port is properly firewalled.