Show HN: StaticBackend – A web and mobile back end without lock-in(staticbackend.com) |
Show HN: StaticBackend – A web and mobile back end without lock-in(staticbackend.com) |
- Website is riddled with grammatical inconsistencies and errors. I can tell you're not a native English speaker, and you may want to revisit some of the copy.
- As @ourcat mentioned, there are way too many pricing options, not to mention the tiny tabs at the top (which yield even more pricing options). It's just confusing/overwhelming.
- You really need to make a case here for why someone would choose you over Firebase. I'd personally never use you because Firebase is free while I'm building out the MVP (usually a side project). It always irks me when passion projects or pre-MVP "startups" are hemorrhaging money (even if it's just 10 bucks a month).
- I don't think "vendor lock-in" is a pain point for these kinds of products. A pain point I do know about is migrating to a more robust data layer if the project takes off (post-MVP phase). I don't really see how this very real pain point is easier to mitigate on your SaaS rather than Firebase.
While I personally agree that self-hosting is a nightmare, the biggest complaint we've heard about Dark has been related to vendor lock-in. I think this is a pretty good selling point for StaticBackend, for a few reasons: 1) what if you get too big for the hosting? 2) what if the company goes go out of business! 3) what if the company determines that hosting you is against the T&C (see the Parler thing this week, for example, although I completely agree with AWS' decision there).
I don't think self-hosting is really a good idea if you can avoid it, but a lot of people are soothed by the idea that they could, if they really needed to.
Ability to self host often also means ability to switch hosted providers. And things like being able to run local copies or instances in CI too.
I think differently regarding self-hosting though. By the fact that StaticBackend is a Go web server, it's a standalone Linux binary and can be hosted very easily on x64 Linux server.
But I'll see when the first customer will choose that option. I'll be ready to help them deploy for sure.
- grammar: thanks, I'm not a native English that's correct, I'll try harder.
- pricing: My thought is that offering only 3 tier would be way too big of a leap from tier to tier.
- Firebase: I do have a fully disconected and local development server that helps during building phase. It's free, but I can see your point.
- vendo lock-in: My main objective is exactly that, to have an easy way to self-host and even get the source code once a product reach scale. Something that not much BaaS offer.
Why not just hire an editor or copy writer. Nothing wrong with focusing on your core goals and outsourcing some of the tasks you don't need to focus on right now.
I'd like to request feedback on my product. I started building in last January with great momentum, but the pandemic made things a bit complicated.
As someone that built a dozen of SaaS in the last decades, there were some aspects of the backend I was bored of rewriting. User management is probably the major one.
I've tried Firebase and admit I found it interesting for 4-5 days, but as a Go backend developer, it did not suit my need/taste.
Why not try something just for me. At first, I called it "ezbackend" and built a dirty prototype in Node. I played with rewriting it in Go and started to like where it was headed. In January 2020, I thought that it might interest others, so I renamed the project, made it more rebust, and kept adding the minimal feature sets I personally wanted.
I'm now near the v1 / official launch, and I'd like to get some thoughts. I know it's not for everyone. To be perfectly honest, I'm not 100% clear who might be interested, but I'm excited enough to build side projects on top of it, it's enough for me to build it.
Any feedback is greatly appreciated.
And they could do with more explanation about what the options contain.
And the last 'tab' of the pricing options reveals the $10k and upwards cost of 'unlocking'. Maybe be a bit more upfront about that.
- pricing: yes, seems like a recurring comments, but I want to make the leap between tier friendly, like Digital Ocean droplet for instance.
- the option to buy the source code is what makes this appealing compared to Firebase, where if you reach scale you have the option of paying 10k which is not huge if you're making 85k in MRR to get peace of mind and have full control.
I can understand that and can see some kind of daily external backups of your data at some point. My whole goal is to make customers feel 0 pressure and especially about their data.
If you had to put a genre/category on it, what would it be?
I'd called this: a SaaS backend API and infrastructure.
It would be a great companion to a Netlify application. Since they have hosting and function as a service. I think it would be the best fit for the current state.
My product is a database and websocket backend you can use from client-side, being web or mobile. It's a pieces of scalable infrastructure needed to build a SaaS or web application.
I realize that it's not very clear at this moment what it does, even to me to be frank. It's the infrastructure I need to build SaaS that compliment a Netlify app.
I admit that the 2. needs efforts on your part to switch. But it's possible to stop using the tool and still have no rewrite on your frontend code at all.
I assume "unlocking" the backend and getting the source code gets you something in Go then, but I didn't see more information about exactly what you get with that option. What frameworks, technologies, etc. Is the API described in Swagger/OpenAPI? What DB? If I use staticbackend, but then I want to write my own backend, can I export my user DB without paying the $10,000? Does the $10,000 even include the User DB!?
1. Their stacks are mostly open source, so you can truly self host with no cost at all if and when you need to.
2. They're building on top of Postgres so you get the full power of a SQL database. Plus they both have realtime solutions ready to go.
My goal with StaticBackend is to go more in dept in features like sending emails, Stripe payments. Features that a SaaS / web app typically need in the backend.
I'll not stop at Database and WebSocket. I'd like to go further based on demand. I'm building more a backend teamate for frontend developers.
I recognize that my choice of using a Document database instead of an RDBMS can be argued. But one as to make choices.
Thanks for your comment.
As an example, look at low-code for inspiration to determine what features people need which aren't being filled by existing solutions. Hopefully that reduces the need to compete via feature checklist.