Business analysis is complete. The architecture is designed, the stack is chosen, the integrations are mapped, the estimate is signed off and the delivery partner is engaged. What the $5M seed funds is execution against a specification that already exists — not the discovery phase that usually eats the first six months of a round.
The system is deliberately built as a white-label core with per-station customisation on top. That single decision is what makes a new station — owned or enterprise — a configuration exercise rather than a new product.
One mobile codebase, customised per station. ROXOFF and NHSFM are the first two skins. Playback, onboarding, in-app purchases and subscriptions, promo and referral codes, hidden-channel unlock codes, social sign-in and DRM-protected streaming, all configurable per app at the administrator level.
Where an artist uploads. Catalogue management, metadata, rights confirmation, submission against station briefs, an in-browser player to check their own masters, and the dashboard that shows where their music played and what it earned.
The operator's cockpit. Per-app settings at the individual station level, catalogue and scheduling control, statistics dashboards, promo-code management, subscription oversight through RevenueCat and detailed logging across the estate.
The part that turns a pile of uploaded audio into a station. Audio file processing and playlist generation, transcoding to adaptive streaming segments, and the scheduling logic that assembles a continuous, brief-compliant broadcast per channel and per zone.
The marketing site and landing pages, plus the full project specification, development documentation and unit test coverage — the artefacts that make the business sellable rather than dependent on the people who built it.
Most seed rounds spend their first two quarters discovering what to build. Ours starts with a completed business-analysis phase: six requirements workshops, a full feature list, functional maps for every user type, a vision and scope document, wireframes with user stories for every key screen, a technical research phase to select the architecture, a mapped integration list and a bottom-up estimate.
Performance, scalability, software compatibility, usability, speed, data integrity, security, modularity and maintainability were set as architectural constraints before a line of code was designed — not retro-fitted after the first load test.
The white-label decision is not a technical preference. It is the reason the eleventh enterprise client costs a fraction of the first, and the reason a new owned station is a configuration exercise rather than a new build.
A containerised API behind a load balancer and auto-scaling group, a dedicated processing tier that turns uploaded masters into adaptive streaming segments, and object storage doing the heavy lifting. Standard, boring, proven infrastructure — which is exactly what you want underneath a product that has to play uninterrupted audio into an operating theatre.
| Tier | Component | What it does |
|---|---|---|
| Edge | CloudFront | CDN in front of the back-office web apps and static assets, so the console is fast from any territory. |
| API | Load balancer → auto-scaling → ECS (NestJS) | The containerised application layer. Scales horizontally with listener load rather than being provisioned for peak. |
| Processing | Music scheduler — FFmpeg on EC2 | Audio file processing and playlist generation. Transcodes uploaded masters and assembles the continuous broadcast per channel. |
| Storage | S3 | Master audio files and generated playlist segments (m3u8 / ts), served for adaptive streaming. |
| Data | Amazon RDS — PostgreSQL | Catalogue, rights, users, placements, per-play attribution and the revenue split ledger. |
| Cache & queue | ElastiCache — Redis | Session and catalogue caching, plus the job queue driving the scheduler and payout runs. |
| Observability | CloudWatch · Sentry | Logs and metrics across the estate, with application-level error tracking and performance tracing. |
| Transactional | SES | Mail delivery for statements, receipts, onboarding and station notifications. |
| Playback | just_audio + audio_service — background playback and lock-screen control |
| DRM | PallyCon DRM SDK + better_player — protects commissioned catalogue from extraction |
| Subscriptions | RevenueCat · in_app_purchase — sessions, passes and recurring tiers across both stores |
| Auth | Google, Apple, Meta and X social sign-in |
| Analytics | Firebase — mobile behaviour and funnel |
| Monitoring | Sentry — troubleshooting and performance optimisation |
| App architecture | Bloc (state) · Dio (network) |
The QA plan is heavier than a consumer music app would justify, deliberately. NHSFM has to run in clinical environments and enterprise clients audit us, so recovery, compatibility and acceptance testing are contractual obligations rather than nice-to-haves.
System, smoke, beta and exploratory testing, run against the specified test cases at the end of every two-week sprint with a new version launched each time.
Performance, load, scalability, security and usability testing — the five that decide whether the platform survives a festival weekend or a hospital estate rollout.
Regression, installation, compatibility and recovery testing across the device and OS matrix, plus requirement documentation testing so the spec and the build stay in sync.
Acceptance and maintenance testing, with unit test coverage as a funded line item rather than something the team squeezes in between features.
This is the number that should reassure an investor. The full system build — mobile apps, both web applications, the backend, the scheduler, the public site, documentation and unit tests — comes in around a quarter of a million euros. The remaining ninety-five percent of the raise goes into the things that actually compound: catalogue, A&R, enterprise sales and the October 2027 launch.
| Workstream | Flutter — hours | Flutter — budget | Native — hours | Native — budget |
|---|---|---|---|---|
| Mobile application | 1,194 | €57,312 | 1,555 | €74,640 |
| Web app — admins & producers | 861 | €41,328 | 861 | €41,328 |
| Backend API | 1,626 | €78,048 | 1,626 | €78,048 |
| Public website | 163 | €7,824 | 163 | €7,824 |
| BA documentation | 324 | €15,552 | 324 | €15,552 |
| DevOps support | 228 | €10,944 | 228 | €10,944 |
| Core scope | 4,396 | €211,008 | 4,757 | €227,712 |
| Project documentation | 240 | €11,520 | 240 | €11,520 |
| Unit test coverage | 485 | €23,280 | 485 | €23,280 |
| With optional items | 5,121 | €245,808 | 5,482 | €263,136 |
Single codebase, 5,121 hours, including project documentation and unit test coverage. Roughly €17,300 cheaper than native and materially cheaper to maintain across two platforms thereafter.
At current rates that full build is around $265K — about five percent of the round. The platform is not where the money goes, and it should not be.
1 project manager, 1 business analyst, 2 mobile developers, 1 frontend, 2 backend, 2 QA engineers and 1 DevOps engineer.
The original vendor schedule was written against a 2024 start. Re-based against the seed closing on 31 January 2027 and the global launch in October 2027, the nine-month plan lands like this — with beta in month eight, deliberately ahead of the DJ Awards.
| Month | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct |
|---|---|---|---|---|---|---|---|---|---|
| Business analysis | ■■■■■■■■■ continuous | ||||||||
| Design | ■■ | ||||||||
| Backend | ■■■■■■■■ | ||||||||
| Frontend | ■■■■■■■ | ||||||||
| Mobile | ■■■■■■ | ||||||||
| QA | ■■■■■■■ | ||||||||
| Milestone | — | Beta | Launch | ||||||
| Service | Cost | Basis |
|---|---|---|
| AWS + S3 | $500 – $15,000+ / month | Scales with users; upper figure is at around 100,000 users |
| Firebase | Free | Spark plan covers up to 50,000 monthly active users |
| RevenueCat | Free → 1% of tracked revenue | Free to $2.5K monthly tracked revenue, then 1%; Scale plan from $1,700/month billed annually |
| Sentry | $30 – $100+ / month | Seats and event volume |
Effort, budget and infrastructure figures are taken from the engineering scope of work prepared by the delivery partner. Third-party pricing is indicative and subject to those vendors' current published terms.
The technical risk in an early-stage platform business is almost always concentrated in the first six months: what exactly are we building, will the architecture hold, and how long will it take. All three of those questions have already been answered here, in writing, by a delivery partner who has done the analysis phase and priced the build bottom-up.
Feature list, functional maps and wireframes complete. We are not going to discover the product in month four.
Bottom-up estimate at 5,121 hours with the optional items included. The build is a known number, not a range.
A ten-person team defined by role and available, alongside the FonoTec engineering hires in Berlin who take ownership after release.