How to Make an App Like Songkick

Building a concert discovery and ticketing platform is a genuinely complex engineering problem. It sits at the intersection of real-time data aggregation, third-party ticketing integrations, and personalised recommendation logic. This post walks through the architecture, key decisions, and honest trade-offs involved in building something comparable to Songkick.

What Does Songkick Actually Do Under the Hood?

Before touching code, it helps to be precise about what the product does. Songkick's core loop is:

1. Ingest event data from promoters, venues, and ticketing APIs
2. Match artists in that data to a canonical artist entity
3. Match users to artists they follow (via listening history or explicit follows)
4. Notify users when a matched artist has a nearby event
5. Route ticket purchases through affiliate or direct ticketing partners

Each of these steps has real engineering weight. The artist-matching problem alone — disambiguating "The National" from "National" across 40+ data sources — requires a combination of fuzzy string matching, MusicBrainz IDs, and Spotify/Apple Music artist IDs as stable canonical references.

Data Sources and Ingestion

Songkick historically built its own event database by scraping and partnering directly with promoters. You have a few realistic options:

Source	Coverage	Effort	Licensing
Ticketmaster Discovery API	Strong for US/UK	Low	Free tier available
Bandsintown API	Good for independent artists	Medium	Negotiated
Eventbrite API	Strong for smaller venues	Low	Free
Scraping + NLP	Broadest possible	High	Legal grey area
Direct promoter partnerships	Most accurate	Very high	Partnership agreements

For a v1, Ticketmaster Discovery API plus Eventbrite covers the majority of ticketed events in most English-speaking markets. Supplementing with Bandsintown gets you better independent artist coverage. Scraping is a maintenance burden and creates legal exposure; only consider it once you have a compelling reason the APIs don't solve.

Artist Entity Resolution

This is where most early implementations fall apart. You will receive event data where the artist name is "Bruce Springsteen", "bruce springsteen", "Bruce Springsteen & The E Street Band", and sometimes just "Springsteen". Your database needs to resolve all of these to a single canonical entity.

Use MusicBrainz IDs (MBIDs) as your primary canonical key. Cross-reference with Spotify artist IDs and Apple Music IDs, since most users will connect via one of those platforms. A simple normalisation pipeline using Python's rapidfuzz library for fuzzy matching, combined with MBID lookup via the MusicBrainz XML API, handles the bulk of this well. Confidence scores below 0.85 should go into a human review queue, not be auto-matched.

What Tech Stack Should You Actually Build On?

This depends on your team's strengths, but here is what a sensible default looks like for a product at early scale.

Backend: Node.js (v20 LTS) or Python (FastAPI) for the API layer. Python has better library support for the ML components you will eventually need. Go is worth considering if you anticipate very high throughput on the event ingestion pipeline.

Database: PostgreSQL with PostGIS for geospatial queries. "Events near me" is fundamentally a radius query, and PostGIS handles this efficiently at scale with proper indexing on a geography column. Redis for session caching and rate-limit tracking against external APIs.

Search: Elasticsearch (or OpenSearch if you want the Apache licence). Artist and event search needs fast, typo-tolerant full-text search. PostgreSQL full-text search starts to show latency problems past a few million records.

Queue: RabbitMQ or AWS SQS for the ingestion pipeline. Event data comes in bursts (a promoter uploads 500 events at once). A queue decouples ingestion from processing and gives you retry logic for failed API calls.

Notifications: Firebase Cloud Messaging for push, with a fallback to email via SendGrid or AWS SES. Users expect near-real-time alerts when a followed artist announces a show, so the notification job needs to run within minutes of a new event being confirmed in your system.

How Do You Handle Personalisation Without Overcomplicating It?

The Songkick model is explicit follows plus location. Users follow artists, and they get notified when those artists play nearby. This is simple, works well, and avoids the cold-start problem entirely for active users.

