Small and medium-sized businesses often rely on spreadsheets, WhatsApp messages, or disconnected tools to manage customers, orders, and schedules. While large CRM platforms exist, they are often expensive, complex, and poorly aligned with how small operational businesses actually work.
While delivering a production CRM SaaS platform for UK manufacturing businesses, I designed a system focused on simplicity, security, and real-world workflows using Supabase and Retool. This article shares the key product and technical decisions behind that system and how similar patterns can be applied when building secure SaaS tools for SMEs.
The Real Problem with Traditional CRMs for SMEs
Many mainstream CRMs are:
Built around sales pipelines rather than operations
Difficult for non-technical teams to use
Overloaded with features small teams don’t need
Expensive when scaled across multiple users
As a result, many SMEs continue to operate with spreadsheets despite the risks around data consistency, access control, and scalability.
My goal was to build a workflow-first CRM that:
Centralises operational data
Supports multiple internal users securely
Remains simple and cost-effective
Why I Chose Supabase & Retool
Supabase (PostgreSQL + Auth + RLS)
Supabase provides a managed PostgreSQL database with built-in authentication and Row Level Security (RLS). This makes it ideal for SaaS systems where data protection must be enforced at the database level, not just in the frontend.
Key reasons for choosing Supabase:
Native PostgreSQL (strong relational modelling)
Row Level Security for fine-grained access control
Simple authentication integration
Scales well for production systems
Retool (Frontend & Internal Tools)
Retool allowed me to rapidly build:
Role-based dashboards
Internal tools for business users
User-friendly interfaces for non-technical teams
This combination made it possible to move fast without compromising security.
High-Level Architecture
The system follows a straightforward SaaS architecture:
Users
↓
Retool (Frontend dashboards & workflows)
↓
Supabase (Auth + RLS)
↓
PostgreSQL Database
The most important design principle was that security rules live in the database, not just in the UI.
Database-Per-Client Isolation
Instead of a shared multi-tenant database, I chose a database-per-client model:
Each client has a separate Supabase project/database
This significantly reduces cross-tenant risk
It simplifies access control and compliance concerns
Within each client database, user access is still strictly controlled using RLS policies tied to authenticated users.
This approach is especially suitable for early-stage SaaS platforms serving SMEs with strong data isolation requirements.
Implementing Secure Multi-User Access with RLS
One of the most important technical aspects was enforcing user-scoped access using Row Level Security.
Rather than trusting frontend logic, access rules are enforced directly in PostgreSQL.
A simplified example:
CREATE POLICY "Users can read their own orders"
ON public.orders
FOR SELECT
USING (user_id = auth.uid());
This ensures:
Users can only access their own records
Even if the frontend is bypassed, data remains protected
Security remains consistent across all tools and queries
This pattern is critical for any SaaS handling sensitive business data.
Designing a Practical CRM Schema
The database schema was designed around real operational workflows, not generic CRM concepts.
Core entities included:
Customers
Orders
Scheduling / dates
Users and roles
The focus was on:
Clear relationships between entities
Avoiding duplicated data
Supporting future feature expansion
A relational design made it easier to maintain data integrity and evolve the product over time.
Lessons Learned Building for Real Businesses
Building for real users highlighted several important lessons:
Simplicity beats features for SME adoption
Security must be invisible but reliable
Business owners care more about clarity than dashboards
Rapid iteration based on feedback is a competitive advantage
Many decisions were guided by direct conversations with business owners rather than assumptions.
Scalability & Future Improvements
The system was designed to scale gradually by:
Adding new workflow modules
Enhancing reporting and analytics
Introducing customer-facing portals
Automating repetitive operational tasks
Because the core architecture is modular, these improvements can be introduced without redesigning the system.
Final Thoughts
Building secure SaaS products for SMEs doesn’t require enterprise complexity — but it does require thoughtful architecture and strong security foundations.
By combining:
PostgreSQL + RLS (Supabase)
Rapid frontend tooling (Retool)
Workflow-driven product design
It’s possible to deliver production-grade systems that genuinely improve how small businesses operate.
This approach has allowed me to deliver a secure CRM SaaS platform currently being adopted by UK businesses, and the same patterns can be reused across many SME-focused digital products.
Top comments (0)