Final

UPDATE: Note to Teaching team

Our deployment server was affected by a 0-day vulnerability discovered during the final exam period after the project deadline has passed (See CVE-2025-55182 for details). This vulnerability is caused by React flight protocol and affects many Next.js-based websites. Our application was brought down by an external attack, where the attacker attempted to run unrelated code and services but crashed the server instead due to insufficient memory.

We have since updated the dependencies and redeployed our server using the new version on the master branch. However, as this is a fresh deployment, it will not contain all the same data as the ones shown in our demo video. Also, since we have reached the end of the semester and are in the holiday season, not everyone on the team is reachable to recreate all the connections to 3rd-party APIs in the new deployment. Despite this, we have tried our best to set everything back up. Currently, the only thing that is not yet set up is Instagram and YouTube scheduling (from CUJ 4), which worked in our previous deployment. Though you should still be able to see the demo of these features in our video linked below. We apologize for any inconvenience and thank you for understanding.

Product Overview

TL;DR

k.ai is a centralized platform for independent musicians managing their post-creation workflow. We address productivity struggles, fragmented workflows, and the lack of planning by unifying release management, social media promotion, and career planning in one place. Musicians get AI-powered personalized guidance, automated task generation, and seamless multi-platform integration, which eliminates context switches and helps them focus on music while building sustainable careers.

JTBDs

1. As an independent musician, I want to be able to keep track of every task that needs to be done so that I can stay organized on the path to a successful release.
2. As a musician who is planning to release or has just released a new song, I want to efficiently promote it on all my social media profiles/pages, so that I can expand my following for better marketing.
3. As an emerging artist, I want the platform I use to have a clean and intuitive interface, plus simple and affordable payment options, so that I can save time and money to focus on the music itself.

CUJs

CUJ 1

The user can see a task list and a progress percentage indication on the dashboard within the current release strategy. This reflects the overall status of release tasks.

CUJ 2

The user can see a list of tasks associated with the timeline, and can click on/expand them for more details.
The user sees a release timeline from the dashboard with a list of to-dos. They can click on a task to expand it. There will be a detailed panel showing:

• Task title
• Status (Not Started, In Progress, Completed), with a clickable status that allows the user to switch between “Not Started” and “In Progress”, and a checkbox which marks complete for the task.
  • A checkbox which marks a task as complete
• Notes field
• Delete task

CUJ 3

The user can create, edit, and delete tasks on the release timeline.

• Creation: The user types the new todo, and hits enter to add a new todo. The progress bar updates accordingly.
• Mark task as complete / incomplete: The user clicks on the checkbox at the front of the todo. The progress bar updates accordingly.
• Change status property: The user clicks on the status property to change the status from Not Started to In Progress or vice versa.
• Add / Edit notes: The user clicks on the task. In the detailed dropdown, they click on the notes field to edit it.
• Delete: The user clicks on a task. In the detailed dropdown, they click “Delete task”. The progress bar updates accordingly.

CUJ 4

The user navigates to the “Social Media” section from their release dashboard. Then, they create a post by:

• Uploading image files
• Writing custom captions

The user selects target platforms, such as Instagram, Tik Tok, X, or Facebook via checkboxes. They then choose scheduling options by clicking either “Post Now” or “Schedule Post” buttons.

CUJ 5

The user can log into their account using their email to access the system, view their artist profile, and manage relevant information. New users can go to the signup page with the signup button

CUJ 6

The user answers 3 onboarding questions after they sign up. Based on their selections, they will see different pre-set tasks.

MVP Development Justification

Initial Hypothesis

Core Problem: We first identified the challenges independent artists face against the systemic and platform advantages enjoyed by established artists and record labels. We can see that emerging artists are massively disadvantaged in terms of utilizing resources and platforms. They lack the time, capital, or tools to address their needs optimally; hence, they struggle to release and promote music due to fragmented tools and time constraints.

Initial Product Idea: A user-friendly tool that would bring together artists’ distribution management, release management, task management, and promotion tools.

Assumptions:

• Users are independent artists aged between 18-35, who are tech-capable and already tool-reliant for managing their musical career.
• Users already utilize social media to promote their music, yet are unable to handle these processes from a unifying tool, and the existing solutions are inaccessible or too costly.
• Our assumption around the key JTBDs revolved around task management, efficient social media promotion, and intuitiveness, alongside affordability.

