💡 Idea Validation: A lightweight CRUD BaaS
context on this for those unaware, CRUD stands for Create Read Update Destroy in the database world, just in case you thought the name was super weird 😂
Hi, I'm a backend developer by day and Indie Hacking Crudly by night.
Crudly is a super simple public API that you can integrate with your apps to do basic data storage. Rather than have to worry about managing/choosing your own DB, you simply create table's through the Crudly UI and make HTTP requests to the public endpoints to store/retrieve your user data.
It's:
- Super fast an easy to spin up
- Can be accessed anywhere on public internet
- Should be cheaper than hosting your own DB (since behind the scenes you're sharing a DB with other users)
- Can be integrated easily with anything that can send an HTTP request, no client libraries required
Thinking about pricing just as a monthly subscription with limited API counts.
A few queries I want validated on this:
- Some services like Vercel offer such super easy DB integrations nowaday, is anyone really going to want this?
- Are developers going to feel confident storing their data over public internet like this?
- Is this too big/risky for a first startup? This isn't the kind of project I can just kill if it doesn't do so well since it would also ruin all the apps people had built using it.
Thanks for your time!
Trending on Indie Hackers
Cloud databases are sooo cheap, maybe free if youre already paying for a pool anyway. Free credits exist for every cloud.
Also you are taking away my option to use ORMs and... write queries.
This isnt saving cost or complexity. Imagine every query you write is suddenly an http request and every additional join is an additional http request.... that sounds terrifying.
Backend sql people would never think of using this. Frontend people who dont like sql are gonna use mongo or whatever and just throw their json in there.
This is for no one.
If you actually want to see whether this is a good idea: Build something else with at least 10 tables in the backend and then use the API of this idea. You can build just the http api in under half a day.
I think you're gonna realize pretty quickly how terrible it will feel.
Losing access to a ORM/query languages is a big one for sure.
I guess the "simplicity" I'm thinking the system brings is in its lack of a requirement for any custom library. But perhaps the demographic for this just doesn't exist. As you say, BE devs will find it easy enough to setup their own DB with modern cloud hosting and FE devs have many easy solutions like firebase/supabase they can already use and pack a few more features they like.
I already had the idea actually to try and build something myself before launching. We'll see if it works out. Unfortunately the system won't really be profitable to run for a single project.
Thanks for your feedback!
To be honest: I do not think that this is really solving a problem. It is to simple for real apps (they would use firebase or supabase or something like that). It also isn't an integration vehicle. Something like Microsoft Dataverse can provide a data storage backend too, but also gives the ability to integrate with other Microsoft Business products.
I do not see which kind of apps are that easy that supabase would be too big, and then even are willing to pay for usage of your crud backend
Well for Supabase you're paying $25/month minimum for all kinds of extra things:
Supabase certainly aims to serve a wide range of different tooling to setup a backend whereas Crudly would just be focussed on the data storage. I agree, it's certainly hard to think of apps that would be "too small" for Supabase but I'm hoping if the pricing can beat Supbase significantly enough it might encourage people with less complex business logic needs to try it.
Perhaps integrations are an interesting road to explore to see if there's any niches to fill there. The idea was to KISS though so have to be careful of violating that.
Thanks for your feedback!
When building something more than a hobby project (something that would make money, so people would be willing to pay for your service), the complexity of the app is higher than a simple CRUD. Things that you also need on top is permissions, data validation, more complex queries (maybe with joins).
I am working right now with firestore, which is kind of something you want to do: a serverless database you can just use either from the frontend (and have permission access and data validation through the firestore rules) or from the backend where you can implement custom permission and validation logic.
But just for CRUD, unsecured, with no complex queries and without validation, I don't think it has a market. Databases are the most crucial single point of failure for a software startup, so it has to be robust, and be able to scale.
I think the target market is definitely smaller hobby projects as you say. But maybe no one really wants to pay for infra for a hobby project even if the price is super low.
In my experience as a backend dev in my day job a lot of what we do is CRUD. There are certainly many logic layers in micro-services on top of it, but at its base it becomes CRUD. This idea was actually born out of a situation at work where we needed to migrate away from legacy storage infra and ended up spending huge amounts of time deliberating how we were going to create a simple key-value-store to support a new feature. It felt like for such simple data storage there needed to be an easier solution than spinning up Cassandra/Postgres etc.
I think this is a good point to touch on. The lower the complexity of a system, the far easier it is to maintain and scale. This is another idea behind the app. If all we need to manage is simple CRUD operations, then it should be easier for us to scale out.
Thanks for your helpful feedback and sharing your experience with Firestore!
How is this gonna be different from a headless cms?
It depends what your definition of headless CMS is. I would associate a CMS with serving of media content for a frontend. My service is more about the storage and querying of structured data (e.g. JSON objects) into your backend server.
You also wouldn't really write data back to a CMS from your application, which is what you can do with Crudly. Crudly is more of data layer solution than a CMS.
Got it, so you are gonna help me create data models and do crud operations on them correct? isn't that what an ORM helps me with?
Sure, that's one advantage. But an ORM is just a programming library, this will be an actual piece of infrastructure meaning you also don't need to worry about choosing a DB/hosting service.
I think it's a good idea! I've found integrating databases with serverless environments like Vercel to be a bit of a pain. Sometimes I just want to make an API call without having to run that backend separately
Thanks for the response @behn! I just hope that my service can remain simple enough to attract people away from other hosting solutions that are already really simple these days.
I agree with @Venisol, relying on having to send http requests for each query will not be a viable alternative for large applications. Maybe this could be used for small scale projects or for educational purposes but i dont think any expierenced developers would consider this over just using a well known database solution.
Hi @DazKins, I use DynamoDB for all the reasons you mentioned. But is there a niche cohort of users that may want an alternative for other specific reasons? Perhaps there's an appetite for your product in such a community.
Hi @ElijahGeorge,
I guess if you've got a DB technology that you know how to setup/host very easily and your comfortable with then people will always stick to stuff like that.
The thinking behind my service is that you don't have to worry about which DB to choose or where to host it. You simply make API calls from anywhere and you can store/fetch your data.
For bigger projects you definitely want to think about your DB choice and your hosting solution, but if you're writing a small indie project maybe just for a few friends or family, Crudly can provide this without having to worry about these decisions.
I think my main competitor will be the simplicity of existing offerings like simply hosting MongoDB on Vercel which I've tried myself and is super easy. People might just feel more comfortable with well established methods like that.
Thanks for your feedback!
Got it.
It's too big and you will see many questions coming in from customers on the data storage, latency and a lot of other questions with downtime, RTOs, RPOs..Don't get in there especially if you are just getting started. There are many smaller SaaS ideas that you can start with.
Thanks for the feedback!
Yes, that's definitely a concern. There's also a lot of legal concerns that come with hosting a platform for other people's applications that might not be worth my time getting stuck into as a first time startup.
I was hoping my product could attract the niche of smaller indie developers in order to avoid the risks of hosting for larger products that might go with Supabase/Firebase. I think with super low costs (due to the simplicity of the service) some people might be happy just to pay a few dollars to host some basic data for a side project.
As a developer would I feel confident storing data over the public internet?
Depends what you mean. I use Firebase and you can restrict which users can read what data and write what data but other than that it is on a public endpoint. I think it is fine.
As long as it is secure. If anyone can edit the data or even read it that is obviously not good.
As for whether I would use it, well I would be hesitant because I would be coding to your api and if you shutdown I need to rewrite. If I were to use something like this that isn’t Firebase I would use Parse (open source) supplied as a BaaS I think there are some companies doing that. If they stop I can still move to another host.
I think the problem you will have is you are competing in a space against the big clouds and a bunch of VC funded startups who can offer free or cheap plans that will make it hard for you charge much or anything.
I think there needs to be a different value prop to just making it easy. There are plenty of options on the easy to sophisticated spectrum.
Yeah, I'd echo a lot of things that are said here.
I use Supabase and they also provide a GUI to create and edit tables + a public API you could use to do CRUD. One important question is why people would use your app instead of options like Supabase.
Another set of questions involves missing features. A lot of times I think people want a solution for things like auth and file storage (both of which Supabase provides). I also think it's important to provide the developer with the option to actually write SQL, because sometimes the situation calls for it.
Thanks for your in depth replies both!
I think you make a super good point about the "lock in" factor. People wouldn't feel confident trusting a random indie startup with their core application data layer. I think there's a couple of idea that could remedy this:
My idea with this service (maybe not so well communicated in the original post) is that it wouldn't be done with user level auth. It's a single admin API key to access all the tables associated with your project so in that sense it's only really usable from your backend, not the frontend.
I've been back and forth a lot on the whole user auth thing, I'm kind of a simplicity addict so didn't want to get stuck into anything like that unless I was sure there was a requirement for it.
The niche that my product fits into is more for small indie developers rather than large corporations. You would be able to do some cool things like easily run your stuff locally but hooked up to production data for testing purposes.
My thinking was that by stripping out all of the extra features that platforms like Firebase/Supabase provide, I could drive down the price super low and attract enough small projects to make a profit on hosting costs. The service is essentially a managed multi-tenant DB. But maybe you're right, maybe there needs to be an additional value prop here...
Thanks for the great feedback!
Yeah. Hmm. I'm not sure how I feel about this. On the one hand, it does seem possible to side-step. But on the other hand, I dunno, as a developer I kinda just want to make sure that stuff at the data level is reliable. I'm ok taking a risk on an unproven library for a UI widget or something, but probably not here. That's just me though, and I'm not sure.
Gotcha, that makes sense. Supabase gives you that option as well and it's what I do. They actually push you against it and towards something called Row Level Security, but I prefer just using the API key.
That sounds fair. I'm sure there is some audience out there that doesn't need the user auth, and I agree that it is often wise to KISS and say no to features. Thinking about it more, there is something very attractive about that to me. Feature bloat is often times annoying.
Exactly, feature bloat not only makes it hard for users to understand/use your product, it adds more cognitive load for developing/maintaining the system. This simplicity should allow prices to stay low and make the product easy to use.