A mobile offerwall SDK — decomposing product requirements into execution sites
Across app, web, SDK, server and QA, I defined where each capability executes and where its data lives.
- Android
- iOS
- Web
- SDK
- REST API
Specification
- Organisation
- Nudge Healthcare
- Period
- 2024
- Team
- App, web, SDK, server, QA and product — about 15 people
- Execution sites
- Android, iOS, Web, SDK, backend
- Role
- Translating requirements into structure, designing execution sites and call flow, cross-team alignment
Context
The requirements were written as what should happen. Several systems cannot execute that directly: development starts only once each capability has a site of execution and a place its data lives.
Approach
For each capability I named the site of execution: Android, iOS, web, SDK or backend.
Storage locations, data flow, API call relationships and ordering, and inter-service dependencies were written out as flows and sequences.
Exception paths, failure handling and change impact were defined alongside them. A design with only a happy path collapses at QA.
When product requirements met engineering constraints, I explained implementation cost and change impact and settled on an alternative. API contracts, schedules and dependencies were aligned with backend, Android, iOS, web and QA.
System
For every capability: who executes, and who holds the record.
The app opens the web view through the SDK; the SDK sends auth and events to the backend, which holds the authoritative state.
Boundaries
- The SDK and native app implementations belonged to the platform teams. My role was turning requirements into an executable structure and aligning the interfaces between organisations.
- The outcome here is the joint result of several teams.