Case Study
Randibot
For a 0→1 SaaS MVP that automates RCMS · K-Startup grant operations, I designed a multi-tenant backend and ETL pipeline so onboarding each agency became a configuration task instead of a code change.
- Next.js
- NestJS
- PostgreSQL
- Multi-tenancy
Problem
Randibot was built to collect and normalize public grant-budget execution data from RCMS and K-Startup. Each agency had slightly different operational rules, and handling each new customer with custom code would have slowed the product down immediately.
The real target was not “automate scraping,” but to create a SaaS foundation where customer-specific differences could be absorbed through configuration while data, permissions, and operations remained cleanly separated.
What I built
I structured the backend around `tenancyId = workspaceId`, separating collection rules and post-processing options into workspace-level configuration. That kept the application logic shared while maintaining hard boundaries between tenants.
The RCMS · K-Startup pipeline was split into staged jobs so failures could be retried and traced without reprocessing everything. Operators could onboard a new institution by entering workspace settings rather than waiting for a backend deploy.
Outcome
In production, the system onboarded 5 workspaces without code changes and handled roughly 1,200 ETL runs per month. The important shift was that “adding a new agency” became an operations task instead of a development request.
That made this project less about adding features and more about establishing the SaaS shape that later sales and operations could scale on top of.