Write A Bad Song (WABS)
WABS is a musician-aid app that motivates users to write new music consistently through reminders, community, and accountability.
Problem Background
For music content creators, one of the biggest impediments is finding time or motivation to ensure that you are writing new music consistently. With Write a Bad Song, the goal is to assist musicians to produce music consistently through various features such as reminders and accountability.
Research Insights
The primary customer (for this MVP) will be musicians and music content creators that write their own lyrics and music. Based on our survey (n=12), the majority of musicians noted that they are not writing lyrics/music on a consistent basis, and wishes that they were able to track their content creation goals better. We also know that the time and inspiration to write a piece of music varies greatly between each musician (and for each piece for that matter), and 75% of our respondents will often/sometimes get writer’s block which impedes motivation. Lastly, 66% of our respondents said that they are either unorganized or very unorganized in their writing process which leads to further inconsistencies in writing. The minority of users who didn’t have any of these issues are full-time professional musicians who write music for a living. For these reasons, our App can help musician users stay organized and hold them accountable for their music creation goals.
Solution Explanation
After reviewing the survey results and brainstorming with our Resident Musician & CoLab 28 Developer, Lee Dyer, the app will provide a comprehensive solution for the musician to create musical content consistently. What these features are include:
- Goal Setting feature: Our app will ask the musician users on how many songs they want to create in a period of time to set their music creation goals/milestones.
- Reminder feature: This feature will remind the users that they need to continue writing music, remind them of their deadlines, or remind users that they have a calendar block to write music. This will be done via SMS, WhatsApp, Notification, Email, etc. Also, users can respond to the SMS by stating they have completed this task already, started, etc.
- Accountability feature: This feature will create a buddy system either with another user, our platform, or social media to “pressure” the user if they are falling behind on their goals.
- Calendar feature: You can specify a time of day when you want to block off for music writing. This is connected to your reminder setting and integrated to your Google Calendar etc.
- Milestone feature: You can set mini-goals for each piece of music you write, so your progress is bite-sized.
- Journal and notes feature: This is where you can keep journal and notes on your progress, and you can also add the lyrics you’ve written. You can share these entries with your friends, colleagues, and groups. Users can speak and our app can transcribe.
- Onboarding feature: Our app can match your style of music creation and curate your journey based on this. For example, some musicians are music first before writing the lyrics, vice-versa. Some musicians only write music not lyrics. We want to individualize each profile to fit the user’s creation style.
- Sharing feature: After the music has been created, you can share it with your fellow circle of users within our app or on a major social media platform e.g. soundcloud, youtube, etc.
Lofi & Hifi Mockups
The lofi mockups were based on user research and the existing website that our Developer originally started. We wanted to emphasize the community aspect of the app since the people I interviewed inferred that collaboration with other musicians was sometimes challenging. Here is a copy of the lofi mockups.
The hifi mockups changed some of the components and design patterns. I also chose a color palette based on the existing website but with hues that provided better contrast. I wanted to keep the typography simple, so I stuck with Roboto. Many of the design patterns were inspired by Duolingo.
Here are some of the HiFi mockups:
Iterative Design Learnings
After we showcased our prototype to the users again, we learned that users typically like the desktop version more. This was because it is easier to type on a desktop than on mobile. They also commented that it was easy to use and they thought it would be a great app to log their songs.
Technical implementation
- Where is it hosted - https://vercel.com/
- What is your tech stacksome text
- Backend Framework - Supabase, Node Server for Email (Hosted on Render)
- Frontend Framework - React
- CSS Framework - Tailwind
- Database Choice - Supabase
- Other Tech used - Twilio for SMS reminders.
High level journey of a request
- We chose Supabase because it is a new system that seems to be an all-in-one solution that includes authentication, SQL, and especially File Storage. In the past, I’ve used Dropbox API and it has many authentication setup issues and uses third-party cookies that’s going to be deprecated.
- Walk-through of Application Functionality
Technical challenges
- One of the hardest parts of the development is not knowing if the tech stack we chose was the right one. It would be nice to have a veteran coder help out and provide guidance from that perspective. For example, we didn’t know that Supabase didn’t need a Flask App, so we spent a lot of time developing a Flask App when we didn’t need it at all.
- In terms of scaling, now that we figured out Supabase, there shouldn’t be any scaling issues. The only scaling issue would pertain to the subscription level and how much room it gives.
- Key Takeaway: “We’re idiots and we don’t know any better” - Lee.
Future Steps
As a team, we felt that we did a great job on creating the MVP in the 8-weeks and laying the foundation to build a great WABS App. For our developer, Lee, WABS is a passion project that he wanted to create and pursue, and one of the main reasons why he started to learn coding. For this reason alone, this evolution of WABS will continue. Furthermore, we all felt that we have so many user stories on our Trello Board that haven't been fulfilled in this MVP. In order to build a community around WABS and have users use it to write music , we needed to continue the roadmap that we created and continue on this journey.
Images
Learnings
Product Manager Learnings:
Andrew Chou
For me, part of my career in tech is working side by side with my product team to deliver the best customer experience and outcome for our customers. Learning the concepts of Agile and applying it with my team, I learned a great deal about teamwork, creating a common goal for each of our sprints, and learning about the tech stack that the Devs and Designer use to get their jobs done.
But furthermore, the WABS MVP taught me the fundamentals of building a program, block by block. After the completion of the program, I feel more confident working with my Product Team and may switch to Product in the future.
Designer Learnings:
Connor Bardine
Designer Learnings:
Jo Sturdivant
- Adapting to an Established Team: Joining the team in week 6 of 8 was challenging, as I had to quickly adapt to existing workflows, dynamics, and goals. This mirrors real-world situations where you often integrate into teams mid-project, and flexibility is essential.
- Work-Blocking for Efficiency: With only two weeks to complete the project, I learned the importance of a structured work-blocking system. This approach allowed me to manage my time effectively and meet deadlines under pressure.
- Making Data-Driven Design Decisions: Unlike my past projects, I had to rely on research conducted by others. This was a valuable experience in using pre-existing data to guide design decisions, helping me focus on the core insights without starting from scratch.
Developer Learnings:
Lee Dyer
As always, I learned the benefits of taking a deep breath and planning before you dive into the world of coding. If you can apply the 80-20 rule to coding, it's most likely 80% planning and 20% coding. Unfortunately, this is a lesson I've had to learn multiple times before it sinks in. I learned this lesson again and again in this project, most notably when my fellow developer and I realized we no longer needed the back end to work with Supabase. Another huge benefit from the course was the ability to focus on a single small part of a project.
After Anthony and I realized our mistake and moved Supabase to the client-side code, we set aside time to restructure the repo and set it up so that code must be pushed to main through a pull request from another branch. This meant that I needed to create a new branch for each individual bite-sized piece of work I did. This at first seemed like it would cause more trouble, but in the end, it kept me hyper-focused on each little task and kept me from wandering around the code base fixing (and breaking) little things like a kid in a candy store.
Developer Learnings:
Vanady Beard
&
As the back-end developer, I learned how important it is to create efficient and reliable systems that support the entire application. This experience also taught me the importance of optimising the database and ensuring the backend is scalable and easy to maintain.
Developer Learnings:
Stephen Asiedu
&
As a back-end developer, I've come to understand the importance of being familiar with various database systems and modules. This knowledge enables me to build diverse applications and maintain versatility in my work. I've also learned that the responsibility for making the right choices rests on my shoulders, guided by my best judgement.
Developer Learnings:
Anthony Lenzo
&
The experience of working with a team for the first time as a coder was invaluable. I was a little nervous about how things would go at first, if we’d really be able to finish a working product in less than 8 weeks. But when we learned and then put into practice the AGILE system of project management, along with the MVP concept, I became more confident that we would finish a halfway decent app. And we did!
I also learned how roles in teams can shift and that sometimes the best solution will involve me in a different way. Having a small team allowed that flexibility and actually gave me another chance to employ skills learned from my improv performance training. Gotta shift on a dime! I feel lucky that I was grouped with such talented, dedicated, and kind people, especially on my team, but really all of the Co.Labers. Co.Laborers? Co.Labradors? Co.Laborators! Ah! Duh! There’s the meaning of it all! Overall, I feel much more confident now in my ability to work with a team as a software developer. Go Team Ocho!
Developer Learnings:
Maurquise Williams
&
- Process of Creating an MVP: Developing a Minimum Viable Product (MVP) taught me how to focus on delivering core functionalities balancing between essential features and avoiding scope creep.
- Collaboration in a Real-World Tech Setting: This experience taught me how to collaborate efficiently in a fast-paced tech environment, keeping the team aligned and productive, even while working remotely across time zones.
- Sharpening Critical Thinking and Problem-Solving Skills: This experience honed my ability to think critically and solve problems efficiently. By tackling challenges and finding quick solutions, I sharpened my decision-making and troubleshooting skills in a dynamic, real-world setting.
Developer Learnings:
Jeremiah Williams
&
All in all this experience was very awesome I learned that in coding with others being transparent is key
Developers Learnings:
Justin Farley
&
I learned how important communication is when working with a team. Communication provides understanding, advice, ideas, and much more. While working with the product team, I’ve found that communication keeps everything flowing smoothly. Working with a team also showed me that every member brings something different to the table and we all have to work together in order to align and meet our end goal.
Full Team Learning
For our team, one of our first accomplishments was being able to work together remotely. All four of us live in different parts of North America, and being able to make time for each other and working a-sync proved that we can accomplish a lot while apart! Second, working as a team, we learned to use Agile to our advantage and began to systematically break down our MVP into chunks and user stories rather than trying to code in all directions. The discipline helped us focus better which helped us complete our MVP objectives.
Lastly, what we learned at Co.Lab pushed all of our boundaries. Our Devs used a new tech stack that they’ve never used and there were definitely setbacks, but it helped all of us learn and prepare for our respective careers in the future.