Recommendation (suggesting artists the user hasn't explicitly followed) is a second-order problem. Do not build it in v1. The data you need to do it well — listening history, event attendance, social graph — takes time to accumulate. A content-based collaborative filter built on top of Spotify listening history is a reasonable v2 approach once you have OAuth connections.

For location, store user location as a PostGIS point and run a configurable radius query (default 50km, user-adjustable) against event venue coordinates. Most users want city-level granularity, not street-level precision, so you do not need GPS; a saved city preference works fine.

Ticketing Integration: Affiliate vs. Direct

This is the commercial architecture question. There are two models:

Affiliate: You link out to Ticketmaster, AXS, See Tickets, etc. via affiliate links. You earn a referral fee (typically 2–5% of transaction value). Zero inventory management, zero payment processing risk, but you lose the user at checkout and have no visibility into whether they actually bought.

Direct/White-label: You integrate a ticketing platform's white-label checkout (for example, Ticketmaster's resale partner programme or DICE's API) and keep the user in-app. Higher engineering cost, more regulatory surface area (PCI DSS compliance if handling card data), but better conversion data and potentially higher margin.

For a v1, start affiliate. The engineering effort for direct integration is significant and the commercial relationships take time to negotiate. Re-evaluate once you have traffic data showing that affiliate drop-off rates are costing you materially.

What the Infrastructure Looks Like at Scale

At the scale Songkick was operating (roughly 10 million monthly active users before the Live Nation acquisition in 2017), the ingestion pipeline processes tens of thousands of events daily across hundreds of venues. Your architecture needs to account for:

• Idempotent ingestion: The same event will arrive from multiple sources. Your pipeline needs to detect duplicates using a combination of (artist_mbid, venue_id, event_date) as a composite key before inserting.
• Venue normalisation: Like artists, venues need canonical entities. Google Places API IDs are a practical anchor here.
• CDN for media: Artist images and venue photos should sit behind Cloudflare or AWS CloudFront, not be served from your application server.
• Rate limiting: External APIs impose rate limits. Ticketmaster Discovery API allows 5 calls per second on the free tier. Build exponential backoff with jitter into every API client from day one.

At early stage (sub-100k MAU), a single PostgreSQL primary with one read replica, a small Elasticsearch cluster, and a managed queue service on AWS or GCP is entirely adequate. Do not over-architect early.

Conclusion

The core engineering work is event ingestion, entity resolution, and geospatial notification delivery. Everything else (recommendations, social features, direct ticketing) is an iteration on top of that foundation.

If you are evaluating whether to build this in-house or with a development partner, the honest consideration is entity resolution and third-party API integration. These take longer than they look on a spec sheet. Getting your artist disambiguation pipeline wrong means persistent data quality issues that are expensive to fix later.

The next concrete step is to map your target markets to available API coverage, then prototype the ingestion and deduplication pipeline before committing to a full product build. That proof of concept will tell you more about timeline and cost than any estimate based purely on feature lists.

---

FAQ

How long does it take to build a Songkick-like app? A functional v1 covering ingestion, artist following, location-based alerts, and affiliate ticketing links takes roughly 4 to 6 months with a team of three to four engineers. That assumes existing familiarity with the third-party APIs involved. Full personalisation and direct ticketing integration adds another 3 to 4 months.

What is the biggest technical risk in a concert discovery app? Artist entity resolution is the most commonly underestimated problem. Poor deduplication means users miss events because an artist appears under a slightly different name in your database. Allocate dedicated engineering time to the normalisation pipeline before anything else.

Do you need a music licence to build this kind of app? Not if you are only displaying event information and linking to ticketing partners. You are not streaming audio. If you add audio previews via Spotify's embed API or similar, those come with their own usage terms, but the core concert discovery functionality carries no music licensing obligation.

Can you build this on a no-code or low-code platform? The front-end and basic event display can be prototyped in tools like Bubble or Webflow. The ingestion pipeline, entity resolution logic, and geospatial queries require custom code. No current low-code platform handles the deduplication complexity at any meaningful data volume.

What is the typical cost to build a Songkick competitor? Costs vary significantly by market and team structure. A lean offshore team might deliver v1 for $80,000 to $150,000. A senior product team in a major Western market would cost considerably more. The bigger variable is post-launch data quality work, which is consistently underbudgeted.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.