Forty Seconds to a Finished Song
You type a title, a sentence describing the style — "slow Delta blues, resonator slide, gravel baritone vocal" — and if you have lyrics you paste them in with [Verse] and [Chorus] tags. If you do not, the model writes its own. About forty seconds later you have a complete track: vocals, instrumentation, arrangement, mixed and ready to download, with a 768-pixel album cover generated alongside it.
That is PressWax, and I want to be honest about something before I go any further: the part I just described was the easy part. Wiring a text-to-music model up to a web form is a weekend. Everything that turned it into something a stranger could pay for took the other three months, and almost none of it was about the model.
If you are considering a product with generative AI at the center of it — your own or one you are paying somebody to build — these are the three subsystems that never make it into the estimate, plus the cost I underestimated worst of all.
I have written before about why AI pilots stall before they reach production. This is the same story told from the other side — a pilot that did reach production, and the bill that came with it.
Subsystem One: The Credit Ledger
Most software bills per seat or per request. Generative media bills per unit of output, and the output length is variable, which breaks the usual approach immediately.
The underlying inference is priced by the second of audio. At list price that is a tenth of a cent per second, so a three-minute song runs about eighteen cents to generate and the cover art adds a fraction more. Cheap — until you notice that a user can request anything from thirty seconds to eight minutes, and can leave the duration blank entirely and let the model decide. You cannot charge a flat price per song without either losing money on long ones or gouging on short ones.
So the currency is a credit, and one credit is one second of music. That decision creates work you have to do carefully:
- Charge an estimate upfront, settle on completion. When a user leaves duration blank, the system debits a default estimate before generation starts, then trues it up against the actual length when the file lands. Without the upfront hold, a user with a nearly empty balance can queue five auto-length songs and go negative.
- Refund failures in full, automatically. Generation fails. Prompts get blocked by moderation. If a user pays credits for a song they never received and has to email you to get them back, you have built a support burden into your pricing model. Blocked and failed generations refund without anyone asking.
- Every balance change goes through one function and lands in one ledger. No sprinkling
user.credits -= naround the codebase. Signup grants, subscription grants, debits, settlements, and refunds all flow through a single service into a transaction table the user can see on their billing page. The first time somebody says "I was charged twice," the ledger is the only thing that will let you answer with confidence instead of apology. - Make subscription grants idempotent. This one bites everybody. Stripe retries webhooks, and it will happily deliver the same
invoice.paidevent more than once. If your handler grants monthly credits every time it sees that event, some customers get double. The grant is keyed on the invoice ID so a replay is a no-op.
None of that is hard. All of it is invisible in a demo, and all of it is load-bearing the moment real money moves.
Subsystem Two: Moderation That Rewrites Instead of Rejecting
The instant you let users type free-form prompts into a generative model, some of them will type the name of a famous artist. Not usually out of malice — "make it sound like Johnny Cash" is just how people describe music. But an imitation of a named living artist is a legal problem you do not want, and platforms have been sued over less.
The first layer is boring and effective: a regex blocklist of well-known artist names and "in the style of"-shaped phrases. Cheap, fast, catches the obvious cases.
The second layer is the interesting one. A small, fast language model screens what gets past the regex — catching misspellings, nicknames, and oblique references the blocklist never anticipated — and instead of rejecting the prompt, it rewrites it. "Sounds like Johnny Cash" becomes "deep baritone male vocal, sparse acoustic guitar, train-rhythm strumming, outlaw country." The user gets the song they actually wanted. Only explicit imitation intent gets blocked outright.
That distinction is a product decision disguised as a safety decision. A rejection is a dead end, a confused user, and often a support ticket. A rewrite is a song. The compliance outcome is the same and the customer experience is not remotely the same — and the rewritten prompt gets stored on the record, so if anyone ever asks what was actually sent to the model, there is an answer.
Subsystem Three: The Licensing Answer You Need in Writing
Before you can put "royalty-free, commercial use allowed" on a pricing page, somebody has to actually verify it up the whole chain. For this product that meant reading three things: the model license, the inference provider's terms, and the current position of the US Copyright Office.
The results, as of my review in July 2026: the model is MIT-licensed with no restrictions on its outputs, and the inference provider's terms disclaim any ownership of what comes out. So "royalty-free, commercial use allowed" is a defensible claim.
What you must not claim is copyright. The Copyright Office's 2025 guidance is that purely AI-generated work is not copyrightable — only human-authored contributions are, such as lyrics the user wrote themselves. And nobody anywhere in that chain warrants that a given output infringes nothing. A customer who assumes they own an exclusive, defensible asset has assumed something no one in the stack promised them, and the place to correct that is your terms of service, before they find out on their own.
The engineering lesson is smaller than it sounds: write the license research down, date it, and cite the sources. Two months later, when you are drafting marketing copy at eleven at night, you will not remember which of those three documents said what.
The Cost I Underestimated: Being Findable
Here is the part I got wrong, stated plainly, because it is the most useful thing in this post.
I built a product I am genuinely proud of and then discovered it was invisible to search engines by construction. Not ranking poorly — absent. An audit found no robots.txt, no sitemap, no meta description on a single page, no canonical tags anywhere, and both the apex domain and the www subdomain serving identical pages with no redirect between them, quietly splitting whatever authority existed. Searching for the product by name returned competitors and nothing else.
Every one of those is a half-day fix. Together they were the difference between a product that exists and a product anyone can find. I had treated crawl plumbing as a launch-day chore, somewhere below "polish the pricing page," and it turned out to be infrastructure — as much a part of the build as the database schema.
If you are scoping an AI product right now, put discoverability in the build, with a ticket and an owner, the same way you would put authentication in the build. The model is not your moat. Plenty of people can call the same API you are calling. The business is everything wrapped around it: the metering that lets you charge fairly, the guardrails that keep you out of court, the license research that lets you make an honest promise, and the plumbing that lets a stranger find you at all.
The demo takes a weekend. Budget for the other three months.
Before You Budget an AI Product
If you are planning something with a model at the center of it, the useful conversation is rarely about the model. It is about metering, guardrails, licensing, and whether anyone will ever find the thing — the four line items that decide whether you end up with a product or an expensive demo. The full write-up of this build is in my portfolio, and you can go make a song at presswax.com and judge the output yourself.
If you have a build like this in front of you and want a second opinion on the estimate, send me the scope. I would rather tell you what is missing from it now than have you discover it in month three. And if you are still deciding whether to build at all, start with the off-the-shelf versus custom framework instead of a feature list.