I Built a Cross-Platform Music Sharing App With AI for Under £300

How I went from an idea to a live product on iOS, Android, and the web — without writing a single line of code myself.

I had a problem. My friends and I use different music streaming services. I'm on Spotify, some are on Apple Music, others on YouTube Music. Every time someone shared a song link, half the group couldn't open it. The link was useless to them. Most of the time we would resort to look up and share the song on youtube.

So I thought: what if there was a service that took any music link and created a universal one that works everywhere? That's MTShare. Here's an example — try this universal link and it'll open the song on whichever platform you use.

The catch? I'm a Linux systems engineer, not a software developer. I know my way around Python, I live in Docker and docker-compose, I can set up nginx, Prometheus, Grafana, and CI/CD pipelines in my sleep. But building a FastAPI application with SQLAlchemy models, a React Native mobile app, a Next.js frontend with TypeScript? That's a different world. I'd never written a line of JSX or TypeScript in my life.

My systems background turned out to be both an advantage and a limitation. I could handle the production side — containerisation, deployment, monitoring, networking — but the actual application code was beyond what I could write from scratch.

This is the story of how AI bridged that gap, what it actually cost, and what I learned along the way.

The Idea

The concept was simple: paste a Spotify link, get back a universal link that opens the same song on whatever platform the recipient uses. Spotify, Apple Music, YouTube, Amazon Music, Deezer, Tidal, SoundCloud, Pandora — all of them.

I wanted three things:

• A REST API that does the heavy lifting (parsing URLs, matching songs across platforms, generating short links)
• A website where people can create and share links
• Mobile apps for iOS and Android with share sheet integration

That's a Python backend, a Next.js frontend, and a React Native mobile app. Three repositories, three tech stacks. I could read the Python and understand the backend logic, but the React/TypeScript world and mobile app development were completely new territory.

Starting the Conversation

I started with Claude. Just a chat window and an idea.

The first few sessions were rough. I'd describe what I wanted, the AI would generate code, and I'd deploy it. But then I'd come back the next day with a new request, and the AI had no memory of what we'd built. It would suggest changes that conflicted with existing code, or re-implement things that already existed.

This is the context switching problem, and it nearly killed the project early on.

Learning to Steer

The breakthrough came when I discovered that I needed to give the AI persistent context. Not just "here's what I want today" but "here's the entire project, here's how it works, here's what we've already built."

I created two key documents:

A steering document — a markdown file that describes the project structure, the three repositories, the tech stack, workflow rules (like "always ask me about version bumps"), and architecture notes. This gets loaded into every conversation so the AI always knows what MTShare is and how it's built.

A todo.md — a living document tracking every bug, feature request, and testing recommendation. Each item gets marked with [x] when done, with a note explaining the fix. This became the project's source of truth. When I start a new session, the AI reads this file first and knows exactly where we left off.

These two documents transformed the experience. Instead of starting from scratch every conversation, the AI picks up right where we left off. It knows the codebase, the conventions, the history of bugs we've fixed and why.

Spec-Driven Development

Later I learned about spec-driven development — a more structured approach where you write requirements and design documents before touching code. For bigger features, this turned out to be invaluable. Instead of jumping straight into implementation, we'd first agree on what we're building, how the API should work, what the data model looks like. Note: I instinctively wrote "we", the AI chat agent and I... This is interesting as I do feel I have developed a working relationship with this thing, maybe I will need a human therapist at some point! :)

This matters because when you're collaborating with AI, the spec becomes the contract. It's the thing you both agree on before any code gets written. It reduces the "that's not what I meant" moments dramatically.

The Black Box Fear

I'll be honest about something: there's a genuine fear that comes with having AI write your entire codebase. You end up with thousands of lines of code that you didn't write and don't fully understand. What happens when something breaks at 2am? What if the AI made an architectural decision that paints you into a corner?

This fear is real, and I don't think it fully goes away. But here's what helped:

1. The architecture document. We created a comprehensive doc that maps out every component, every API route, every data model, every flow. Even though I didn't write the code, I understand the system because it's documented.
2. Incremental building. We didn't build everything at once. Each feature was a conversation, a small change, tested and deployed before moving on. I understood each piece as it was added.
3. The todo.md as institutional memory. Every bug fix includes a note about what was wrong and how it was fixed. When something similar comes up, there's a trail to follow.
4. Reading the code. My Python knowledge meant I could follow the backend logic and catch issues. The TypeScript/React side was harder, but over time I picked up enough to understand what the components were doing, even if I couldn't write them from scratch.
5. My systems background. I set up the production environment myself — Docker Compose, nginx reverse proxy, Cloudflare CDN, Prometheus monitoring, Grafana dashboards, the CI/CD webhook pipeline. That's all stuff I know. The AI wrote the application code, but I understood the infrastructure it runs on. That gave me confidence that even if the code was a black box, the box was sitting on ground I controlled.