Key Learnings & Pivots

Social Media Management: One of the key revelations during development was the difficulties the musicians are facing with multi-platform social media management tools. Our initial assumption was that we could easily rely on any third-party social media management tools or straightforward platform APIs to support multi-platform posting. As we wanted to test out existing solutions as well as for integration purposes, we tried several methods and services: Hootsuite, Ayrshare, platform-specific API implementations... Third-party services were too costly, while individual platforms made it intentionally difficult to integrate with, gatekeeping their services and requiring reliance on visits to their applications, which led to a loss of time for the artists.

Our research into multi-platform social media management tools and our efforts for integration validated our concerns and pain points raised by customers. In addition, we backed this initial assumption, which is validated by our own integration efforts, with a series of user surveys where independent musicians highlighted this pain point.

Finally, we settled on an open source service, Postiz, completing integration for Instagram and YouTube. As social media management was one of the key points raised, we dedicated effort and time to supporting at least two platforms through our solution.

Deployment as a Requirement: Our initial Postiz setup was hosted on a local machine, and we believed this would meet the MVP requirements. As we progressed with integrating Instagram through Postiz, we observed that Instagram(alongside TikTok and Facebook, among many others) rejected the uploaded images on the Postiz side for communication to the Meta API. Postiz API worked well on file upload, but the communication failed once the content was being sent to Meta applications.

Upon further research, we have identified that the Meta API requires the URL to be public if it is being utilized for image transfer and posting APIs. This led the team to consider options around the resolution of this issue. Though deploying to the cloud is a definite long-term solution, we were also considering a short-term option to utilize ngrok - a service that creates secure tunnels from a public URL to a local development server. In the end, we pivoted and decided on a production-like deployment to a server/cloud, which made our Postiz endpoints accessible to the rest of the team for testing and integration purposes.

Personalization Through AI: During our competitive CUJ, we went through a series of use cases to test out IndieFlow. The platform had many issues, but one key feature that they were unable to do justice stood out for us. The platform had an onboarding survey that the users had to take. However, the resulting task list/template poorly affected users’ experience. The relation between the questions and the resulting template was inexplicable. This led the team to brainstorm about how the onboarding process can be done better. As a result, this led to the prioritization of the utilization of AI within our product. Now, the answers users give to our well-curated onboarding questions lead to a personalized initial task list. In addition, the users are capable of interacting with their releases & tasks and receive personalized insights.

Key pivots are as follows:

Key Pivot	Development-Based	User-Research-Based
Social Media Management Integration Choices	X	X
Decision to Deploy	X
Prioritization of AI		X
Enhanced Onboarding		X

Justification of Final MVP

As our key JTBD, task management, is validated by user research, we proceeded with keeping it a core component while equipping it with multiple user authentication, database persistence, and session management that gives users of the MVP the true ability to perform end-to-end task management flows. Multiple users can simultaneously interact with their unique releases and tasks, not needing to initialize a user every time they are using the MVP. The **calend...

A9: Demo 4

Direct links to all submitted files

• ADR8
• Frontend changes

Roadmap Update

Progress Update

TL;DR

We deployed the k.ai platform to production using Azure Virtual Machines, with Next.js running as a native Node.js server and Postiz services managed via docker compose. Security is handled through Nginx as a reverse proxy with HTTPS. On the frontend, we connected core components to the Prisma database and had the UI updated. For social media integrations, we can now post to YouTube using the Postiz social media management tool.

Roadblocks

Our initial Postiz setup was hosted on a local machine. As we progressed with integrating Instagram through Postiz, we observed that both Instagram and Facebook rejected the uploaded images on the Postiz side for communication to the Meta API. Postiz API worked well on file upload, but the communication failed once the content was being sent to Meta applications. Upon further research, we have identified that the Meta API requires the URL to be public if it is being utilized for image transfer and posting APIs. This led the team to consider options around the resolution of this issue. Though deploying to the cloud is a definite long-term solution, we were also considering a short-term option to utilize ngrok - a service that creates secure tunnels from a public URL to a local development server. In the end, we decided on deploying to server/cloud, which will make our Postiz endpoints accessible to the rest of the team for testing and integration purposes.

Deployment

