Table of Contents
I want to help with the running costs βοΈ
Kytario is free for you and your friends π. No ads, no paywall, no premium account. And that is not going to change. π Kytario does have certain costs that we pay to third parties, though - renting and running the servers, the domains, and newly also the bill for running the AI song transformation - and we cover those out of our own pocket.
We try to optimise the costs as much as we can without making the platform any less reliable. We are well aware that Kytario is just as critical a tool for you and your project as it is for us β€οΈ. Some fees are simply unavoidable, though.
You can contribute one-off or repeatedly. If you would like to be listed among the supporters in the page footer, send us your name (or the name of your band/project) by e-mail, and a link to your social media if you like πͺ.
From Czechia - with a payment QR code to the account2580670033/0800
From the EU - by SEPA transferIBAN CZ68 0800 0000 0025 8067 0033BIC/SWIFT GIBACZPX
From Sweden - with a Swish QR code to the number076 773 07 49
Kytario is a non-commercial community project run by a private individual. Contributions are used solely to cover the running costs. Being thanked among the supporters is a gesture that a contribution gives no entitlement to, see article 2.3 of the terms and conditions.
I want to help with development π»
If you have an idea for a new feature, a fix to the texts, an extension of existing functionality or an improvement to the design of the whole site, the most useful thing you can send is a detailed description of that idea, or a prompt. π€©
You do not need to be a programmer for that. If you use Kytario in a band, when teaching music or at a campfire singalong, you know which things work well and which do not. And that is exactly the rare part we need to know β€οΈ.
Why a description is better than finished code π‘
Writing code is easy these days. Coming up with a working product that thinks about edge cases, a broad user base, accessibility, the law and maintenance is not that easy any more. π°
We built Kytario from the ground up, and thanks to that we have context that is not readily apparent from the code. We verified a lot of changes in real-life situations, gathered feedback and asked people for their opinion. That is hard to do when we receive changes "as code" and have to work out the intent behind them ourselves.
A clear description of the change, or a prompt directly, skips all of that. We read it in 5 minutes, ask about the things that are not clear, and then we can implement the change so that it fits properly into the rest of the platform. π
How to write a great description of a change βοΈ
Think of it as instructions for someone who will do the job while you are away. Try to cover:
- π― What is the problem? Not the solution.
- π Who does it affect? Just you, your band, everyone around the campfire?
- β¨ What should happen instead? Describe it the way you would tell a friend.
- π€ What about the odd cases? An empty list, a song with no chords, a slow internet connection.
- π± Where does it matter? On a phone while playing, on a laptop while preparing, on a printed PDF?
- πΈ Show us. Screenshots, a photo of a scribble on paper, a link to another app that does it well - it all helps.
Do not worry about whether you write it perfectly or whether you use the right technical words. π
An example π
β Too vague: "Add a transpose button to the screen."
β Useful:
When we play outdoors, the singer often decides to change the key in the middle of the song. Right now I have to open the song menu, find the transposition and tap "+1" four times - which takes about ten seconds.
I would absolutely love "+" and "β" buttons right on the song screen while playing, big enough to hit without looking, and the current key between them so I know where I am.
It matters most on a phone. I do not play gigs with a laptop, and on a projector it makes no sense.
You can then paste this extended description into ChatGPT, Claude, Gemini or any other AI assistant and ask it which exceptions (edge cases) would be worth covering and how the whole thing fits into the rest of the project. Although AI tools do not have access to the source code, they can work a lot of things out correctly from the documentation or from the specific publicly accessible page the change concerns (e.g. the song list).
You can then send us the resulting description of the feature by e-mail to info@zounar.me and we will get back to you β€οΈ. And if you would like to lend a hand even more, take a look at our stack and let us know π.
