Short answer
RaftLabs built CeolX, a location-first Irish music event discovery app, in Flutter on Hasura, PostgreSQL, and AWS with Typesense-backed map search. It launched into Irish festival season in August 2026 and recorded 344 registered users, 113 published events, and 1,667 event views, with 86% of signups arriving in a single month.
Engagement
The CeolX engagement
- Client
- CeolX, a founder-led Irish music and events venture
- Sector
- Live music discovery and venue booking in Ireland
- Delivery
- Phased fixed-price build from March 2026, launched August 2026, ongoing
- Team
- Two engineers, one project manager, one QA engineer, part-time solution architect
- Scope
- Flutter apps for fans, artists, and venues; Next.js admin portal; Hasura and PostgreSQL backend on AWS; Typesense map search; Stripe venue subscriptions
- Status
- Live in both app stores. Venue subscriptions built and sitting on staging, pending a phased rollout
CeolX is not a rescue story. There was no broken system, no previous agency, no legacy stack to unpick. The founder wanted to promote Irish music culture and had a specific idea of how: put every live session, gig, and festival slot on a map, and let fans, artists, and venues find each other on it.
That is harder than it sounds. It is a three-sided product where none of the three sides is useful without the other two. Fans need events to browse. Artists need venues to book them. Venues need an audience worth paying for. Get the sequence wrong and you launch an empty map.
RaftLabs built the whole thing: three personas inside one Flutter app, an admin portal, a Hasura and PostgreSQL backend on AWS, and location-first discovery backed by Typesense. We timed the launch to Irish festival season. In the first season the app recorded 344 registered users, 113 published events, and 1,667 event views from 198 distinct viewers. 86% of all signups arrived in a single month.
The two things worth reading this page for are the App Store compliance problem, which reshaped the entire revenue model, and the retention curve, which is the honest part.
before & after
From an idea about Irish music to a live three-sided app
- No product. An idea, a market, and a founder who is not technical
- Irish live music discovery scattered across Facebook events, posters, and word of mouth
- No way for a venue to find an available artist for a Thursday night
- No way for an artist to see which venues were programming their kind of session
- No revenue mechanism, and no clarity on whether a subscription model could even ship inside the app stores
- Festival season approaching, which is either a launch window or a missed year
- One Flutter app serving three personas: fans, artists, and venues, live on iOS and Android
- Map-first discovery over live event and venue data, with radius and category filters
- Artists publish events and promotional posts, apply to venue gigs, and accept or reject invitations
- Venues list gigs, invite artists, run promotional ads, and read engagement analytics
- A Next.js admin portal for the internal team, with user management and subscription visibility
- A venue subscription model that clears Apple and Google review, built and verified on staging
- Launched into festival season: 344 registered users and 113 published events in the first weeks
The problems we had to solve
- 01
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 off a business that has not yet proven the model. 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 a payment link arrives by email, outside the app entirely.
We chose email-only activation. It costs no platform commission and it does not depend on which country a reviewer opens the app in. What it costs is discipline, and the discipline is unusual enough to be worth spelling out.
- 02
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 one is the trap. 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.
- 03
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 radius filters, category filters, and text search across artist and event names, 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 Google Maps for rendering instead. The reasoning was ordinary and correct: this is a solved problem, the client is a founder-led venture without an ops team, and spending build weeks on a bespoke geo search layer would have bought nothing a hosted index does not already do well. It was still the component that generated the most bugs during the build, mostly at the edges of clustering and radius behaviour.
- 04
App store review was harder than the engineering
The most expensive delays on this project came from Apple and Google review policy, not from code. A three-sided app with user-generated content, external payment, location permissions, and social features touches several policy surfaces at once, and each rejection costs a review cycle.
There is no clever solution to report here. We worked through it, and we came out with a written checklist of the policies that actually bit us. The next app we take to review will not spend that time again. If you are building your first app for the stores, budget review cycles as a real line item in the timeline, not as a formality after code complete.
- 05
Scope drift with a non-technical client
Worth stating plainly because the framework asks for honesty and this is the real one. At one point the client believed a feature was in scope when it was not. Nobody acted in bad faith. The scope was written in a proposal, agreed, and then interpreted differently months later, which is what happens when the person approving scope is not technical and does not see the product between demos.
Two things fix this and we now push for both. Define scope more granularly when the decision-maker is non-technical, to the level of individual screens and states rather than feature headings. And get the client into the staging build frequently during development, with a demo call every week. We run that cadence on another engagement and the gap between what the client expects and what exists stays near zero.
the build
How the build was sequenced
The engagement was a fixed-price phased build rather than a single delivery. That shape mattered, because two of the decisions we pushed back on were about sequence, not about features.
Phase one shipped 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 ship first, because it is the simplest paid object 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.
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.
A stack chosen for a team that has no ops function
Flutter for one codebase across iOS and Android. Hasura over PostgreSQL for instant GraphQL APIs with role-based permissions, so three personas with genuinely different read and write rights did not become three sets of hand-written endpoints. AWS Amplify for auth, storage, queues, and compute. Firebase for push and remote config. Next.js for the admin portal. Every one of those is a managed service, and that is the point: the client has no platform engineer, so anything requiring ongoing operational attention was a liability, not a feature.
Two engineers across a handover, mid-build
The build passed between engineers in late June 2026, roughly 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. Handovers mid-build are a risk worth naming; this one held because the stack is conventional and the backend is declarative rather than bespoke.
Proof
What the first festival season produced
All figures were pulled from the CeolX production database and PostHog on 16 September 2026, roughly six weeks after launch. They are first-season numbers from a new product with no marketing budget, not a settled trend.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Registered users | 344 across three personas | 165 fans, 159 artists, 19 venues | CeolX production database, 16 September 2026. 86% of all signups landed in August, the peak of Irish festival season |
| Signup funnel | 427 installs converted to 209 completed signups | Unique users through each step | 427 installed, 351 started signup, 301 submitted, 232 opened verification, 209 completed. A 49% install-to-active conversion |
| Events published | 113 live events | First season, published by artists and venues | 1,667 event views from 198 distinct viewers, and 54 clicks through to external ticket links |
| Community activity | 126 posts, 251 follows, 16 bookings | Social and booking layer, first season | Production database: 126 promotional posts, 113 likes, 251 follows, 26 saved events, 16 bookings |
| Platform split | 272 devices, 155 Android and 117 iOS | Registered devices at time of pull | Near-even split, which is worth knowing before anyone proposes an iOS-first roadmap for an Irish consumer audience |
| Retention | 153 monthly actives, 32 weekly | 30-day and 7-day windows to 16 September 2026 | Weekly actives ran 69, 131, 214 at peak in the week of 10 August, then 138, 108, 74, 96. Roughly 55% below peak and the open problem on this product |
| Revenue | None yet | Venue subscriptions are built and verified on staging, not live in production | Stated plainly by the delivery engineer. There is no monetisation figure to report and this page does not imply one |
Timeline
How the engagement ran, and where it stands
- 01January to March 2026
Scope, personas, and a phased proposal
Three personas defined with distinct pain points and feature sets, plus an admin portal. Live streaming, in-app event payments, and offline maps were explicitly ruled out of version one, in writing, before any code was written. - 02March to July 2026
Core build across seven milestones
Auth and onboarding, map discovery, event and post creation, the artist and venue invitation loop, calendar and notifications, analytics, and the admin portal. - 03Late June 2026
Engineer handover mid-build
Delivery passed to a second engineer, who took launch, store submissions, production operations, and the subscription milestone. - 04August 2026
Launch into festival season
Released on both stores. An offline event run by the client drove the install spike. 86% of all signups arrived this month and weekly actives peaked at 214 in the week of 10 August. - 05August to September 2026
Venue subscriptions built to staging
Email-only activation, Stripe webhook as the single source of truth, no checkout surface in the app. Verified on staging and held there pending a phased venue rollout. - 06Now
Ongoing, with later phases scoped but unconfirmed
The engagement continues. Event boosting and in-app promotion were deliberately deferred from phase one and are planned, not yet commissioned.
The lesson
For a local discovery app, acquisition is the easy half. Plan the second month before you launch the first
CeolX did not have a user acquisition problem. A single offline event run by the client put 427 installs on the board and 86% of all signups into one month. If you are building a community app around live events, tie your launch to a real-world moment where your audience is already gathered in one place. It works, and it is cheaper than any paid channel.
The number that matters is the one after that. Weekly actives went 69, 131, 214, then fell back to roughly half of peak and flattened. That is a normal launch curve, and it is also the whole product problem, because a discovery app is only useful when there is something new to discover. The fix is not marketing. It is supply: a steady flow of published events, which for CeolX means artists and venues posting week after week rather than during festival season alone. A three-sided marketplace lives or dies on the side that creates the inventory.
So if you are building something like this, put the same planning into the off-season that you put into launch week. Decide before you ship what gives an artist a reason to post in November, and what gives a fan a reason to open the app on a Tuesday. We would rather say that plainly than present a launch spike as a finished outcome.
Where to go next
What we would recommend next
These are opportunities beyond the delivered scope, not work that was included.
- Next 01
Take venue subscriptions live as a small pilot
The flow is built and verified. Activate a handful of the 16 venues rather than all of them, watch where the email activation step loses people, and fix that before it becomes sixteen support threads at once.
- Next 02
Attack retention as a supply problem, not a marketing one
Weekly actives sitting 55% below peak is a symptom of thin event inventory outside festival season. Prompts, reminders, and streaks for artists and venues who publish will move the fan-side numbers more than anything aimed at fans directly.
- Next 03
Instrument the 54 ticket-link clicks properly
1,667 event views produced 54 clicks through to external ticketing. That ratio is the single clearest signal of whether the app drives real attendance, and it deserves proper attribution rather than a raw count.
- Next 04
Put the client in staging every week
The one genuine friction on this engagement was a scope expectation gap. A weekly demo against the staging build, which we run on other engagements, closes it. It costs an hour and it is the cheapest risk control available on a fixed-price build.
Evidence and limitations
Reviewed 21 September 2026
- Product figures come from the CeolX production database and PostHog, pulled on 16 September 2026 by the delivery engineer. They are not independently audited.
- Six weeks is a short window. Every engagement number on this page describes a first season for a new product. Treat the retention curve as an early signal, not a verdict.
- There is no revenue figure because there is no revenue. Venue subscriptions are built and verified on staging and have not been switched on in production.
- The discovery phase predates the current delivery engineer. The diagnosis and scoping detail on this page is drawn from the signed proposal dated 12 March 2026 rather than from a first-hand interview, and the original build engineer has not yet been interviewed.
- No client testimonial has been recorded for this engagement, so this page carries none.
- Budget is described as a shape, not a figure, in line with how we present commercials across the portfolio.
- Client sign-off on this page is pending. It should not be published before the client has approved the named figures.
Questions founders ask about builds like this
A phased fixed-price build. Scoping ran from January to March 2026, the core build across seven milestones ran March to July, and the app launched on both stores in August. The proposal put the build phase at 12 to 14 weeks in two-week sprints. The engagement is still running, with later phases scoped but not yet commissioned.
Two engineers across a mid-build handover, one project manager, one QA engineer, and a part-time solution architect. The build phase was a fixed price in the low five figures in euro, with any work beyond the signed scope going through a change request at an hourly rate. We describe commercials as a shape rather than a figure across the portfolio.
For CeolX, by not charging inside the app at all. Venues sign up, the app tells them their listing is not yet visible, and a Stripe payment link arrives by email. No price, URL, or checkout button appears anywhere in the app, the Stripe webhook is the only source of truth for payment status, and the activation route is kept out of the deep-link configuration so the email opens the payment page rather than the app. It clears review globally and costs no platform commission. It is slower for the venue than a tap, which is the real trade.
Because indexed location search is a solved problem and the client has no platform engineering function. Hand-rolling it on PostGIS would have consumed build weeks and produced something we would then have to operate. The hosted index handles radius and category filtering at the response times a map needs. It was still the most bug-prone area of the build, mostly around clustering and radius edge cases.
Yes. The shape is a three-sided local marketplace: people who attend, people who perform or supply, and venues that host. Sport, comedy, food markets, and community events all have that shape. The parts that transfer directly are the map-first discovery layer, the invitation loop between supply and venues, and the external-payment subscription pattern. The parts that do not are the category taxonomy and the seasonality.
Live streaming, in-app ticket payments, offline maps, and historical event data were ruled out of version one in writing before the build started. Event boosting and paid in-app promotion were designed and deferred out of phase one on our recommendation, so venue subscriptions could ship on their own rather than waiting behind a bundle.
Two things. Define scope at screen-and-state level rather than feature level when the decision-maker is non-technical, because feature headings read differently to different people six months apart. And put the client in the staging build weekly with a demo call, which is the cadence we run on another engagement and which keeps expectation and reality in the same place.
Yes. The engagement is ongoing. Venue subscriptions are built and sitting on staging awaiting a phased rollout, and further phases including event boosting and in-app promotion are planned but not yet confirmed by the client.
Related work