We investigated our deployment options and settled on Azure Virtual Machines. We have deployed our Next.js web application as a native Node.js server, and the Postiz service stack (Postiz, PostgreSQL, Redis) using docker compose. The connection between the client and server is secured by https through the use of Nginx as a reverse proxy. Right now, we are using pm2 to manage the server process, but we may look into packaging our Next.js application as a docker container in the future to streamline our deployment process.

Social Media Integrations

We set up YouTube on our deployed Postiz and are able to post a video using the Postiz UI. We encountered a port-related issue during the setup, which we were able to resolve.

Issue Summary

Issues (closed or ongoing) fall under:

• Frontend: #4, #5, #8 (IPR)
• Social media integration
  • YouTube #20
    • Setup #75 (closed)
• Deployment
  • Research #52 (closed)
  • Deploy to Azure #78, #79, #80, #81, #82 (closed)

Summary of Architecture Changes

We deployed using Microsoft Azure Virtual Machines. See ADR8 for more information.

Roadmap Change Details

Decisions Log

This week, we have decided on deployment over hosting locally, investigated our options for deployment, and proceeded with our deployment using Microsoft Azure Virtual Machines. See ADR8 for more information.

UI / UX

At frontend, the major action is connecting the components to the backend and database while ensuring most of the features are usable. We designed UIs for the login page and signup page. User can register for an account with their email address and a password which is at least 8 characters long and login with the account freely by sending API requests to the backend. Besides, the AI chatbot UI upgrades to be more intuitive as a real chat interface which keeps record of user’s prompts. The AI model fetches user’s info of releases and tasks, and can answer specific questions based on user’s input on these sections.

Milestone Update

We are breaking down our milestones into features (Previously our milestones are short-, mid-, and long-term features.) There will also be dev-related milestones (e.g. deployment).

Feature milestones:

Feature	Frontend	Backend
CUJ1-3. todo list	Completed, but fixing bugs	Completed.
CUJ4. social media scheduling	Completed except uploading media and platform-specific settings (e.g. whether a video is public on YouTube)	Integration using Postiz: YouTube: can post using Postiz UI; getting started with code. Instagram: getting started.
CUJ5. Log in / auth	Completed	Completed
Release timeline	Completed, but fixing bugs	N/A
Calendar	Completed, but fixing bugs	In-progress
AI chatbot	Completed	N/A
User profile	In-progress	Limited

Dev-related milestones:

• Testing
  • Integration and unit tests written for auth and todo list
• Deployment
  • Completed this week
• CI / CD
  • Completed

Next Steps

• Enable users to post to YouTube and Instagram
• Finalize UI designs
• Social media scheduling frontend: uploading media and platform-specific settings
• Write more tests

Pull Request(s)

#73 - frontend - chatbot UI, Connect components to prisma database, Finalize login and signup UIs
#85 - ADR8: Deployment Choices

A8: Demo 3

Direct links to all submitted files

• Changed files - Tasks API
• Changed files - Dev frontend
• Changed files - CI/CD Automation
• ADR 006
• ADR 007
• Architecture diagram description

Roadmap Update

Progress Update

TL;DR

We continued our work on the backend APIs, CI/CD pipelines, frontend UI design, and social media management integrations. These progress and improvements aim to bring our users a fast, reliable, and simple system. They also automate and speed up the testing process for developers.

Backend Tasks APIs

We continue to work through implementing our backend APIs. This time it includes task-related APIs. They include the typical operations of retrieving or updating data from the database from a REST request, and returning the result to the user. We also included a suite of unit tests and integration tests to ensure that the implementation works and continues to be functional in the future as we make further changes in the codebase. These tests can be run manually through npm run test during development, or triggered automatically as detailed in our next section.

CI/CD Pipeline

Continued from last time where we set up a testing framework, we implemented a CI/CD Pipeline based on that to automate linting and testing during development. We are using ESLint as a simple linter, which is bundled within our Next.js install. It detects formatting issues like unused variables or ambiguous types like any, overall helping with our code quality and improving ease of maintenance. We also included a build step in our pipeline to confirm that our code actually builds without error. Note that we do not have a deployment step yet, as this pipeline only applies to the dev branch and not the main branch, and is triggered on push or pull requests. We plan to create another pipeline that includes a deployment step for the main branch as one of our next steps.

Social Media Management Integrations

