> I think that would cause too much friction for something that should be a 5-seconds-or-less kind of experience.
I don't think I'd agree with that, but that's just my intuition thinking a link is less annoying than a popup. I have no data to back that up either way.
But put it this way: A popup or embed annoys every single visitor, as soon as they show up. Very few of them will want to send you anything at all, but they all get annoyed. I know that every time I see a popup, my first instinct is to close it without even reading it. (I only suggested this because it's a very common pattern, often insisted on by product owners... but as a frontend dev, I hate floating things like that).
On the other hand, a link is a word or two I can quickly scan and ignore if I don't want to use it. If I do, I know exactly what happens if I click it... it opens.
Maybe a compromise is just to have a "Contact" link in the header (instead of the very bottom) that goes to a contact page with an embedded form. (Or a drop-down form if you really must).
> I don't really want a complex setup, with user heatmaps and such; these are projects that have very limited features and likely to shut down in a few months.
> [...]
> Mind if I ask why? I think DIY is better than those because of the smaller friction in collecting feedback.
To me that's all the more reason to just find some drop-in feedback widget. It takes like one line of code and 5 min to set up and it's going to be like 95%+ reliable. Someone else did all the design work, testing, CDN stuff, etc. If it's not core business logic for your startup, why waste time on it at this early state? It's literally just a text box for someone to send you a message. It could be a mailto link if that's easier.
The trouble with rolling your own is just that it's a hassle. You gotta do the frontend for your visitors and make sure the popup is responsive and has the right z-index vs everything else on the page, etc. You have to design a backend and make sure it's authed and protected from drive-by bots and such. You have to either be willing to parse entries in a DB/KV browser or else design a viewer frontend for yourself. That's like hours/days of work, in my mind, vs a drop-in one-line script (or a link), under a vendor's free or cheapest plan.
And if you want to accept files (like screenshots or recordings), it becomes quite a bit harder.
But if you really want to DIY it...
> How would you set up the schema to store the data, while allowing for migrations that will probably happen quite often? One setup I've hosted involves a Go/Gin server with embedded SQLite on Hetzner using Caprover, which I felt worked quite nice. It's costing me about $5/month, which I need to spend for another server I need to host.
I think this use case is simple enough you could do it however you want. If your app has a DB already, it can just write to another table there (with proper sanitization and and bot blocking, etc.). It does run the risk of bad actors damaging your prod DB, though.
If I were doing it, it'd be like a few lines of code in a serverless func writing to a serverless KV, like a Cloudflare Worker writing to a Workers KV: https://developers.cloudflare.com/kv/ It should be free up to 1000 writes/day, 1 GB of stored data.
The schema can just be something simple, like:
{
feedback_api_version: 0.01,
email: "nicefellow@gmail.com",
comment: "Hi, blah blah blah, I love your product but...."
}
If you version it every time you change the schema, it should be simple to write an importer/normalizer in the future.
If you want to put it in a DB instead of a KV, go ahead. Doesn't seem like the kind of thing that really needs its own server, but if you prefer that architecture and don't mind paying for it, why not? You can probably put it on a free plan somewhere ( Vercel, Firebase, wherever: https://gist.github.com/bmaupin/0ce79806467804fdbbf876197051...).
But it just seems like overkill to me. You're just reinventing Google Forms and Airtables, who already has all that done and tested and deployed and battle-tested thousands if not millions of times a day.