Building an AI product often looks simple from the outside.
A user enters a prompt, clicks a button, and waits for the result.
But the actual product experience includes much more than sending a request to an AI service. The application needs to understand different types of input, manage long-running tasks, handle failures fairly, present results clearly, and give users enough confidence to try again.
These are some of the challenges I encountered while building Songvora, an AI song generator that turns text prompts, lyrics, and personal stories into complete songs.
This article focuses on the public product and engineering lessons behind the project. It intentionally leaves out provider-specific integrations, infrastructure credentials, internal APIs, and billing implementation details.
1. Why I Started Building Songvora
Many people have ideas for songs but cannot easily turn them into finished music.
Someone may have:
- Lyrics stored in a notes app
- A story they want to turn into a personal gift
- An idea for background music
- A mood or genre in mind
- A birthday or anniversary message
- A melody they cannot record or produce
Traditional music production requires time, equipment, musical knowledge, and experience with production software. Working with a musician is another option, but it may not be practical for someone who simply wants to hear an early version of an idea.
I started building Songvora around a simple question:
What if someone could describe a song in ordinary language and hear that idea as a complete track?
Songvora is not intended to replace musicians or professional music production. Its purpose is to make musical experimentation more accessible.
Users can begin with a prompt, their own lyrics, or a personal story. The product then helps transform that creative direction into a generated song.
You can explore the current version at songvora.com.
2. Why I Chose Next.js and FastAPI
Songvora uses Next.js for the frontend and FastAPI for the backend.
The two technologies serve different parts of the product.
Next.js for the product experience
The frontend needs to support both interactive application features and public content pages.
Next.js provides a useful foundation for:
- Interactive song creation forms
- Account and song-management interfaces
- Server-rendered landing pages
- Metadata and canonical URLs
- Structured content for search engines
- Localized routes
- Responsive product pages
The App Router also makes it possible to separate server-rendered content from client-side interactions.
This matters for an AI tool. The generation interface needs client-side state, while public pages still need meaningful content before JavaScript interaction begins.
FastAPI for generation workflows
The backend is responsible for application logic that should not live in the browser.
At a high level, it handles:
- Validating generation requests
- Managing user and task state
- Starting music generation jobs
- Tracking task progress
- Handling successful and failed results
- Managing credit-related product rules
- Returning completed audio information to the frontend
Python is a practical choice for AI-related service integration, and FastAPI provides a clear structure for typed API endpoints and service logic.
The public architecture can be summarized like this:
Next.js interface
│
▼
FastAPI application
│
▼
AI generation service
The actual production system includes additional operational details, but keeping the public explanation at this level is enough to understand the main separation of responsibilities.
3. Designing Different Ways to Start a Song
One of the earliest product lessons was that users do not all think about music in the same way.
A musician may describe tempo, instruments, arrangement, and song structure.
A content creator may only know that they need energetic background music for a video.
Someone making a birthday gift may not know any music terminology at all. They may only know the recipient's name, a few shared memories, and the message they want the song to communicate.
Because of this, Songvora supports several ways to begin.
Starting with a music prompt
Users can describe the intended sound using details such as:
- Genre
- Mood
- Tempo
- Instruments
- Vocal direction
- Song topic
For example:
Warm acoustic pop about reconnecting with an old friend, intimate vocals, gentle guitar, and a hopeful final chorus.
Starting with AI-assisted lyrics
Some users know the subject of the song but do not have lyrics yet.
They can describe the idea and allow the application to help prepare the lyrical direction before generating the track.
Starting with custom lyrics
Other users want control over every word.
They can provide their own verses, choruses, bridges, and production direction.
Starting with a personal story
A story-based workflow is useful for people who do not naturally write music prompts.
Instead of asking for technical production language, the interface can ask:
- Who is the song for?
- What is your relationship?
- Which memories should be included?
- What should the person feel?
- What message should the chorus communicate?
The frontend experiences are different, but they ultimately need to produce a clear and consistent creative request for the backend.
This separation has been useful: the interface can speak the user's language without requiring the generation system to become a completely different product for every input mode.
4. Handling Long-Running AI Generation
Music generation is not a typical request-and-response interaction.
A normal API request may return useful data almost immediately. A music generation task can take significantly longer and may pass through several stages before audio becomes available.
Keeping a browser request open for the entire process would create a fragile experience.
Instead, Songvora treats generation as a task:
Create request
│
▼
Validate input
│
▼
Start generation task
│
▼
Track progress
│
├── Completed → Present the song
└── Failed → Restore the user's credits
The important principle is that the backend owns the task state.
The frontend can display progress and request updates, but it should not be responsible for keeping the generation alive.
This provides several benefits:
- The user can leave the page while generation continues
- Refreshing the browser does not create a new task
- Completed songs can appear in the user's library
- Failed tasks can be handled consistently
- The frontend does not need a permanent connection to the generation service
It also changes how the interface should communicate progress.
A single loading spinner is not enough. Users need to understand that a task has been accepted, is still being processed, or has failed.
The exact internal task states are implementation details, but the user-facing experience should remain simple and predictable.
5. Designing for Trust When Generation Fails
Generative systems are not perfectly predictable.
A task may fail because of temporary service availability, invalid output, processing errors, or other conditions outside the user's control.
That creates an important product question:
Should users lose credits when they do not receive a completed result?
For Songvora, the product rule is straightforward:
A failed generation should not consume the user's credits.
The implementation details remain internal, but several engineering principles are important:
- Failure handling must happen on the backend
- Credit restoration must be safe to repeat
- Repeated status updates must not produce repeated refunds
- The application must distinguish a failed result from an unfinished task
- The user interface should explain what happened clearly
This is not only an accounting concern. It affects whether users trust the application enough to try again.
The free experience follows a similar idea. Users should be able to evaluate the product before entering payment information.
AI music also requires iteration. The first result may have the wrong energy, vocal direction, or arrangement even when the prompt is reasonable.
Giving users more than one attempt allows them to change the prompt and understand how their instructions affect the generated track.
The larger lesson applies to many generative AI products:
If output is uncertain, the product must be predictable about everything surrounding the output.
Users may accept that an AI result is imperfect. They are less likely to accept unclear charges, missing task states, or credits disappearing after a technical failure.
6. Making an AI Music Product Easier to Evaluate
An AI music website can describe features, genres, prompts, and workflows, but users eventually need to hear the output.
For a music product, real examples are more useful than another section of marketing copy.
I have started adding Songvora-generated audio examples together with the prompts used to create them.
One example is a personalized birthday song created from a story about a best friend named Maya.
The prompt included:
- Late-night road trips
- Her fearless laugh
- The way she makes every room brighter
- A chorus wishing her an unforgettable year
You can listen to the generated track and view the exact prompt in the personalized AI birthday song case study.
Songvora also has a dedicated AI Birthday Song Generator for users who want to create a song from names, memories, relationships, and a birthday message.
Publishing real examples serves several purposes:
- Users can evaluate the output before registering
- Prompts become easier to understand when paired with results
- Limitations become more visible
- Future prompt revisions can be documented honestly
- Product feedback becomes more specific
Instead of asking whether someone "likes the idea," I can ask:
- Did the song reflect the prompt?
- Did the personal details feel natural?
- Was the result worth sharing?
- What would you change in the next generation?
These questions produce more useful feedback than a general product survey.
Public content is also important for discovery.
An interactive generation form alone does not explain enough to users or search engines. Tool pages need clear server-rendered descriptions, examples, FAQs, and internal links.
Songvora therefore separates different search intents across pages such as:
The interactive tool helps users create. The supporting content helps them understand when and how to use it.
7. What I Learned and What Comes Next
Building Songvora has reinforced that the difficult part of an AI application is often not the first API request.
The surrounding product decisions require just as much attention:
- How users describe what they want
- How long-running tasks are represented
- What happens when generation fails
- How credits are handled fairly
- How completed results are stored and presented
- How users evaluate quality before paying
- How public pages explain the product
- How localized pages stay consistent
A few lessons stand out.
Meet users at their level of musical knowledge
Not every user knows how to write a detailed music prompt. Asking for memories, relationships, and emotions can sometimes produce better creative direction than asking for technical music terminology.
Treat failure handling as part of the product
A failed generation is not only a backend exception. It is a moment that determines whether the user trusts the application.
Show real results
AI products are difficult to evaluate through feature lists. A real prompt paired with a real output is more informative than a claim about quality.
Keep product facts consistent
Credits, limits, and storage rules may appear across many pages and languages. Shared configuration reduces contradictions and makes future changes safer.
Localization requires more than translation
A translated page is not automatically useful. Examples, prompts, FAQs, and search intent should make sense in the target language and region.
Songvora is still at an early stage. My current priorities are improving the first-time creation experience, publishing more real audio examples, strengthening localized content, and learning what users need before adding too many new features.
You can explore the current product here:
I would also be interested in hearing from other developers working on long-running or generative AI workflows:
What makes you trust an AI product enough to try it a second time after the first result is not what you expected?
Top comments (0)