Postiz is adopted as the backup solution to Ayrshare (see below for the reasoning around the decision). Despite some initial issues around the Docker setup & configuration, the tool is successfully deployed and can be self-hosted as it is up and running. The team is testing out Postiz’s functionalities and the API suite for further integration.

Frontend UI Design

Built core UI components using React and TypeScript with local storage for data management. The calendar supports day, week, and month views with event creation, scheduling, and recurring event options. The release timeline lets user track music releases with milestones, progress bars, and status updates (planning, in progress, updated). The social media component handles post creation across multiple platforms, including Instagram, X, Facebook, and Tik Tok, with draft, scheduled, and published status tracking. The AI chatbot integrates with Gemini API to provide real-time music release advice. All components use a consistent design with Tailwind CSS for styling and maintain their state through browser local storage.

Issue Summary

Issues (closed or ongoing) fall under:

• Backend Tasks API: #65, #67 (closed), #40 (IPR)
• CI/CD Pipeline: #50, #51, #57, #58 (closed), #13 (IPR)
• Third-Party Social Media Management Integration: #66 (closed), #68 & #69 (IPR)
• Frontend UI Design: #45 (closed), #4, #18 (IPR)

Summary of Architecture Changes

Our social media API was changed from Hootsuite to Postiz as the latter offers a free self-hosting option, allowing us to lower our Cost of Goods Sold. We added a LLM API, Gemini, to support chatbot functionality with its fast response times.

Roadmap Change Details

Decisions Log

Social Media Management Integration

Due to the limitations on rates for the free account, the team reached out to Ayrshare for a potential collaboration focused on educational purposes. Though we received a response, it was not exactly to our benefit. Hence, the team started looking into a potential backup option, an open-source social media scheduling tool: Postiz. Although Postiz is also a priced option, as it is open-source, it offers a free option in the scenario where the tool is self-hosted. Positz self-hosting was successful and team is testing out its functionalities and API suite.

Architecture Updates

For social media management integration, we chose to use Postiz as our API suite. Details of our decision are in ADR 006.

We added a LLM API, Gemini, to support chatbot functionality and allow intelligent personalization needed for, e.g., todo list generation. Gemini’s fast response time is great for real-time chatbot interactions. Details are in ADR 007.

User Research

We synthesized our survey and interview responses in CSC454 to come up with four features that each represents a value proposition. The features are:

• Personalized To-Do List Creator
• Flexible Promotional Content Generator
• Master Schedule
• Community Social Network

This is how it connects to what we are building in CSC491.

• the 454 to-do list creator is part of the 491 release to-do list
• the 454 promo generator is a mid to long-term extension for 491's social media post/scheduling feature. Promo generation can be mocked if we have time.
• the 454 master schedule is a calendar for our MVP. If we have time, we will mock the calendar to show the time-saving benefits of a unified calendar
• the community social network from 454 is a long-term goal in 491 that we are not pursuing right now before the end of the semester, but our user registration/login system in the backend will be able to handle the social network if we ever get to that phase.

Next Steps

• As we are approaching the final demo, we should think about how we would tie everything together, the existing front-end, back-end, and services like Postiz. Then we can get a good idea of the gaps that we need to fill in to make a complete MVP.
• We should also update our CI/CD pipeline as requested in the final handout to include coverage report, and additionally include deployment instructions.
• We should conduct user testing sessions with potential indie musicians to gather feedback on our UI/UX design and feature set. This will help us validate our assumptions and identify any usability issues before the final demo.

Pull Request

#64: Tasks API Implementation
#62: Frontend UI Design
#60: CI/CD Pipeline for dev branches
#63: ADR006 - Postiz
#70: ADR007 - Gemini
#71: Architecture Diagram Updates

A7: Competitive CUJ

Summary and Progress Update

Completed a comprehensive competitive analysis of IndieFlow, a direct competitor in the release management space for independent musicians. Evaluated their core features through hands-on testing and documented critical insights that inform our product differentiation strategy.

Our A7 submission is in the link below. A condensed key findings is afterwards.

Submitted Files

A Competitive Analysis of the Indieflow Music Management Platform
Same file as above on GitHub repo

Key Findings

User Journey Analysis

Analyzed IndieFlow's onboarding and task management features through the lens of our target persona: Jennifer, a 23-year-old independent musician preparing her first release.

Total Time: 1 hour 1 minute
Context Switches: 8

