Show HN: StaticBackend – A web and mobile back end without lock-in | Hacker News Reader

Show HN: StaticBackend – A web and mobile back end without lock-in

staticbackend.com

35 pointsdstpierre30 comments

A few takes:

- 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.

thanks for the feedback:

- 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.

>grammar: thanks, I'm not a native English that's correct, I'll try harder.

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.

yes, absolutely

'It always irks me when passion projects or pre-MVP "startups" are hemorrhaging money (even if it's just 10 bucks a month)'

Disclaimer: I'm founder of DarkLang, a sorta competitor.

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.

thanks, this give me some confidence.

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.

> 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.

Hi there,

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.

It seems like a decent concept. I think the main problem is that you have two competitors (nhost and superbase) that are doing the same thing but better. In particular:

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.

Yes, I discover nhost a couple of months ago when the founder replied on a post I made in IndieHackers. I was not aware of both before.

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.

I would suggest that quality is much more important than quantity/breadth here. I would use such a service to save me time, but it will only save me time if it's rock solid and very actively maintained. Otherwise I'd much rather just build my own.

yes totally. that's why I'm focusing on simple implementation and not planning on adding anything yet. I planning on building real-world SaaS examples to showcase the capabilities.

Conversely, renewed competition may also be a good sign that there's a market for such products. You do need a place to differentiate, fortunately the surface area of the problem is fairly broad.

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.

yes, this is the vision I have for short-mid terms. But I won't be adding anything soon. The long-term differentiation will be clearer once there's early adopters I think.

Looks cool to me. I like the more flexible tiers, not sure why others are suggesting slimming them down.

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!?

Probably too many pricing options.

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.

thanks for the feedback:

- 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.

One of things I often worry about while working on my SaaS is missing out DB writes, I'm way more at peace with saving something to S3 just so that I don't lose any data.

thanks for the feedback.

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.

Would you call this a headless CMS? Headless infrastructure?

If you had to put a genre/category on it, what would it be?

I still have difficulty knowing what it is.

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.

Is it really far away from strapi.io ?

I did not knew strapi.io, but I don't think it's close no.

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.

Looks really cool, nice job!

thank you

How is there no lock-in?

1. You can export your entire database (it's a stanrad Mongo database). 2. You could use the library and write your own backend API using the same routes and your application would not need any changes if you decide to stop using StaticBackend. 3. You have the option of purchasing the source code. From there you may do whatever you want and change direction and what not.

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.

They changed my title, it was: StaticBackend a web & mobile backend w/o lock-in

Sorry, the software really did a number on that one. I've fixed it now. In the future, you can always correct such mistakes by clicking 'edit' after you post.

Reply on news.ycombinator.com