Security Even When You're “Just Prototyping”
Why I think about security from day one — even when building small internal tools — and how Lovable’s architecture makes it easier to do it right.
Security Even When You’re “Just Prototyping”
When you’re building a new product — especially alone and early — it’s very easy to postpone thinking about security.
“It’s just me using it.”
“I’ll fix it later.”
“I’m still experimenting.”
The problem is that security is not something you add later. It’s something you design in — or accidentally design out — from the very beginning.
This is the simple mental model I follow when building my tools.
The frontend is not the application
Anything that runs in the browser is public, inspectable, and modifiable.
That means the frontend should never contain:
- Secrets or API keys
- Permission logic
- Validation rules
- Business decisions
The frontend is only responsible for:
- Displaying data
- Collecting user input
- Sending requests
All important logic lives elsewhere.
The backend is where trust exists
All authentication, validation, and business logic must live on the server — in Edge Functions.
This creates:
- A single place where permissions are checked
- A single place where data is validated
- A single place where sensitive operations happen
This makes the system easier to reason about and safer by design.
Row Level Security defines data ownership
Row Level Security is not an optional feature.
Without it:
- Users can see data that does not belong to them
- Multi-tenant data separation breaks
- A single mistake can expose entire tables
RLS defines:
- Who can see what
- Who can change what
- How users, teams, and organizations are separated
If RLS is missing or wrong, the system is wrong — even if everything else looks fine.
Authentication is infrastructure, not UI
Login screens are user experience.
Authentication itself is infrastructure.
The UI reacts to authentication state, but never decides what is allowed.
All permission checks happen server-side.
This separation is critical.
Internal does not mean safe
Even internal tools:
- Can be misconfigured
- Can be published accidentally
- Can grow into real products
That’s why internal tools should still have:
- Authentication enabled
- RLS configured
- No secrets in the frontend
It costs little now and prevents large problems later.
Final thought
Security is not a checklist you run before launch.
It’s a structural decision you make at the start.
Fast is not skipping structure.
Fast is choosing a structure that doesn’t break when you grow.