Major Findings

Indieflow's Strengths

• Personalized onboarding with goal-based recommendations
• Template-based release planning
• Collaboration features

Critical Weaknesses

• Severe bugs in core features (due dates not saving, duplicate tasks)
• Broken Distribution feature despite being first recommendation
• Non-functional social media integrations (Instagram, Discord)

Product Differentiation

Our competitive advantage lies in two key areas:

• Deep Customization: While IndieFlow uses generic templates, we'll generate truly personalized to-do lists based on rich onboarding data about each musician's specific goals, release stage, and context.
• Quality & Reliability: IndieFlow's production issues highlight the importance of thorough QA and stable core functionality.

Next Steps

• Ensure core task management features are thoroughly tested
• Continue iterating on UI/UX with focus on clarity and usability

A6: Demo 2

Direct links to all submitted files

• Changed files - Auth APIs and tests
• ADR 005

Roadmap Update

Progress Update

TL;DR

We worked on the backend APIs like auth according to our tech specs from last time, and created tests for it using the Vitest testing framework. We created a prototype on Figma to demonstrate and keep records of frontend designs. We redesigned the front end dashboard to align with our plan. In addition, we continue to explore social media APIs. For user research, we focused on identifying our value proposition and validation. Lastly, we updated the description of a JTBD according to instructor feedback.

Backend Auth APIs

Starting implementation of our planned backend APIs: auth related libraries and APIs. This includes user signing up, logging in, logging out, and other auth actions. As this is the first set of backend APIs we are implementing, this can serve as an example for other backend components in the future for how we define API routes, interact with the database using Prisma, defining TypeScript types, extracting common logic into our private lib library directory, etc.

Testing Framework

We also set up a testing framework with vitest, created unit tests and integration test suites to run during development.This makes sure that we can fix any bugs that arise during development, not after merging into the master branch. Future tests for components written by other team members can also follow a similar format. We can also choose to include a GitHub actions CI/CD pipeline in the next stage of development to automatically run the test cases on each push and pull request to verify that the features are functional.

A detail worth mentioning here is that, for each test case to be “atomic”(not break other tests if one case fails) and function correctly on their own, they must not depend on the previous states of the database, as that might introduce inconsistencies in tests, and mask potential errors from occurring or cause others to occur. To address these issues, we created a testing utility that creates a copy of the dev database, and runs the Prisma using that database instead. This database is reset after each test to the initial state, and removed after all tests are complete.

Frontend design in Figma

We are currently redesigning the frontend UI to align with our product requirements and incorporate insights from ongoing user research. This redesign focuses on creating a cohesive and professional interface that resonates with our target customer of independent musicians aged 18-35.

Our current comprehensive design includes:

• Dashboard/Timeline view: Visual progress tracking with an intuitive task management interface that address our JTBD 1 (keep tracking of tasks for successful releases)
• Task Detail Modals: Expandable views with inline editing capabilities

Issue Summary

Issues (closed or ongoing) fall under auth APIs, testing framework, Figma design, user research, other issues. Auth-related libraries and APIs were set up; related integration and unit tests were created. For Figma designs, a prototype for the todo list feature was created. User research involved validation and identifying a value proposition.

• Auth APIs: #9 (closed)
• testing framework:
  • testing Auth APIs: #48 (closed)
• Figma design:
  • frontend designs #43 (contains 3 issues for different pages and high-level user flow: closed: #44 (todo list); ongoing: #45, #46)
• User research:
  • Validating need for features: #47 (closed)
  • Identifying value proposition: #53 (ongoing)
• Other issues:
  • Product requirement document updates:
    • Updating use_case.md according to instructor feedback #54 (ongoing)
  • Learning: #38, #39
  • Tool exploration: #37
  • Other opened issues:
    • Social media API-related: #41, #42

Summary of Architecture Changes

For unit and integration testing, we chose to use vitest as our testing framework. Details of our decision are in ADR 005.

Roadmap Change Details

Decisions Log

Testing Framework

We decided that we are using Vitest as our testing framework. See ADR 005 for details.

Social Media Tool Choice

