Hyperdata was where the work stopped feeling junior. I was the sole engineer on a CRM for medical-device sales teams, building the Android client in Java and the backend in PHP Slim. The product had to work for real field usage, not in a controlled office environment.

The core problem was operational coverage. Sales reps needed a system for hospital proximity mapping, lead and pipeline tracking, and a built-in content library they could carry with them while meeting hospitals across Jabodetabek and parts of outer Java. That meant thinking beyond screens and into movement, geography, and how reps actually worked day to day.

Being the only engineer on a system like that sharpened my instincts quickly. There was no comfortable handoff between frontend and backend, because both sides were mine. If the flow was awkward, if the API shape was wrong, if data came back inconsistently, I had to fix it end to end.

I also built a separate internal expense tracking app. That second system mattered because it taught me a recurring lesson: even smaller internal tools deserve decent architecture. People notice when software removes friction, even if the audience is only a single team.

Later in the role, I took on interns and helped them navigate the same codebase I had built. Mentoring forced me to explain not just what the code did, but why it was shaped that way. That made my own engineering sharper and pushed me toward a more deliberate style of system design.

Hyperdata was the first time I had to make architecture decisions without hiding behind seniority I did not yet have. It taught me how to own the whole surface area of a product, and that habit carried straight into the chapters that followed.