OameniOameni: A product for communities and real-world events
Designer / Builder · Product & platform ownershipOwned product
Designed and built a web and mobile platform connecting event discovery, community participation, organizer workflows, memberships, payments and ticketing.
Context & constraints
An event brings together several journeys. A participant wants to find something relevant, register and know how to attend. An organizer needs to manage the event and the people joining it. A community needs continuity beyond a single date. I designed and built Oameni to connect these needs in one product, taking responsibility across product decisions, application/backend architecture, APIs, infrastructure, security and operations.
- Participant and organizer workflows need to fit together: an action on one side changes the information and work on the other.
- Events, community membership, registration and payments introduce related but distinct product states. A useful design has to keep those relationships understandable.
- Web and mobile experiences need consistent underlying capabilities while serving different interaction contexts.
- As an owned product, feature decisions also carry operational, support and maintenance consequences.
My contribution
- Shaped the product around communities, event discovery and the practical work of organizing participation.
- Designed and built the application/backend architecture and REST API capabilities, working across the product’s participant and organizer journeys.
- Built web and mobile experiences using Vue.js, JavaScript and Capacitor, with a PHP/Slim backend and relational data storage.
- Connected event, membership, registration, payment and ticketing capabilities as parts of a coherent product.
- Worked with Stripe integration and the surrounding product workflows, alongside infrastructure, security and operational responsibilities.
- Kept implementation choices connected to the organizer’s goal: manage participants and the event with less administrative friction.
Technology context PHP · Slim Framework · MySQL/MariaDB · Vue.js · JavaScript · Capacitor · Stripe · REST APIs · Docker · NGINX · Linux/FreeBSD
How Oameni connects
The Vue web interface and Capacitor mobile application call a PHP/Slim API backed by MariaDB. Redis supports cache, coordination and notification transport; a Node.js WebSocket service carries live updates. Mail and push workers handle background delivery. Stripe and mobile-store integrations cross an external payment boundary.
Components & responsibilities
- Vue web / Capacitor mobile
- Participant and organizer interfaces share the application experience, with native mobile integrations.
- PHP / Slim API
- Authentication, events, communities, registrations, subscriptions and payment-facing product workflows.
- MariaDB
- Durable application records, participation and billing-related state.
- Redis
- Shared cache, coordination and notification transport.
- Node.js / WebSocket service
- Authenticated connections distribute live notifications and presence updates.
- Mail and push workers
- Separate worker processes handle delivery and retry work outside interactive API requests.
- Stripe / Apple / Google
- External payment and store systems integrate through checkout, purchase verification and notification/webhook boundaries.
Connections & flow
- Vue web / Capacitor mobile to PHP / Slim APIHTTP product requests
- PHP / Slim API to MariaDBRead and persist product state
- PHP / Slim API to RedisCache and publish notification work
- Redis to Node.js / WebSocket serviceNotification and presence transport
- Node.js / WebSocket service to Vue web / Capacitor mobileLive WebSocket updates
- Mail and push workers to MariaDBDelivery state and retries
- PHP / Slim API to Stripe / Apple / GoogleCheckout and purchase integration
- Stripe / Apple / Google to PHP / Slim APIPayment and store notifications
Logical architecture: arrows describe interactions, not individual calls or a particular deployment.
Decisions & trade-offs
Connect participant and organizer journeys
Registration and participation make sense in the context of the event and the people managing it.
Trade-off: A connected product has more relationships to keep clear than an isolated registration form.
Keep product capabilities behind application APIs
The web and mobile experiences can work with a shared set of event, community and payment capabilities.
Trade-off: API boundaries require consistent rules and careful coordination as the product evolves.
Treat payments as part of the product workflow
A payment has meaning through the registration, membership or ticket it supports.
Trade-off: Financial integrations add state and operational responsibilities beyond presenting a checkout screen.
Own the full product loop
Design, development, security, operations and support all influence whether the product is useful.
Trade-off: Each new capability adds ongoing maintenance and support work as well as initial implementation.
Outcome & operation
Built a web and mobile SaaS product spanning community, participant and organizer workflows, with memberships, registration, payments and ticketing. Oameni demonstrates my approach to product ownership: connect the user journey to application architecture, implementation and the work of keeping the service useful.
Notes & references
- Owned product
- Personal design and builder responsibility across product, application, infrastructure and operations.
- Public product
- A community and events platform from RedShift IT.