Currently, the team is finalizing the search for a social media integration tool. Ayrshare is contacted for a potential student benefits plan. Another alternative is Postiz, an open-source social media management and scheduling tool. Additionally, Postiz can be self-hosted and deployed on the cloud for free. A decision the team came across around the scope of the MVP was the choice between limited API integration with a single platform of choice and limited number of tokens for a third party API suite. The path to take is to be decided based on responses we will receive from the third party platforms. In the scenario of a self-hosting decision, the integration with Postiz will affect the overall architecture.

Architecture Updates

For unit and integration testing, we chose to use Vitest as our testing framework. See ADR 005 for details.

User Research

• We looked at a new survey response to see if there is a need for our existing features
  • The respondent found it important to have a customized checklist based on his goal, validating our JTBD 1 on tracking tasks. However, we thought that we could improve our customization:
    • Improving customization: we collect information about the musician’s release goals right when they start using the app. We use this information to immediately generate a list of tasks related to their goals
  • New interview also confirmed the validity of our direction
• We began identifying our value proposition. In addition to improved customization mentioned above, another differentiating feature is:
  • Promotional content generation: users can select to generate content either from scratch or supply partially completed promotion to be further finessed and market ready.
  • We will focus on either promotional content generation or task generation first.

Next Steps

• Continue implementing backend APIs alongside their tests
• Finalize complete User Flows to fully flesh out UI requirements
• Create a CI/CD workflow for linting, testing, and (maybe) deployment
• Create our first end-to-end test when we have a flow with both frontend and backend.
• Competitive Critical User Journey
• Updating architecture diagram to include AI platform

Pull Request

Auth APIs and Tests #49
Docs update (JTBD & ADR5) #55

A5: Demo 1

A Note on Our Code

We added our code directly in the repository that we used in our previous assignments.

Direct links to all submitted files

• ADR 004: Ayrshare
• Nextjs API specification
• Changed files in codebase

Roadmap Update

Progress Update

Initialized repository and created Next.js project. We onboarded all members into the project, everyone set up relevant dependencies and libraries, and was able to run the test application alongside our database of choice. We then went on to design and create a database. We also discussed and wrote down detailed technical requirements, database schema, APIs specifications, and code directory structure to implement for the project. (See section below for more details)

We also created an initial implementation for our frontend dashboard with an interactive task list which allows users to add or delete a task. The user can add a task by typing in the title, then they can further add notes and change status. The progress of completing tasks is reflected on a progress indicator.

We took a more detailed look into our options for our social media APIs. Since the project requires handling of multiple social media platforms and profiles, a centralized approach towards third-party API handling for social media platforms was needed. We did a deep dive into what’s been settled for the previous check-in, Hootsuite, and decided that an API-based solution rather than an application with exposed APIs would be a better option. Currently Ayrshare is being utilized for testing purposes. The team was able to create and publish a post using the Ayrshare API suite.

Issue Summary

Our issues fall under our JTBDs. In the frontend, we worked on the release todo list (JTBD 1). Backend work involved posting to social media via Ayrshare (JTBD 2). We also completed infrastructural tasks (JTBD 3).

• Release task management - Frontend: #4 (Ongoing)

  • Subtask: #31 (Closed)

• Social media management - Posting to Instagram: #15 (Ongoing)

  • Subtasks: #26, #28, #29, #30 (These issues were created, worked on, and closed.)

• Infrastructural tasks and Systems Design: #6, #22, #32, #33, #34 (Closed)

Summary of Architecture Changes

For our social media API, we decided to switch from Hootsuite to Ayrshare for testing purposes. We explained our decision in an ADR.

Roadmap Change Details

Decisions Log

We made some major decisions as to how we should actually implement our platform as a web application. Last time, we mentioned that, for our MVP, we were using a monolithic Next.js web server with REST APIs, using Prisma ORM with SQLite as a development database. This week, we held meetings to decide on the details with our JBTD/CUJs from last week. We were able to determine the scope, and settle on which specific aspect of the application we would like to create, and cut out the parts where they are not part of our core functionality but might take a long time. By defining these requirements, we are able to proceed to the next phase of design by creating a first draft of our database schema and API specification. These details have all been documented in our internal technical specifications document for our future reference. (You can also see the API specs in ./architecture/api.md, database schema is available directly in our source code ./prisma/schema.prisma)

Architecture Updates

For our social media API, we decided to use Ayrshare for testing. We explained our decision in an ADR.

