Nura Events
Nura Events
Building Product Process for a Venue App - Across Web, iOS & Android
Building Product Process for a Venue App - Across Web, iOS & Android
Nura is a venue management platform - a purpose-built app for a single venue's events, guests, and community, available on web, iOS, and Android. I joined as the sole PM, reporting to the founder, with no prior product process in place. My remit covered product definition, cross-platform delivery coordination, QA, and a global freelance team operations across multiple time zones. I recruited and hired three of those team members directly: the iOS developer, Android developer, and QA professional. The product was at stage 0, some backend built, base frontend architecture in place, design mostly ready but with significant gaps.
The goal: a seamless, end-to-end event management experience for a boutique high-end community, invitation flows, guest list management by role (host/co-host/guest with distinct permissions), and payments.
Nura is a venue management platform - a purpose-built app for a single venue's events, guests, and community, available on web, iOS, and Android. I joined as the sole PM, reporting to the founder, with no prior product process in place. My remit covered product definition, cross-platform delivery coordination, QA, and a global freelance team operations across multiple time zones. The product was at stage 0, some backend built, base frontend architecture in place, design mostly ready but with significant gaps.
The goal: a seamless, end-to-end event management experience for a boutique high-end community, invitation flows, guest list management by role (host/co-host/guest with distinct permissions), and payments.
Role | Product Manager
Platform | Web · iOS · Android
Team Type | Global freelancers, multiple time zones
Team Type | Global freelancers, multiple time zones
Role | Product Manager
Platform | Web · iOS · Android
Team Type | Global freelancers, multiple time
zones
THE CHALLENGE
OUTCOME
The core challenge was operational: a cross-functional freelance team shipping across three platforms, distributed across time zones, with no unified PM process, no ticket standards, no handoff structure, no QA documentation, and no consistent reporting to the founder. Coordinating without direct authority or shared working hours meant every process had to be async-first and unambiguous by design.
On top of this, I was asked to scope and ship a net-new fundraiser sub-product. The payment architecture had two distinct flows: guests contributing payments to the external fundraising organization, and hosts paying Nura directly for the venue. Each flow required separate routing logic, with Nura never acting as a financial intermediary for the org-side payments — requiring a processor evaluation with compliance and architecture implications.
The app launched live with real community members. The first two events were processed end-to-end, invitations, guest lists, and payments - successfully. Early user feedback flagged strong intuitiveness and information clarity. Product is in early live operation, long-term metrics pending.
THE CHALLENGE
The core challenge was operational: a cross-functional freelance team shipping across three platforms, distributed across time zones, with no unified PM process, no ticket standards, no handoff structure, no QA documentation, and no consistent reporting to the founder. Coordinating without direct authority or shared working hours meant every process had to be async-first and unambiguous by design.
On top of this, I was asked to scope and ship a net-new fundraiser sub-product. The payment architecture had two distinct flows: guests contributing payments to the external fundraising organization, and hosts paying Nura directly for the venue. Each flow required separate routing logic, with Nura never acting as a financial intermediary for the org-side payments — requiring a processor evaluation with compliance and architecture implications.
WHAT I DID
THE CHALLENGE
Built PM process from scratch: defined a ticket pipeline (Deploy → Staging → QA → Done) across all platforms, owned async developer handoffs, and delivered structured weekly reports to the founder.Defined role-permission logic - hosts, co-hosts, and guests each operate under distinct rules, resolved flow conflicts in invitation routing between roles.
Pushed back repeatedly on founder feature requests that would compromise core flow clarity, advocating for user testing before committing dev resources to unvalidated assumptions.
Prioritized seamless, directive UX over feature breadth - guiding users to the correct next action without friction.
Scoped and defined the fundraiser sub-product end-to-end, including dual payment routing: guest contributions direct to the fundraising org, host venue payments to Nura — implemented via Stripe Connect after evaluating 4 processors on architecture, routing capability, and compliance grounds.
The core challenge was operational: a cross-functional freelance team shipping across three platforms, distributed across time zones, with no unified PM process, no ticket standards, no handoff structure, no QA documentation, and no consistent reporting to the founder. Coordinating without direct authority or shared working hours meant every process had to be async-first and unambiguous by design.
On top of this, I was asked to scope and ship a net-new fundraiser sub-product. The payment architecture had two distinct flows: guests contributing payments to the external fundraising organization, and hosts paying Nura directly for the venue. Each flow required separate routing logic, with Nura never acting as a financial intermediary for the org-side payments — requiring a processor evaluation with compliance and architecture implications.
WHAT I DID
Built PM process from scratch: defined a ticket pipeline (Deploy → Staging → QA → Done) across all platforms, owned async developer handoffs, and delivered structured weekly reports to the founder.Defined role-permission logic - hosts, co-hosts, and guests each operate under distinct rules, resolved flow conflicts in invitation routing between roles.
Pushed back repeatedly on founder feature requests that would compromise core flow clarity, advocating for user testing before committing dev resources to unvalidated assumptions.
Prioritized seamless, directive UX over feature breadth - guiding users to the correct next action without friction.
Scoped and defined the fundraiser sub-product end-to-end, including dual payment routing: guest contributions direct to the fundraising org, host venue payments to Nura — implemented via Stripe Connect after evaluating 4 processors on architecture, routing capability, and compliance grounds.
OUTCOME
The app launched live with real community members. The first two events were processed end-to-end, invitations, guest lists, and payments - successfully. Early user feedback flagged strong intuitiveness and information clarity. Product is in early live operation, long-term metrics pending.
OUTCOME
The app launched live with real community members. The first two events were processed end-to-end, invitations, guest lists, and payments - successfully. Early user feedback flagged strong intuitiveness and information clarity. Product is in early live operation, long-term metrics pending.
Learnings & Reflections
Payment architecture is a product decision - who holds money, when, and why determines compliance exposure. That belongs in the PRD, not left to engineers.
Presenting options ≠ making decisions. Working directly with the founders taught me that my job is to map the landscape clearly; they own the conclusion.
Process design is how you lead without authority. A global freelance team across time zones only stays aligned if every artifact is unambiguous enough to work without real-time clarification.
