DEV Community: Apurba Singh

From Python to Laravel: Why I Built My Own IAM System Instead of Using Existing Packages

Apurba Singh — Sat, 04 Apr 2026 05:30:57 +0000

As a backend developer, I’ve spent most of my career working with Python — FastAPI, Django, Flask.
I’ve always cared about one thing deeply:
👉 building systems that scale without becoming messy
But there was one problem I kept running into… no matter the stack.

🧠 The Problem: The “Global Role” Trap
At first, everything looks simple:
• Users
• Roles
• Permissions
But as systems grow, things start breaking.
Most RBAC (Role-Based Access Control) packages assume:
👉 a user is either an Admin… or they aren’t.
But real-world systems are never that simple.

A real scenario:
• A user is a Manager in Branch A
• The same user is a Viewer in Branch B
Now ask yourself:
👉 How do you model this cleanly?

Most of the time, we don’t.
We write conditions like:
if ($user->role === 'manager' && $branch_id === 1) { ... }
And slowly…
• logic spreads everywhere
• dependencies grow
• and one small change breaks multiple parts of the system

😵 When It Became a Problem
Across multiple projects, I saw the same pattern:
• Roles started multiplying
• Permissions became unclear
• Debugging access issues became painful
It didn’t matter if I was using Python or Laravel.
👉 The problem wasn’t the framework.
👉 The problem was the model.

🔄 The Turning Point
While working on Laravel-based systems, I explored existing solutions like Spatie.
They are great — clean, simple, and widely used 👏
But for complex systems, I kept hitting limitations:
• No real support for contextual authority
• Difficult to manage multi-tenant permissions
• Hard to model relationships between roles and scopes
At some point, I stopped trying to “work around” the problem.
👉 I decided to rethink it.

🚀 Building Laravel IAM
Instead of focusing only on roles, I started thinking in terms of:
👉 relationships + context + resolution

This led me to build:
Laravel IAM (v0.2.0)

⚙️ The Core Idea: The Four Levels of Truth
Instead of hardcoding logic, the system resolves permissions through layered specificity:

*Global *→ . (Super Admin)
Resource Wildcard → invoice.*
Action Wildcard → *.approve
Atomic Permission → invoice.approve This makes permission checks: • predictable • scalable • easy to reason about

🧩 Context Matters
The same role doesn’t mean the same thing everywhere.
So the system supports:
• Tenant-based roles
• Team-based roles
• Branch-level permissions
👉 Without turning your code into a mess

💡 What I Learned
This journey taught me something important:
👉 Authorization is not about roles — it’s about context
And even more importantly:
👉 Architecture matters more than framework

⚙️ Under the Hood
Some design decisions behind the system:
• Registry Pattern → decoupled resources & actions
• Flexible Role Assignment → supports IDs, slugs, or models
• Scoped Middleware → supports contextual authorization
• Blade Directives → clean UI permission checks
And yes — everything is backed by a test suite simulating real workflows ✅

🛠️ Open Source
I’ve open-sourced the project and would genuinely love feedback:
📦 https://packagist.org/packages/apurba-labs/laravel-iam
💻 https://github.com/apurba-labs/laravel-iam

💬 Let’s Talk
How do you handle complex permissions in your systems?
Have you faced similar challenges with RBAC?

