Role. Software Engineer (formerly Web Integration Developer), Modo Labs

Problem

A campus-scale app platform has to absorb messy data from hundreds of customer systems, ship across several product lines without breaking native iOS and Android clients, and stay reliable while doing it. Each school runs its own directory, course catalog, building inventory, and identity provider, and none of them agree on a format. The native apps cannot be re-released on a whim, so the contract between the server and the clients has to hold across releases. Doing all of that for ten years, through framework shifts and a move onto Kubernetes, means the platform's staying power matters as much as any single feature.

Approach

  • Build and maintain integrations between customer systems (directories, identity providers, course and building data) and the app platform, normalizing inconsistent upstream feeds into a stable shape the clients can consume.
  • Treat the server-to-client contract as a first-class interface: keep the API responses that native iOS and Android clients depend on backward-compatible so older app versions in the field keep working after server releases.
  • Run release engineering across multiple product lines, coordinating what ships together and what stays gated so one product's change does not destabilize another.
  • Lean on observability to find and fix reliability problems in production rather than guessing, tracing failures back through the integration layer to the upstream system that actually broke.
  • Carry features like indoor mapping and space booking from data ingestion through the API to the native UI, owning the cross-layer path instead of a single tier.
  • Take on large cross-layer refactors as the platform moved onto a PHP and Kubernetes footing, keeping behavior stable while the ground underneath it changed.

Impact

  • Ten-plus years on the same platform, from Web Integration Developer to Software Engineer, with integrations and release processes that have survived multiple framework and infrastructure shifts.
  • Native iOS and Android clients keep working across server releases because the API contract holds, sparing schools forced app updates every time the backend changes.
  • Reliability work driven by real observability data, so production issues get traced to the upstream cause instead of patched at the surface.
  • Features shipped end to end across the stack, including indoor mapping and space booking, with one engineer accountable from the customer feed to the screen.

Stack

PHP · Kubernetes · REST/JSON APIs · Native iOS and Android client contracts · System integrations (identity providers, directory and catalog feeds) · Indoor mapping · Space booking · Multi-product release engineering · Observability and production monitoring · Linux

Details are generalized to respect my employer's confidentiality; the specifics are ones I can stand behind in an interview.