Backend development
The part of the product nobody sees, and everybody notices when it breaks.
Acasa Labs provides backend development services: the database, background jobs, queues, permissions, and integrations behind your web and mobile apps. We build in Python with FastAPI or Django, or in Node, on Postgres and Redis. Pullsy, Kraftr, SigmaCPM, and GymFast all run on backends we built and still operate.
The problem
Most product bugs are backend bugs wearing a frontend costume.
A sync that ran twice. A job that died at 2 a.m. and nobody noticed. A customer who saw another customer's invoice. A third-party API that started returning errors and took the app down with it. None of these show up in a demo, and all of them show up in the first month of real use. A backend designed for retries, crashes, and other people's outages is cheaper to build once than to patch forever.
What we build
- 01
Data models that hold up
Postgres schemas, migrations, and constraints that make bad states impossible instead of merely unlikely, with tenant isolation from the first table.
- 02
Background jobs and queues
Sync, imports, generation, and reminders on queues with retries, locks, and heartbeats, so a crashed worker is noticed and its job picked up again.
- 03
Permissions in the right layer
Roles and access rules enforced in the database or in one backend layer, so a new screen cannot quietly skip them.
- 04
Integrations that fail gracefully
Payment gateways, social platforms, brokers, and LLM providers behind adapters that handle rate limits, backoff, and re-authorization.
From production
From backends we run.
A queue that never syncs twice
PullsyPullsy's Redis queue uses atomic move-with-ack, a delayed-retry set, and per-connection locks, so one account never syncs twice. A scheduler recovers crashed jobs from missed heartbeats.
No extra broker to run
SigmaCPMSigmaCPM's job queue lives in Postgres, with leases, orphan reclaim, and skip-locked selection. That is one less system to deploy, watch, and pay for.
Seven queues, and a view of all of them
KraftrKraftr runs generation, model builds, scene builds, jewelry libraries, video, and batch polling on seven BullMQ queues. Workers write heartbeats every 10 seconds into a liveness view in the admin.
Automation without a server
GymFastGymFast's renewal, payment, and class reminders, plan expiry, and auto check-out run as scheduled Supabase Edge Functions, with roles enforced by Postgres row-level security.
Honest trade-offs
When a managed backend is enough
For many products, Supabase or Firebase gives you auth, a database, storage, and scheduled functions without running servers, and that is what GymFast uses. We write a custom Python or Node backend when the product needs long-running jobs, heavy AI or data work, strict control over where data lives, or integrations a managed platform cannot host. Often the answer is both: a managed database with one service beside it for the hard parts.
What we reach for
- FastAPI, Django REST Framework, Node
- Postgres, SQLAlchemy, Drizzle
- Redis, BullMQ, Postgres job queues
- Supabase Edge Functions, row-level security
- Cloud Run, Railway, Cloudflare Workers
- pytest, contract tests
- Sentry, Prometheus, Grafana
Proof
Shipped, not pitched.
01Our product
Pullsy
Instagram analytics that keep the numbers Instagram throws away.
Analytics for creators. Pullsy keeps insights Instagram discards after about 90 days, explains what each number means, grades the account, and turns it into a media kit a brand can verify.
Web · iOS (native SwiftUI) · REST API
02Our product
Kraftr
One flat-lay photo becomes catalog-ready 4K on-model imagery.
An AI catalog studio for fashion and jewelry brands. Upload one flat-lay or hanger shot per SKU and get on-model imagery at up to 4K, in ten aspect ratios, sized for Amazon, Myntra, Flipkart, and Shopify.
Web · iOS · Android
03Our product
SigmaCPM
Construction project management where AI reads the tender and shows its work.
One project record for civil contractors, from tender to closeout: bids, contracts, RFIs, vendor quotes, and drawings. The AI pulls line items and bond terms out of tender PDFs and cites the page for every value.
Web · API · Chrome extension
Questions
Backend development questions we get asked.
What is the difference between backend development and API development?
The API is the front door: the endpoints your apps and partners call. The backend is everything behind it: the data model, jobs, queues, permissions, and integrations. Our API development page covers the door. This page covers the building.
Python or Node for our backend?
Python with FastAPI or Django when there is AI, data processing, or heavy integration work, since that is where Python's libraries are strongest. Node when the team and the rest of the stack are JavaScript, as with Kraftr's BullMQ workers. We recommend one after we see the product.
Can you fix a backend that keeps falling over?
Yes. We read the code and the logs to find where jobs die, where data goes wrong, and what has no retry. Then we fix the worst of it first, usually queues, locks, and missing constraints, before adding features.
How do you make sure one customer cannot see another's data?
Isolation sits below the UI: row-level security in Postgres, or one backend layer every request passes through, plus tests that try to read another tenant's records. Pullsy's multi-tenant isolation is covered by tests.
Where will the backend run?
In your cloud account. Our backends run on Google Cloud Run, Railway, Cloudflare Workers, Firebase App Hosting, and Supabase, and we pick based on the workload and what your team can maintain.
Backend development
Tell us what keeps breaking, or what has to scale.
The jobs, the data, and the systems your product depends on. We will sketch the backend and say what we would build first.