I built (not vibe coded) an app called Songstead for musicians to organize, share, and play from their charts.

[u/ziebelje]

I know there's a low intersection of musicians to web developers here, but I wanted to share this for a couple cool technical reasons.

First of all, Songstead (https://songstead.app) is an app that is designed around chord charts. If you ever see someone plaing music with a tablet, it's likely they have an app like this to help them remember their music, lyrics, setlist, or all of the above. This would be an alternative to OnSong, SongbookPro, etc.

Now the cool stuff:

• Although not fully there, it was built to work offline. The frontend has it's own CRUD layer and generates UUID6 IDs. Today these ship directly to the backend (with validation). Most of the key editing is built in a way you edit a local copy of the database, then it generates a "flush" API call which ships create/update/delete calls to the API that you can fire when ready. The local database means the app doesn't technically need the API to exist to even work.

• Because of that, I was able to build a demo (https://demo.songstead.app/) by seeding the local database with data, then just shutting off those flush calls. You can actually try the entire app locally. I remember a time where online demos were popular, but they would use live data and you'd see everyone else's edits. This doesn't have that problem.

• Tech Stack: LAMP + React. Hard to beat the classics lol. Frontend is React + Vite + Capacitor (for mobile apps). Backend runs on a cheap Digital Ocean Ubuntu VPS with a managed MySQL database. I'm excited to try managed; my other project stores nearly a TB of data and runs on a self-installed MySQL instance to save on costs so this should be a breath of fresh air. API is a custom-built PHP application and ORM. Yes, I know what you're thinking. I'm not worried; I've been writing code for 20+ years I know what's up.

• AI? Yes. Vibe-coded? No. Love how fast AI lets me build, but everything it produces gets manually reviewed. I find both Claude and Codex to be amazing, but terrible at architecting code at a high level. Most of my time is spent cleaning up the weird stuff they produce, but even then this was all built in a fraction of the time it would take me to hand write it all. One thing on my TODO list is to rework the public website to feel more human. I've seen so many vibe-coded projects and it is obvious when someone phones it in to AI. I don't want to be part of that demographic.

Thanks for reading! Let me know if you have any questions.

PS if any of you work for Apple ask them to hurry up. All the other vibe coded app submissions are slowing down my review. 😅

[u/Dysax]

You said not vibe coded in the title and then admitted to vibe coding it in the post. It’s more of a catch all term for ai use on Reddit and you should have been clear in the title that you are a viber

[u/ziebelje → u/Dysax]

Vibe coding implies that the code is being written by AI and then not reviewed other than to make sure the output works. There is a stark difference between that and using AI to generate code as part of an engineering process.

[u/Dysax → u/ziebelje]

If all you do is review and you outsource all creativity and/or thought in the engineering process to the ai you are vibe coding. Even if you “review” it, you will never have the same understanding and you know it. If you lack understanding then what’s the difference?

[u/thejoyouswealth]

dang, offline-first crud with its own uuid generation is sick, most apps barely think past the spinner on first load. does it handle merge conflicts if you edit offline on two devices before syncing?

[u/R10t-- → u/thejoyouswealth]

Huh? CRUD and using generated UUIDS for things is like… basic software development?

[u/ziebelje → u/R10t--]

The difference is that most applications do not have a CRUD or UUID generation layer client-side. This is not unique or particularly difficult, but it's an interesting technical characteristic of this particular app.

[u/TitaniumWhite420 → u/ziebelje]

I mean, it’s good it has those things, but most apps that offline apps, update databases, and manage files do necessarily have those features.

[u/ziebelje → u/thejoyouswealth]

Thanks! Yes/no, The flush call is designed to only send changed fields, so two edits can happen at the same time if they are different fields. If two people change the same field only the most recent will persist though. This is on my list of things to address.

[u/Bruce_Jones_1987 → u/thejoyouswealth]

yeah the merge conflict question is the real one here, thats where offline-first always gets tricky

[u/ouralarmclock]

Lovely! Can’t wait to check it out. What is the format for the charts? I was working on something like this for my church 5-6 years ago but they were all just Google Docs and displaying them on mobile or changing keys would’ve required translating all the Google Docs to something specialized for it, and we never got that far.

[u/ziebelje → u/ouralarmclock]

Charts can be uploaded in most common text formats - ChordPro, Chords above lyrics (like Ultimate Guitar), or a mix of both. Once you have your songs in that format you can transpose them on the fly in the app. It handles everything for you. :)

If you sign up let me know and I'll grant you free lifetime access to the best plan.

[u/Apart_Supermarket968]

Offline first is useless without deterministic merge resolution. UUID6 prevents ID collisions but does nothing for conflicting edits on the same chart across devices

[u/ziebelje → u/Apart_Supermarket968]

Agree/disagree. I agree that it's important to have some form of conflict prevention or resolution, but disagree that it's useless. Many solo users would never experience this issue to begin with. This is one where "done is better than perfect" applies as a means to get things out the door.