Click the banner to checkout our app
James Hearn · Elizabeth Salami · Mohamedamin Abdile · Rhys Postans · Mugheesa Ahmed
- Problem Statement
- Solution
- Future Scope
- Dependencies and Limitations
- Tech Stack
- Lessons Learned
- The Process
- Documentation
- Acknowledgments
Emerging artists need a platform that supports engagement, and discovery, enabling artists and fans to build a direct connection for listening, feedback and contribution.
Currently, music platforms are ran by record labels, manipulating recommendation algorithms by saturating the platform with content and paying for it to be prioritised. In addition to this, fans don't have a direct way to contribute towards an artists journey, or feel like they're a part of the growth of their favourite artists.
Longevity in the music industry is built on a foundation of loyalty between artist and their fans, and we believe Plugged-In Music can help to provide that method of communication and collaboration.
Our solution is a music platform that leverages quick-form content methods to help with the discovery of new music, with tinder controls and functionality. One of our core features, the discovery page, gives users the ability to be presented with random music snippets, along with two buttons allowing them to dislike or like in order to add those songs to their playlist. In addition to creating fast, quality playlists, each "💜" received is tracked and tallied increasing the total count for that artist. This gamification feature fosters competition among artists to increase their like count in order to appear higher on the leaderboard and in turn, gain more exposure.
Due to time constraints we were not able to develop certain features or functionality that we would have liked. For example, during our first stakeholder meeting we were provided an extensive list of social features that would help with artist outreach, such as stories, live streaming, and a contribution or donation system. In addition to these features, monetisation was briefly mentioned in the form of implementing subscription models. As a result we scaled back our mvp to focus on one core discovery feature as a proof of concept and then refining our platform to function and flow as seamless as possible.
| Feature | Description |
|---|---|
| Listening Parties | Set up a room with your friends to all contribute and listen to the same listening queue / playlist at the same time. |
| Live Streaming | Your favourite artists bringing the electric, passionate atmosphere of concert going live to you from the comfort of your home |
| Contributions | Creating intricate payment systems integrating third party services to accept contributions for artists. Such as studio time, audio equipment, merchandise and more. |
| Spotlight | Recognition for being one of the first few people to discover new up and coming artists, as well as loyalty spotlights for sticking around. |
| User Tailored Algorithm(s) | Tailored recommendation algorithms to display new music that fits your taste in your home feed, but also music from similar genres that might expand your world of music. |
- We are using the free / hobby version of Vercel and Supabase. This means we have to succumb to certain limitations, such as storage and bandwidth limits. Whilst this is quickly scalable by switching to premium versions, this must be monitored to ensure there is no downtime and no unexpected expenditure.
- Authentication is extremely complciated and must be secure, so we will be using Supabase's pre-built authentication systems that have proven security methods in place.
- Without contribution systems or unique discovery features, onboarding artists early on may prove difficult.
- Music storage is not only limited by Supabase's subscription plan, but it also presents complications regarding file size and how uploads are handled. For example, Supabase recommends setting up resumable uploads for files above 6Mb. We attempted this using tus-js-client but decided, due to time constraints, it wasn't feasible to continue. Alternatively we setup regular file uploads to a storage bucket, utilising supabase api, with file size limits of 8Mb.
-
We found Next.js to be far more efficient and effective to use than vanilla react. The directory based routing allows for cleaner file structure of layouts, pages and components, as well as clean organisation of API routes.
-
TailwindCSS allowed us to prototype and style to our wireframes, responsively, with ease.
-
Using Supabase to solve our authentication requirements and databasing with Row-Level security took care of one of our most complex problems, within minutes.
-
Using mock data was great as it allowed us to address the front end quickly, however, it also caused a bottleneck when we were ready to present real data and the backend wasn't ready.
-
Our team worked incredibly well together, utilising pair programming and daily stand ups to keep tasks organised and team members on track.
-
Spending the entire first sprint focusing on our team's core values, work processes and methods of conflict resolution allowed us to progress quickly throughout the remaining sprints.
-
Meticulously planning our database schema and wireframing our front-end gave us guide rails along the entire development process.
-
Conducting market research early helped us to tailor our approach, eliminating any need for trial and error, saving time in the long run.
-
Setting up the API early to streamline data fetching and setting empowers the DRY coding principle and allows for tidier code.
-
Prioritise your strengths over learning new things (80/20 rule), when faced with a time crunch
-
Setting up snapshot tests with Jest is easy, but testing Next.js API routes with Jest and Supertest is exceedingly more difficult
-
Utilise mock data for testing in Next.js, rather than trying to setup simulated API environments with Supertest
Deciding on using TypeScript over JavaScript:
|
Initial Decision: |
Final Decision: |
![]() |
![]() |
30 minutes to gather ideas onto the moodboard, 30 minutes to categorise the ideas we like:
|
Unorganised Moodboard |
Organised Moodboard |
![]() |
![]() |
Upon deciding on our tech stack, I put together the high fidelity wireframes over night and brought it to the team in the morning. We then worked on refining them together with low-fidelity wireframes and prototypes.
|
Low Fidelity Wireframes |
High Fidelity Wireframes |
![]() |
![]() |
Utilising google forms we conducted user research and attained critical feedback
|
Results |
|
![]() |
![]() |
![]() |
|
|
Weekly Goals |
Daily Standups |
![]() |
![]() |
|
Trello Development Tickets |
|
![]() |
|
We would like to thank the school of code for making this all possible!
School of Code Website - School of Code Github
A Very big thank you to Nathan and Nasa for giving us the trust and opportunity to work on this project.
Thank you to Nadeem for constanly checking in on us and reminding us of common pitfalls we could run into.
We also want to express our gratitude towards our mentors for helping us along the way and being that voice in our corner:
Guy Dunton · Azlan Cuttilan · Ben Ashley · Andrew Fitzpatrick