This is a submission for the 2026 WeCoded Challenge (https://dev.to/challenges/wecoded-2026): Echoes of Experience

Built with ☕ and logic by Apurba Labs.

Laravel #PHP #Python #IAM #RBAC #SaaS #Backend #OpenSource #WeCoded #wecoded2026

I’m a Python Developer — So I Built a Better IAM System for Laravel

Apurba Singh — Fri, 03 Apr 2026 19:16:58 +0000

I’m a Python/FastAPI Developer — So I Built an IAM System in Laravel
As a backend developer working with FastAPI, Django, and Flask, I’ve always cared deeply about clean architecture and scalable authorization systems.
But every time I built a SaaS product, I ran into the same problem:
👉 Permissions become messy… very quickly.

🧠 The Real Problem: Contextual Authority
Let’s say:
• A user is a Manager in Branch A
• The same user is a Viewer in Branch B
Most RBAC systems struggle here.
You either:
• add tons of conditional logic ❌
• or end up with tightly coupled, hard-to-maintain permission rules ❌

😵 The Breaking Point
When systems grow, you start seeing:
• Role explosions (too many roles)
• Nested dependencies
• Hardcoded permission checks
• “Who can do what?” becomes unclear
I faced this repeatedly in Python projects…
and surprisingly, the same issue exists in Laravel.

🚀 So I Built: Laravel IAM (v0.2.0)
Instead of patching the problem, I designed a system that handles:
✔ Contextual permissions (per scope: tenant, team, branch)
✔ Wildcard permissions (expense., *.)
✔ Hierarchical access (manage → all actions)
✔ Dynamic resolution (no hardcoded roles)

⚙️ The Core Idea: “Four Levels of Truth”
The engine resolves permissions using a layered approach:

Direct Permission → exact match
Wildcard Match → resource.*
Hierarchy Rule → resource.manage
Global Access → . This allows instant and predictable permission resolution — even in complex SaaS environments.

🔥 Why Not Just Use Existing Packages?
Packages like Spatie are great for basic RBAC 👏
But they don’t fully solve:
• Context-based access control
• Dynamic multi-tenant systems
• Workflow-aware permission resolution

💡 Example
IAM::can($user, 'expense.approve');
No complex conditionals.
No hardcoded roles.
Just clean, predictable logic.

🛠️ Open Source — Try It
I’ve open-sourced the project and would love feedback from the community:
📦 Packagist: https://packagist.org/packages/apurba-labs/laravel-iam
💻 GitHub: https://github.com/apurba-labs/laravel-iam

💬 Let’s Discuss
How do you handle contextual permissions in your projects?
Have you faced similar issues with RBAC systems?

Laravel #PHP #FastAPI #RBAC #IAM #SaaS #Backend #OpenSource

I Built a Laravel Approval Engine to Stop Email Spam 🚀

Apurba Singh — Wed, 25 Mar 2026 23:33:15 +0000

Over the last few months, while working on enterprise Laravel projects, I noticed a recurring "Notification Nightmare."

Every company needs an approval workflow (requisitions, invoices, PTO), but most systems flood managers with separate notifications for every single item.

I decided to build a solution: Laravel Approval Engine.

🔥 The "Smart Batching" Concept

The core problem with enterprise workflows isn't the approval logic; it's notification fatigue. Instead of sending 50 separate emails for 50 pending approvals, my engine buffers them into 1 smart batch. The manager receives a single, clean digest with secure, token-based links to approve everything at once.

🏗️ How it Works

The architecture is designed to be modular and plug-and-play.

Define a Module: Use php artisan make:workflow-module to create a logic class.
Queue Records: Your business models enter a "pending" state.
The Processor: A scheduled artisan command bundles pending records into a Batch.
Action: The approver receives a single email. They can Approve All, Reject, or View Details via a secure Next.js dashboard.

🧠 Technical Highlights

Multi-stage Workflows: Easily route from Manager -> Finance -> CEO.
Token-based Security: Approvers don't even need to log in to take action.
Event-Driven: Hooks for every stage (Created, Approved, Escalated).
Next.js Dashboard: A sleek frontend for managing the workflow status.
Laravel 12 Ready: Built to work with the latest PHP 8.2+ features.

📊 The Workflow Flow

graph TD
    A[Pending Records] --> B[Smart Batch Created]
    B --> C[Email Digest Sent]
    C --> D[Approver Clicks Link]
    D --> E[Stage Resolver]
    E --> F{Next Stage?}
    F -- Yes --> G[Create Next Batch]
    F -- No --> H[Workflow Completed]

🚀 Try the Demo

I've included a demo inside the repo so you can see it in action in under 2 minutes:

git clone https://github.com/apurba-labs/laravel-approval-engine
cd laravel-approval-engine/example/laravel-demo
composer install
php artisan approval:demo

🔗 GitHub

I’d love for the community to check it out, give it a star, or suggest new features!

👉 Get the Code on GitHub

Would love to hear your feedback! How do you handle complex approval routing in your own Laravel apps?