Boomrng

The challenge

Finding and sending the right card or invitation was clunky, and the experience was split across platforms. Shipping web and mobile together meant either duplicating the logic or letting the schemas drift until the two apps disagreed.

Collaboration

I joined boomrng as a product engineer and designed and built the platform — web, mobile, and the backend — rather than owning a single client. That meant the card and invitation experience, the shared schema, and the media services were one delivery, taken through to a product people could use on both platforms.

From discovery to production

• Web and mobile apps for discovering, personalizing, and sharing cards and invitations
• A monorepo that shares generated GraphQL types, business logic, and utilities across both clients
• A Node.js backend with Apollo GraphQL, REST APIs, and a media server on MongoDB
• One data contract so web and mobile stay in lockstep

How it was solved

Web and mobile live in one monorepo. GraphQL types and shared utilities are generated, so a schema change shows up in both clients instead of being copied. Apollo GraphQL and REST sit in front of MongoDB, and a media server handles the card and invitation assets. The frontend and backend were integrated as one system, which is what kept the two apps from growing separate models of the same card.

Key technical decisions

• 01A monorepo so web and mobile share one schema instead of two hand-maintained copies.
• 02Generated types and utilities, so drift is a build failure rather than a production bug.
• 03Apollo GraphQL plus REST, so the product API and the media path could differ without splitting the clients.

Screenshots

Impact

• Web and mobile ship the same card and invitation experience from one shared contract.
• Generated schemas removed the integration bugs that come from two clients interpreting the API differently.
• The media server, GraphQL API, and both clients were delivered as one platform.