Afterwards, we thought that we made a good decision as Ayrshare helped us to overcome a challenge during testing. When we tried to publish the same test post twice, Ayrshare returned an error saying that Instagram does not suggest users to post duplicate content. A solution to this from Ayrshare is to send a post with a random text and image.

User Research

There was also ongoing user research on our customer this week, but we just heard back from them yesterday, so we did not have enough time to incorporate them into our product yet. More details in the User Research section below.

User Research

In CSC454, we sought to understand our customer through surveys and interviews. First, we developed customer personas and profiles for independent musicians to inform the design of our product. Through comprehensive customer research, we analyzed customer profiles thoroughly and validated our hypotheses on customer jobs, pains, and gains.

We developed three customer personas representing different experience levels: Tom (25, low-mid experience seeking audience growth), Stella (20, beginner overwhelmed by entry barriers, and Leen (33, mid-level artist managing growing operations). Market research and industry reports informed the identification of customer jobs, pains, and gains across functional, social, emotional, and basic need categories.

Customer profile analysis reveals that independent artists prioritize portfolio creation, promotion, and community forming as core jobs. Primary pains include feeling overwhelmed by complexity, time constraints, and concerns about maintaining authenticity in social media promotion. Key gains focus on time-saving through streamlined workflows, developing professional portfolios that attract opportunities, and building confidence through structured guidance.

Validations through surveys and interviews confirmed hypothesized jobs, pains, and gains. Community building emerged as slightly more important than initially predicted. The two respondents of interviews validated the pain of getting music heard and managing multiple responsibilities, though one of them resisted inauthentic promotional tactics. These findings suggest independent artists prioritize community engagement and streamlined management services.

Next Steps

• Develop frontend to incorporate the social media posting feature
• Work on API integration with more social media platforms
• Adjust roadmap based on future user research if needed
• User signup/sign in functionality with tokens
• CI/CD

Pull Request

#35 Setting up the development environment, initial frontend implementation, and exploring api options

A4: Tech Choices, Architecture Diagram, Roadmap

Summary and Progress Update

Decided on Tech Choices, created Architecture Diagram, Roadmap

Submitted Files

• Product Requirements (use_cases.md)
• Architecture Diagram

ADRs

• ADR 001: React.js & Next.js
• ADR 002: Prisma ORM + SQLite
• ADR 003: Hootsuite

GitHub Additions

• Projects
• Milestones

Issues and Pull Requests since last release

Planned short-, medium-, and long-term goals (as part of roadmap):

• short-term (until end of October): #4, #5, #6, #8, #9, #22, #15, #12, #7
• medium-term (until January 2026): #13, #18, #21, #10, #17, #20, #23, #24
• long-term (until September 2026): #11, #14, #16, #19

Changes to your roadmap, architecture, or use cases

Added roadmap, architecture diagram and ADRs, and JTBDs

A3: Critical User Journey Runthrough

Summary and Progress Update

Added a critical user journey for setting up and using the Meta Graph API, which will likely be part of our tech stack.

Submitted Files

CUJ Runthrough

• cuj_runthrough.md

Issues and Pull Requests since last release

#3 Adding critical user journey

Changes to your roadmap, architecture, or use cases

No changes to roadmap, architecture, or use cases in this release.

A2: Team Exploration - Bias and Diversity Reflection

Summary and Progress Update

Identified strengths and weaknesses, and evaluated the aspects of diversity in the team. We also explored how these things can affect us through unconscious bias, and identified ways to mitigate them.

Submitted Files

Diversity Reflection

• diversity.md

Issues and Pull Request since last release

#2 Adding diversity and bias reflection

Changes to your roadmap, architecture, or use cases

No changes to roadmap, architecture, or use cases in this release.

A1: Team Introduction, Team Setup

Summary and Progress Update

Initial release, added team profiles and readmes. We also came up with a team name and design for the company brand, then decided on our team principles and workflows for this project.

Submitted Files

Readmes

• README (logo and vision)
• Team README

Team Principles

• Team Principles

Team Profiles

• James Chen's Profile
• Kevin Hu's Profile
• Ali Eren Kaya's Profile
• Monique Mattia's Profile
• Yvonne Zhang's Profile

And images for team logo and photos (See PR below for details)

Issues and Pull Requests since last release

#1 Add profile markdown files and photos of team and update readme files

Changes to your roadmap, architecture, or use cases

This is the Initial release.