Is it perfect? No. But it's a working product with real users, and I understand it well enough to maintain and extend it.

What Got Built

The final product is more than I originally imagined:

• A Python FastAPI backend with 10 platform parsers, 10 platform matchers, a song.link API integration that resolves all platforms in a single call, JWT authentication, Google and Apple OAuth, email verification, a community moderation system, automatic rank promotion, Prometheus metrics, and geolocation tracking.
• A Next.js website (mtshare.net) with universal link landing pages, user dashboard, trending charts (coming soon), community badges, blog posts, and light/dark mode.
• React Native mobile apps for iOS and Android with share sheet integration, deep linking that opens native music apps, and the same feature set as the web.
• A CI/CD pipeline with Bitbucket Pipelines, webhook-triggered deployments, Docker Compose production stack, Cloudflare CDN, Prometheus + Grafana monitoring.
• A community system with six rank levels, automatic promotion based on contributions, moderation queue for link corrections, and admin tools.
• Last.fm and Genius integration for metadata enrichment, lyrics links, and artist pages on every universal link. This one was particularly close to my heart — I used to work at Last.fm, so having their API woven into something I built felt like a nice full-circle moment.

All running on a single instance.

The Collaboration

What surprised me most was how natural the collaboration became. I'd describe a bug — "when I search for Otis Redding and select 'That's How Strong My Love Is', it returns unknown artist and track 'That'" — and the AI would trace it through the codebase, find that the Apple Music parser's regex was treating apostrophes as attribute delimiters, and fix it.

I'd say "the Spotify desktop app doesn't open on macOS when clicking from the universal link page" and the AI would identify that the deep linking code was mobile-only, then implement a try-native-first approach with a timeout fallback for desktop browsers.

I wasn't limited by my ability to write code. I was limited only by my ability to describe what I wanted. And honestly, that turned out to be the harder skill — being precise about requirements, thinking through edge cases, describing the user experience I had in mind.

Writing things down clearly is its own form of engineering.

What It Cost

Here's the full breakdown of what MTShare cost to build and launch:

AI-Assisted Build Cost

That's roughly £410 to go from idea to a live cross-platform product with mobile apps on both stores, a website, a REST API, monitoring, and CI/CD.

What Would This Cost Without AI?

Let's think about what the same project would cost the traditional way.

Option A: Learn the missing skills and build it yourself

With a Linux systems background, Python knowledge, and Docker experience, you'd already have the backend and infrastructure covered. But you'd still need to learn React, Next.js, TypeScript, React Native, Expo, SQLAlchemy ORM patterns, OAuth integration, and app store submission processes. That's realistically 4-6 months of learning before you could build something production-ready across all three platforms. The infrastructure costs would be the same, but you'd be paying them for months before launching.

Estimated cost: £250 in infrastructure + 4-6 months of evenings and weekends.

Option B: Hire a freelance developer

A full-stack developer who can handle Python backend, React web, and React Native mobile would charge £50-100/hour. For a project of this scope — API with 10 platform integrations, web app, two mobile apps, auth, moderation, monitoring — you're looking at 200-400 hours minimum.

Estimated cost: £10,000-40,000 + ongoing maintenance costs.

Option C: Hire an agency

An agency would scope this as a 3-6 month project with a team of 2-3 developers, a designer, and a project manager.

Estimated cost: £30,000-80,000.

The AI approach delivered the same result for under £500. That's not a rounding error — it's a fundamentally different economics of building software.

What I Learned

You don't need to be a full-stack developer to build a full-stack product. A systems background, some Python, and the ability to describe what you want clearly is enough. The AI fills in the gaps — the React components, the TypeScript, the mobile app code — while you handle the parts you know: infrastructure, deployment, monitoring.

Context management is everything. The steering document and todo.md are more important than any single piece of code. They're what make the AI a consistent collaborator rather than a forgetful assistant.

Spec-driven development works. Writing down what you want before building it saves enormous amounts of rework. This is true with human developers too, but it's especially true with AI where miscommunication means wasted tokens and wrong code.

The fear of the black box fades. Not completely, but enough. Good documentation, incremental building, reading the code you can, and owning the infrastructure it runs on go a long way.

AI doesn't replace thinking. It replaces typing. You still need to understand your users, design the experience, make architectural decisions, and test everything. The AI is a very fast, very capable pair of hands — but you're still the brain.

Yes, This Blog Post Too

In the spirit of full transparency: this blog post was also written with AI assistance. I described what I wanted to say — the journey, the costs, the comparison, the lessons — and the AI helped me structure and write it. Then I edited it to make sure it sounds like me and says what I actually mean.

That's the whole point. AI is a tool. A remarkably powerful one. But the ideas, the direction, the taste — that's still human.

MTShare is free to use. Share a song link from any platform and get a universal link that works everywhere. Available on iOS, Android, and the web.