One session, start to finish. Musical notation in; a playable audio file and typeset sheet music out. Six pieces and four scores came out of it, all on the same day.
It works the way everything else here works — the source is text, and the output is a build step. Write the notes, run one command, get an MP3 and a PDF. Change a bar, run it again.
Why it is worth mentioning
Not because we are in the music business. Because of what it took: an afternoon, and no new skill. The knowledge of how to typeset music and synthesise it from a score already exists in mature open tools. What was missing was somebody wiring them together and deciding what correct output looked like.
That is most specialist software. The hard part was solved by somebody else years ago and published. What is missing in your business is not capability — it is the twenty lines that connect the capability to your actual input and your actual output.
And then we stopped
We are including that deliberately, because the pattern it represents is expensive. A capability gets built because it is interesting, it proves out, and then it waits for a use that never arrives. Multiply that by a year of enthusiasm and you have a tool shed nobody opens.
The audit that surfaced this also showed which tools survived: the ones attached to work that happens every week. Proposals get made constantly, so the document pipeline is hardened and reliable. Music got made once.
The test worth applying
Before building the thing, ask what happens the week after it works. If the answer is that somebody will use it on Tuesday because they have to, build it. If the answer is that it will be available should the need arise, you are building a demonstration.
Demonstrations are not worthless — this one proved the pattern generalises beyond documents, which is why it is on this page. But they should be recognised as what they are, and given an afternoon rather than a quarter.