PepWell

PepWell is an employee wellness and benefits application built for PepsiCo in Egypt, delivered to employees as a mobile application with an administration dashboard behind it. It gives PepsiCo employees one place to discover and access the benefits their employer provides. The defining property of the product is that it is a distribution mechanism: the benefits already exist, negotiated by the employer, and the application exists to make them findable.

The problem is distribution before it is technology: large employers negotiate substantial benefit programmes that employees never use, not because the benefits are poor but because discovery is. Benefits typically live scattered across intranet pages, PDF documents and HR emails, so an employee must already know a benefit exists in order to find it. An employer-scoped catalogue is also harder than a public one in exactly one place: the offers are negotiated for the employees of one organisation, so access itself has to be gated on employment. The deployment is PepsiCo Egypt. The actual brief behind the engagement is not documented, and this problem statement is derived from the documented capabilities rather than supplied as one.

A dedicated benefits application connecting the employer, its employees, the benefits negotiated for them, the offers behind those benefits, and the service providers the offers come from. Access is gated by federated sign-in: the application integrates with Okta, the employer's identity provider, over SAML, so employment is asserted by the directory that already holds it rather than by a sign-up the application would have to police. The catalogue is organised into browsable categories: wellness offers, financial benefits, mental wellness, physical wellness, lifestyle benefits, exclusive promotions and employee offers. Employees discover benefits, browse categories, explore offers and view promotions, and redeem inside the application rather than being handed off to the provider, which is the difference between this and a directory of links. Redemption is a confirmation rather than a token: the employee confirms in the app, the platform records it, and nothing is generated for a provider to scan or validate. Firebase Cloud Messaging carries push to the app, which is what gives a catalogue whose offers expire a way to reach people. Eligibility and personalisation rules, and how service providers are onboarded, are not documented.

The backend is a modular monolith: one Laravel 11 deployment over MySQL, hosted on AWS, divided internally into modules rather than split into services. The modules are a code boundary rather than a data one: they share the single MySQL database, which is the ordinary shape of the pattern and a different bet from the database-per-module split on Al-Ouf. Two surfaces sit in front of it and reach the same API, an employee application in React Native on Expo and an administration dashboard in React with Tailwind and TypeScript. Sign-in is the load-bearing part: the platform does not authenticate employees itself, it federates to Okta, the employer's identity provider, over SAML. That puts the assertion of employment in the only system that can make it authoritatively, and leaves the application holding a session rather than a credential. Media stays off the request path, in S3: offer and provider imagery, employee uploads and documents, and backups, with CloudFront serving the ones the application actually renders. Push reaches the app through Firebase Cloud Messaging. There is no entitlement layer behind it, and that is a design decision rather than an omission: every employee who authenticates sees the whole catalogue. Authentication is therefore the only boundary in the system, which makes the SAML federation carry more weight than it looks like it does, and it means access ends exactly when the employer stops authenticating someone and not a moment before.

• An employer-scoped benefits platform is an authorisation system before it is a catalogue: every documented capability presupposes an answer to "is this person an employee, and which benefits may they see". The first half is settled by federating sign-in over SAML, which moves the question to the system that already knows the answer and keeps a benefits application out of the business of verifying employment. The second half is simpler than it looks, because there is no second half: everyone who gets in sees everything.
• Redemption is what turns a read-only catalogue into a system that changes state, and it is recorded here rather than presented: the employee confirms in the app, the platform writes it down, and nothing is handed to the provider to scan. That keeps the whole redemption path inside the platform and moves the hard part outward, onto how a provider learns that a redemption happened at all. No provider integration is documented, so the far end of the most consequential write path on the platform is the part left open.
• Authentication is the whole authorisation model, which is a legitimate answer rather than a missing one. Benefit programmes in large organisations often vary by region, grade or business unit, and modelling that would couple the catalogue to an HR reality the platform does not own and cannot keep current. Serving one catalogue to everyone who can prove employment avoids that entirely, and it moves the only question that matters onto the identity provider: whoever it still authenticates is still an employee.
• An offer in this catalogue joins three parties, none of which the platform owns: the employer, its employees and the external service providers behind the offers. No provider integration and no HR integration are documented, which makes how the catalogue and the employee population are kept current the central operational question left open.
• Offers and promotions expire, and a benefits channel that surfaces a dead offer teaches employees to stop checking it. In a product whose value is discovery, content freshness is a trust property rather than housekeeping, and push is the lever that turns a catalogue nobody reopens into one that can announce itself.

• Okta: employee sign-in federated over SAML
• Firebase Cloud Messaging: push notification delivery to the mobile app

• Laravel 11
• MySQL
• React Native
• Expo
• React
• Tailwind CSS
• TypeScript
• SAML
• Okta
• Firebase Cloud Messaging
• AWS
• Amazon S3
• Amazon CloudFront
• Docker