So I recently switched database providers after years on Railway and moved over to PlanetScale. Octarine doesn’t necessarily need a database, but it does store things like Changelog and newsletter subscriptions in Postgres.

I’d been having issues with Railway (I was on their free plan, so I don’t think they owe me anything), and with the new $5 tier that PlanetScale introduced, I figured, eh, it won’t hurt.

So I spent a day asking Codex to help me migrate everything over. I created new schemas, removed legacy Prisma tooling, and was all in all pretty happy seeing PlanetScale’s pretty charts and graphs on my screen.

Why am I paying $5 for just this data?

Okay, so clearly I wasn’t using much, yet I was still paying a very small but non-zero amount for a service that, while reliable, wasn’t really doing much for me—just as Railway wasn’t.

So the logical next step was to—~~move back to the free version~~—create new services so I could use more of the database.

Managing Feedback

For those of you who have reported issues or requested feedback for Octarine over the years, you’ll know there are two primary support channels: the GitHub tracker and the Discord server. Both have worked well enough for years and will continue to, but as support grew, I found it taxing to manage separate contexts, remember where something might have been reported before, and tell users about duplicates. It kind of became a chore.

The other major issue is that most of my users aren’t technical, so they have no reason to have a GitHub account, nor are they necessarily part of the Discord crowd. So they’d usually tweet at me or email me. There was just no easy way to send feedback from the very app they were using.

That’s when I figured I might as well make PlanetScale earn the $5/month and set out on an internal adventure (not as exciting as it sounds, it was more like lots of environment-variable setting).

I wanted to offload most of this to Codex, so I laid out some ground rules:

It should only be accessible to me, but via some sort of authentication.
It should have a decent API structure that allows for as much detail as possible, so there’s less back and forth with the user. This is purely an async communication flow, so if I need to email the user about what, where, or how, it kind of defeats the purpose.
It should email me once a day about any new feedback I might have received the night before, when I wake up.
It should allow me to take internal notes, set priorities, track status, and more as I start working on it, for my own peace of mind.
Most importantly, it NEEDS to look pretty.

Why limit to just new feedback?

While new feedback is a nice thing to receive, the GitHub tracker has tons of open issues (I know, I know, I’ll get to them all) that were imported into the tool, so I can see what needs to be prioritized and taken up. GitHub imports come with the existing replies, so none of the context is lost. Well, labels are lost, but who cares about them anyway?

Next Steps

Maybe the channels from the Discord server could be brought in? But I don’t necessarily think that’s a good idea because:

They’d bloat the hell out of the feedback tool, to the point that I’d stop looking at it.
Community members are really active on Discord, so any back and forth I need to better solve an issue is resolved immediately.
I really don’t want to mess around with that awful MCP/Discord bot-token thing. I did it in the past for a similar toy project, and I can’t imagine how the product manager for the Developer Settings page made those decisions.

All in all, it was a fun day-long project that will hopefully help me provide better customer support. More importantly, the design and decisions taken here will come in handy for the upcoming Tasks/Projects feature shipping soon in Octarine!

Also, who knows, maybe this becomes a public portal where users can vote, comment on existing issues, and help guide the roadmap. But that’s for another week; this one’s packed already.