CeolX put Irish live music on a map and reached 119 listed events in its first month after launch

The situation

The problems we had to solve

• Venues had to pay, and the app stores forbid the obvious way to collect

  This was the hardest problem on the project, and it was not a coding problem. Venue subscriptions are the revenue model. Apple and Google both restrict how an app can take money for digital access, and a global app cannot rely on the narrow exemptions that exist in some countries.

  We considered three routes. Apple In-App Purchase with RevenueCat was the compliant default, but it takes roughly 15% of every subscription from a young business before the model is proven. A "Buy now" button opening an external browser clears review in some jurisdictions and is fatal in others, which makes it a liability for an app meant to travel. The third option was email-only activation: the venue signs up, the app tells them their listing is not yet visible, and an activation link arrives by email that opens Stripe Checkout, outside the app entirely.

  We chose email-only activation. It costs no platform commission and works the same whichever country a reviewer opens the app in. The trade-off is that the flow only works if four rules hold.

• Four rules the payment flow had to hold, or it silently breaks

  Choosing email activation created four constraints that are easy to violate months later by accident:

  No price, no URL, and no checkout button appears anywhere in the app. Not on the subscription prompt, not in settings, not in a tooltip. The app states that the venue is not yet visible and that activation details have been emailed. That is the entire surface.

  The Stripe webhook is the only source of truth for payment. Not the browser redirect. Users close the tab, lose signal, or pay on a different device, and any flow that treats the redirect as confirmation will mark paying venues as unpaid.

  There is no return URL back from the Stripe portal. A reviewer should not be able to trace a round trip from the app to a checkout and back, because that round trip is the thing being restricted.

  The activation route is excluded from the app's deep-link path globs. This is the easiest rule to break. Add it by default and the activation email opens the app instead of the payment page, which silently closes the only route into the paid flow, with no error anywhere.

• Location-first discovery, without building a geo engine

  The map is the product. Everything else is a feed. That meant indexed geospatial search over live event and venue data, with category filters, text search across artist and event names, and a search radius that widens automatically when an area comes back empty, all responsive on a phone in a pub with poor signal.

  We could have built this on PostGIS queries against Postgres directly. We used Typesense for the geo index and the native map on each platform for rendering instead: Apple Maps on iOS, Google Maps on Android. The reasoning was simple: this is a solved problem, the client is a founder-led venture without an ops team, and build weeks spent on a custom geo search layer would have bought nothing a hosted index does not already do well. Most of our testing effort went into the edges: pin clustering, and what the map shows when an area has no events. The choice held up. The map is the most-used screen in the app.

• Clearing App Store and Google Play review for a three-sided app

  A three-sided app with user-generated content, external payment, location permissions, and social features touches several store policies at once. Each one has to be handled in the product itself, not explained in review notes: admin moderation that can take down any event, location requested only when the map needs it, account deletion inside the app, and no payment surface at all.

  We turned what we learned into a written review checklist covering these policies. The next app we take to the stores starts from that checklist instead of finding the same rules one review at a time.

• Keeping scope clear with a non-technical founder

  Feature-level scope works well when the buyer is technical. When the decision-maker does not read specs, a feature heading agreed on signing day can mean different things to each side a few months later. On CeolX we closed one gap like that during the build, and it changed how we scope.

  We now define scope down to individual screens and states when the decision-maker is non-technical, and put the client into the staging build every week with a short demo call. On engagements where we run that cadence, the gap between what the client expects and what exists stays close to zero.

1. Phase one carries venue subscriptions alone

   The original subscription ask bundled venue subscriptions, event boosting, and in-app advertising into one phase. We pushed back and split it. Venue subscriptions go first, because they are the simplest paid product and the one that proves whether venues will pay at all. Event boosting and paid promotion are designed and deferred to a later phase. A bundled subscription phase would have delayed every part of it behind the slowest part.

2. A pilot rollout instead of switching on all venues at once

   There were 16 venues on the platform when subscriptions were ready. The instinct is to activate all of them and start billing. We recommended piloting with a handful first. An email-activation flow with no in-app checkout is unfamiliar to the person receiving it, and the first few venues will tell you where they get stuck far more cheaply than sixteen simultaneous support conversations will.

3. A stack chosen for a team that has no ops function

   The March proposal specified Flutter, Hasura, and AWS Amplify. The build moved to a single TypeScript stack instead: React Native with Expo for one codebase across iOS and Android, a Hono backend with tRPC and Drizzle over PostgreSQL on Neon, and a React admin portal. One language across mobile, API, and admin means the app and the server validate against the same schemas, so a form rule cannot drift from the API rule behind it.

   Around that core, every moving part is a managed service. BetterAuth for sign-in, Typesense for map search, AWS S3 for media, Mux for video, Upstash QStash for background jobs, Postmark for email, Firebase for push and remote config, Vercel for the API. That is the point: the client has no platform engineer, so anything requiring ongoing operational attention was a liability, not a feature.

4. Continuity across an engineer handover

   The build passed between engineers in late June 2026, about two thirds of the way through the feature milestones. The first engineer built the core product between March and July. The second took over launch, store releases, venue subscriptions, production operations, and analytics. The handover was smooth because the stack is conventional TypeScript end to end and every milestone had a written task spec.