Every side project I've shipped starts the same way: I have a frontend idea, and I immediately have to stop and go build a backend for it.
Not because the backend is hard. Because it's tedious. The same patterns, every time. Define a model. Wire up routes. Handle errors. Write docs nobody reads. Set up auth. Repeat.
At some point I stopped asking "how do I build this backend faster" and started asking "why am I building it at all?"
That question became Crudly.
What it actually does
You create a project, add a collection (think: a database table with a name and fields), and Crudly instantly gives you a live REST API at:
https://api.crudly.org/v1/{your-project}/{collection-name}
GET, POST, PUT, DELETE — all working, all authenticated, all documented. You didn't write a single line of backend code.
Here's what that looks like in practice. I created a project called sample, added a todos collection, and within about 30 seconds I had:
# List all todos
curl "https://api.crudly.org/v1/sample/todos" \
-H "Authorization: Bearer YOUR_API_KEY"
# Create a todo
curl -X POST "https://api.crudly.org/v1/sample/todos" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"title": "Repair Watch", "done": false}'
That's it. No Express. No Postgres migrations. No deploy step.
The architecture decision that makes this possible
Crudly doesn't generate code. There's no Express app being scaffolded and deployed per user. That approach sounds appealing until you think about what it costs — cold starts, isolated infra per project, deployment latency, and a maintenance nightmare.
Instead, the API server uses dynamic runtime routing. Every request to api.crudly.org/v1/{project}/{collection} hits the same handler. At request time, it reads your schema configuration, validates the request against it, and serves or persists data accordingly.
The schema is the source of truth. The routes don't exist as code — they're resolved at runtime from what you defined in the dashboard.
This is the same pattern that makes tools like Hasura and PostgREST compelling, except Crudly's surface area is intentionally smaller. You're not writing GraphQL. You're not pointing it at your own Postgres instance. You create a collection, you get endpoints. That's the whole contract.
What ships with it
The thing I kept running into with minimal API tools is that they solve one problem and leave you to figure out everything adjacent. Crudly ships the full surface:
Playground — A browser-based HTTP client (Postman style) built into the dashboard. Select your collection, pick a method, fire a request. I built this because switching to Postman or Insomnia mid-flow kills momentum. The response comes back formatted, with status codes and timing.
Auto-generated docs — Every collection gets docs that reflect the actual schema. They update when the schema changes. The curl examples use your real endpoint URLs. No Swagger YAML to maintain.
Request logs — Real-time traffic visible from the dashboard, filterable by method, status, endpoint, and date. Useful enough that I've caught integration bugs in client apps just from watching the log stream.
Webhooks — POST callbacks on create, update, or delete events per collection. If you're integrating with n8n, Zapier, or your own service — this is how you wire it up without polling.
API key auth — Read-only and read-write keys per project. Generate and revoke from the dashboard. Keys go in the Authorization: Bearer header.
Admin Panel — A generated data dashboard. Browse records, create entries, edit, delete. Useful during development and for non-technical stakeholders who need to manage content.
What I didn't build (deliberately)
No custom logic. No middleware hooks. No computed fields. No joins across collections.
If you need those things, you need a real backend and you should build one. Crudly is not trying to be Firebase or Supabase. It targets a specific use case: you have a frontend, you need persistent data with a REST interface, and you want it running in under five minutes.
The constraint is the feature. Every time I was tempted to add "just a bit of custom logic support," I asked whether it would break that five-minute promise. Usually it would.
Where it actually fits
The use cases where Crudly earns its keep:
- Prototyping and MVPs — Wire up a real API before you've decided whether the product is worth building a proper backend for.
- Frontend demos and portfolios — Stop mocking data in JSON files. Ship something that actually persists.
- Internal tools — A quick admin data store for a side dashboard, without standing up another service.
- Hackathons — The entire backend setup takes less time than arguing about which framework to use.
Try it
Crudly is live at crudly.org. Free plan available. Create a project, add a collection, hit the endpoint — it takes about two minutes to get to a working API call.
If you run into anything broken or have a use case it doesn't handle, I'm interested. Still actively building this.
Top comments (1)
schema-to-REST is the right primitive but the FRONTEND is usually where ppl get stuck after schema-gen. been building moonshift one layer up - 1 prompt -> wired saas including frontend + auth + stripe + deploy into ur own gh + vercel. could plug crudly as the backend layer behind a moonshift frontend. $3 per ship. happy to test the integration if u r open to it.