DEV Community: Raviraj Jariwala

What We Learned While Rebuilding RBAC for a B2B SaaS

Raviraj Jariwala — Tue, 07 Jul 2026 08:12:37 +0000

TL;DR: A multi-instance B2B platform had 700 lines of hardcoded navigation with inline permission checks, no route-level security, and Cognito group changes requiring code deploys. We separated instance config, group-based RBAC, and per-user overrides into three distinct layers: moved navigation to the database, built a flat group-to-policy mapping, and added a two-gate route enforcement system. Access changes went from "deploy a PR" to "update a DB row."

Nobody designs a broken permission system on purpose. Ours wasn't a mistake. It was the right call, made correctly, several times in a row.

With one client and a dozen users, hiding a sidebar item behind a flag isn't a shortcut. It's the correct amount of engineering. Building a permissions layer at that scale would have been solving a problem we didn't have yet.

A few clients later, another feature ships with its own access rule. Another flag goes in next to the last one. Still the right call. A real RBAC system still costs more than the problem it would solve.

Then a client asks for a custom navigation just for their instance. There's no layer for "per-client" anywhere in the system, so it goes in the same place everything else did. That's not laziness. It's consistency with how the codebase already works.

Fast forward to a dozen clients and a hundred menu items, and the same decision, repeated at ten times the scale, isn't cheap anymore. It's a 700-line file where every item carries its own inline permission check, and shipping one more feature means finding the right spot in it, wiring up another hasAccess() call, and testing everything around it before you deploy.

Nothing here was ever broken by a bad decision. The system just outgrew the scale it was built for.

That was us.

What We Were Building

We were building a multi-instance B2B SaaS platform. Each client gets their own isolated instance. Their employees use it daily: Sales, Marketing, Content teams, Executives. Same app, completely different access needs.

The product had grown to multiple modules. Each module had sub-features. Each sub-feature had its own access requirements. And underneath all of that, each client had a different subscription: some had all modules, some had three, some had two.

On paper, not a complicated problem. In practice, we had made it one.

The Real Problem

When a client asked us to restrict the Reports section for a specific employee, the answer was: "We'll need to create a new user group in Cognito, redeploy, and it'll be live in a few hours."

That's not a permission system. That's a deployment pipeline masquerading as one.

The navigation file looked like this:

const menuItems = [
  {
    label: 'Customers',
    link: '/app/customers',
    icon: <CustomersIcon />,
    hidden: !hasCustomerAccess(),
  },
  {
    label: 'Reports',
    link: '/app/reports',
    icon: <ReportingIcon />,
    hidden: !hasReportingAccess(),
  },
  {
    label: 'Budget',
    link: '/app/budget',
    icon: <CoinsIcon />,
    hidden:
      !hasAccess(budgetRoles.BUDGET_FULL_ACCESS) &&
      !hasAccess(fullAdminRoles.FULL_ADMIN),
  },
  // ... 60 more items like this
]

Every item. Inline. In code. Adding a new feature meant opening this file, finding the right place, wiring up a new hasAccess() call, and shipping a deploy.

There were three things happening that shouldn't have been:

Access changes required code deploys. Every time a group needed different access, a developer had to touch the navigation file and ship it. For a platform serving multiple clients simultaneously, this was a constant low-grade tax on engineering time.

Route protection stopped at the group level. Routes did call hasAccess(), the same Cognito group check the sidebar used, before rendering a component for a given path. But that was the only gate. There was no way to block one specific person without pulling their entire group's access, so a one-off restriction only ever lived in the sidebar. If someone hid from the menu still knew the URL, the route let them straight in.

One-off exceptions were impossible. If a client wanted their Sales Manager to see everything except the Budget module, there was no clean way to do it. Every exception became a new Cognito group, which accumulated over time into a list nobody fully understood.

Separating Three Things We Had Mixed Together

The first useful thing I did was stop thinking of this as one problem.

What looked like a permission problem was actually three separate concerns we had conflated into one system:

Once I separated these three, each one had an obvious solution. The mess came from trying to solve all three in the same place.

What Changed

1. The Navigation Moved to the Database

Before: navigation hardcoded in JS

src/
  components/
    Sidebar/
      helpers.js       ← 700+ lines, every menu item hardcoded
      permissions.js   ← hasCustomerAccess, hasCorporateAccess...
      Icons/           ← 30+ icon files

After: navigation lives in the DB, code just renders it

src/
  core/
    ui/
      Sidebar/
        SideNav.jsx        ← fetches menu, builds tree, renders
        helpers.js         ← menuArrayToTreeWithFilter()
        components/
          StaticNav.js     ← product icons strip
          NavDrawer.jsx    ← feature list flyout

Every menu item is now a database row:

ui_config_menu
┌─────────────────┬──────────────┬─────────────────────────────────┬─────────────────┐
│ menu_identifier │ url          │ access_policies                 │ product_id      │
├─────────────────┼──────────────┼─────────────────────────────────┼─────────────────┤
│ customers_list  │ /app/cust... │ ["customer_full_access",        │ 2               │
│                 │              │  "customer_restricted_view"]    │                 │
├─────────────────┼──────────────┼─────────────────────────────────┼─────────────────┤
│ reports_main    │ /app/repo... │ ["report_full_access",          │ 1               │
│                 │              │  "reports_advance_flow_full"]   │                 │
├─────────────────┼──────────────┼─────────────────────────────────┼─────────────────┤
│ budget_overview │ /app/budg... │ ["budget_full_access",          │ 1               │
│                 │              │  "full_admin"]                  │                 │
└─────────────────┴──────────────┴─────────────────────────────────┴─────────────────┘

The frontend fetches this at runtime and builds the tree dynamically:

export const menuArrayToTreeWithFilter = (items, userGroupsAndPolicies, userCognitoData) => {
  items.forEach((item) => {
    const isRestricted = restrictedMenuIdentifiers.has(item.menu_identifier)
    if (isRestricted) return                                    // per-user block

    if (!hasProductAccess(item.product_id, userCognitoData)) return  // subscription check

    const hasAccess = item.access_policies?.some(              // RBAC check
      (policy) => userGroupsAndPolicies?.includes(policy)
    )
    if (hasAccess) parent.children.push(item)
  })
}

Adding a new feature to the nav is now a database row. No PR. No deploy. No risk.

2. A Flat Group Model, Not a Hierarchy

I considered building a role hierarchy, where admin inherits from manager which inherits from user. I dropped the idea quickly.

For this kind of business platform, access is naturally group-shaped, not hierarchical. Sales gets sales access. Marketing gets marketing access. CEO gets everything. No inheritance chain to reason about.

Instead, there's a mapping table between Cognito groups and access policies:

user_group_access_list

Cognito Group         →    Access Policy
─────────────────────────────────────────────
sales_team            →    customer_full_access
sales_team            →    product_restricted_view
sales_team            →    dashboard_season_view

marketing_team        →    customer_non_restricted_view
marketing_team        →    social_full_access
marketing_team        →    dashboard_full_access

exec_team             →    full_admin

At login, Cognito groups get expanded into a flat list of all access policies the user holds:

export const setUserGroups = async (userGroupAccessList = [], callback) => {
  const cognitoGroups = getCurrentUser()?.userGroups || []

  // expand each group into its access policies
  let accessPolicies = []
  Object.keys(groupAccessByUserGroup).forEach((group) => {
    if (cognitoGroups.includes(group)) {
      accessPolicies.push(...groupAccessByUserGroup[group].map((i) => i.access_policy))
    }
  })

  // store the full expanded list in session
  user.userGroups = [...new Set([...cognitoGroups, ...accessPolicies])]
  setUser(user)
}

Every access check from that point uses this expanded list. The indirection matters: if we want to change what the sales team can access, we update the mapping table. No Cognito change. No code change.

3. Two Gates on Every Route

Before: routes only had one gate, the group check

After: routes have two gates, group check and per-user deny-list

In code:

const RestrictedRoute = ({ Component, accessList, ...props }) => {
  const path = props.location.pathname
  const { gatsbyUserData, user } = useAuthContext()
  const { urlPathMap } = useSidebarContext()

  // Gate 1: group access
  const hasAccess = hasValidAccess({
    accessList: gatsbyUserData?.userGroups || [],
    namesOfAccessList: accessList || [],
  })

  // Gate 2: admin deny-list
  const isRestricted = user?.restricted_menu_identifiers?.includes(
    urlPathMap[path]?.menuIdentifier
  )

  if (!hasAccess || isRestricted) return <AccessDenied />

  return <Component {...props} />
}

Both gates have to pass. The first checks group membership. The second checks whether an admin has explicitly blocked this specific item for this specific user.

4. Per-User Exceptions Without Engineering

For the edge cases, where one specific person needs a different scope than their group, we built an admin UI. It shows the user's accessible menu as a tree. An admin checks or unchecks items. Changes save immediately.

Manage User Access: John Smith (Sales Team)
─────────────────────────────────────────────
☑ Customers
  ☑ Customer List
  ☑ Customer Details
  ☑ Import
☑ Products
  ☑ Tickets
  ☐ Hospitality        ← unchecked by admin
  ☑ Merchandise
☑ Dashboard
  ☐ Revenue Flow       ← unchecked by admin
  ☑ Season View

This is purely a deny-list. It can only restrict, never grant beyond what the group allows. That constraint is intentional: if it could grant extra access, you'd have two systems to keep in sync instead of one.

What used to be a Cognito console operation involving an engineer is now a ten-second admin action.

Before vs After

Decisions I'd Make the Same Way Again

Keeping subscription separate from RBAC. Product availability is instance configuration, answered at provisioning and doesn't change. Mixing it into the permission system would have coupled two concerns with completely different owners and change frequencies.

Deny-list over per-user allow-list. An allow-list creates a maintenance problem: you'd need to keep it in sync with group access as groups evolve. A deny-list composes cleanly on top. Edge cases are almost always about restricting, not granting.

Client-side menu filtering. The menu builds and filters in the browser. The real security boundary is the API layer. For an internal platform with controlled users this is the right call. The sidebar is a UX concern, not a security perimeter.

What I'd Tell Someone Starting This

The hardest part wasn't the implementation. It was resisting the urge to solve all three concerns (subscription, group access, individual exceptions) in one system.

When access control feels messy, it's usually because these three things have been layered on top of each other in the same place over time. Nobody designed it that way. It accumulated.

Separating them, even if the resulting code feels like more pieces, makes every individual decision obvious. You always know which layer you're working in and why.

The complexity doesn't disappear. It just gets organized.

What I learned refactoring a codebase with a 7,558-line constants file"

Raviraj Jariwala — Sun, 21 Jun 2026 14:37:24 +0000

If you've ever opened a file to fix a bug and spent forty minutes just figuring out where the bug lives, this post is for you.

Not because the bug was hard. Because the code had no home.

I've been the sole frontend developer on a sports data platform serving 5+ professional sports clubs. I've worked on this codebase for a few years now, across everything on the frontend — auth flows, build configuration, product features, UI design implementation. When I joined, there were other developers on the team. By the time this refactor started, it was just me.

One of the things I was working with was a file called constant.js with 7,558 lines in it. That number tells you everything you need to know about the state of things.

This is what I did about it, the decisions I made along the way, and what I'd share with anyone facing something similar.

TL;DR: I restructured a 6-product React/Gatsby codebase — 1,100+ files, a 7,558-line constants file, 30-minute builds — into a clean module architecture, fixed two auth bugs affecting real users, and shipped the whole thing without pausing feature delivery.

How codebases get this way

It's worth starting here because I think developers are too quick to blame the people who came before them.

Nobody writes a 7,558-line constants file on purpose.

It starts as a place to put a few shared values. Then one developer adds a constant. Another adds five more. A deadline hits, someone adds twenty at the bottom and ships. Nobody sounds an alarm when a constants file hits 500 lines. Or 1,000. Over years, across multiple developers with different styles, that file becomes something nobody fully understands and everyone is afraid to touch.

That's exactly what happened here.

The platform is a React + Gatsby SaaS app for professional sports organisations. 6 products in one codebase: broadcast analytics, social media tracking, news sentiment, customer intelligence, deal management, revenue forecasting.

When the project started, the team was moving fast on an early-stage product. That's the right call at that stage. You ship, you figure out architecture later.

The problem is "later" kept getting pushed back. By the time I joined, there were a few developers' worth of different coding styles layered on top of each other with no consistent structure.

Everything lived in src/components/ and src/components/pages/. No grouping by product, no grouping by feature. Just files, alphabetically, forever.

And honestly? I followed the same pattern when I joined. You do. You're onboarding into an existing codebase, you match what's already there.

Then the product matured, the client base grew, and what used to be manageable became painful to work in every single day.

What had actually accumulated

Here's the concrete picture. Before any refactoring, the codebase had:

constant.js with 7,558 lines, a single file holding every constant the app had ever needed
utils.js with 1,115 lines, every helper function all in one place
src/components/ with 1,100+ files, no grouping by product or feature
3 unused npm packages still being compiled on every build (@material-ui/core, @material-ui/pickers, apollo-boost)
2 login bugs affecting real users
30+ minute build times on every deploy

Those two login bugs are worth explaining because they were the most user-facing pain.

The first: after your first login, changing the URL from the address bar logged you out. The post-login redirect logic was conflicting with the router state, and navigating away triggered it.

The second: random mid-session logouts. Picture a club analyst mid-presentation, pulling up a live report, and suddenly staring at the login screen. The cause was the idle timer living in component state. Every re-render was resetting it, creating a race condition that eventually fired the logout.

And on top of all this, there was the UI situation.

Some clients were still on the old version. Others had been migrated to the new one. So at any point in time there were three things running:

The legacy UI (still live for some clients)
The new UI (live for others, actively getting features)
A refactoring branch sitting on top of the new UI

Three states of the same codebase. Simultaneously. Picture trying to hold all three clearly in your head every morning before writing a single line of code. New features couldn't pause. Clubs were using this every day.

The call that started the refactor

I had a conversation with the client and laid it out plainly.

The codebase was slowing everything down. Debugging was slow, builds were slow, adding features was getting harder because nothing had a clear home. The ask was simple: let me restructure while still delivering features. No freeze, no "we'll pause and clean up."

They agreed. And then came the harder part: figuring out how to actually do it.

The approach

The temptation with a refactor like this is to fix everything in one big branch. I considered it. It would have been a mistake. It ends in a merge conflict nightmare that never ships.

The constraint here, that features couldn't pause, was actually a gift. It forced the refactor into pieces small enough to be independently merged. One product per PR.

Discover first, then Social, News, Broadcast, Deal Management, Media Hub. Six PRs, each self-contained, each mergeable without the others being finished.

But before moving a single file, the target structure needed to be clear.

Picture opening your editor on the old codebase and seeing this:

Before:

src/
  components/          (1,100+ files, no product grouping)
  components/pages/    (same problem)
  utils/
    constant.js        (7,558 lines)
    utils.js           (1,115 lines)

No labels. No ownership. Every file looks the same regardless of which of the 6 products it belongs to.

Here's what the same codebase looks like after:

After:

src/
  core/                shared across 2+ products
    ui/                reusable UI components
    utils/             split by domain (dates, numbers, charts)
    constants/         split by domain
    hooks/
    services/
    auth/
    features/          global features with their own API calls
  modules/
    airwave/           broadcast analytics
    reach/             social media tracking
    headlines/         news sentiment
    compass/           customer intelligence
    pipeline/          deal management
    studio/            media hub

You can see at a glance which product a file belongs to. You can see what's shared and what isn't.

The rule for src/core/ is simple: if more than one product needs it, it lives here. Nothing product-specific.

The rule for src/modules/{name}/ is visual: the folder structure mirrors the URL. If the route is /app/airwave/insights/overview, the file lives at src/modules/airwave/pages/insights/Overview/. You read the URL, you know exactly where to look.

src/core/features/ is for global features that span products or don't belong to any one of them: things with their own API calls, side effects, and state.

The last piece before starting was adding path aliases to jsconfig.json: @core/*, @modules/*, and product-specific aliases for the most complex ones.

This sounds small. It's probably the highest-leverage change in the whole refactor. No more ../../../components/something. Every import tells you where the file lives.

The mechanics of moving 1,100+ files

This is where things actually go right or wrong, so it's worth being specific.

Step one: import conversion.

I wrote a script to convert relative imports to absolute imports using the new path aliases. The important thing was running it one feature folder at a time, not across the whole codebase in a single pass.

If something broke, the blast radius was one feature. Fix it, verify, move to the next folder. Simple but it saved a lot of pain.

Step two: file moves.

VS Code's built-in file move handles most import updates automatically. For everything else, git mv in the terminal.

This matters more than it sounds. git mv tells git the file moved rather than treating it as a deletion and a new file. After the migration, git blame and git log --follow still work. You can still trace why a line was written two years ago by someone no longer on the team.

In a codebase without a test suite, that history is one of the few tools you have for understanding why something was done a certain way. Worth protecting.

What each PR looked like:

Every product PR ended the same way. The last few commits were always: organise product-specific constants into the module, pull anything shared into src/core/, and break down any file over 500 lines into smaller, readable pieces.

Not perfectly small. Just below 500 and coherent enough to open without getting lost.

The hardest part:

The deal management module was the most difficult. It felt like rearranging a room while someone was still living in it. That product was being actively changed based on client feedback at the same time I was restructuring its files. Every day there was a new conflict to resolve between the refactoring branch and what was landing on the main branch.

Honestly, I thought about skipping the deal management module entirely and coming back to it later. Instead I skipped individual files within it when the conflict risk wasn't worth it, noted them, and moved on. A partial migration that ships cleanly beats a complete one that breaks something in production.

Fixing the bugs

Login bug one (URL change logging users out):

The post-login redirect logic was conflicting with the router state. Navigating via the address bar after first login triggered the logout flow.

Fixed by simplifying: always redirect to the home route on login, then let the router handle navigation from there. One clear responsibility, no conflicts.

Login bug two (mid-session logouts):

The idle timer moved from component state to useRef. No more re-renders, no more race condition.

User data fetching changed from sequential to concurrent. And localStorage cleanup on logout was scoped to only the specific keys that needed clearing, instead of wiping everything.

The build time:

Removing @material-ui/core, @material-ui/pickers, and apollo-boost from package.json was the bulk of the improvement. They were being compiled on every build and hadn't been used in a long time.

What changed

3,900+ files touched across 74 commits
Around 18,000 net lines removed (284k deleted, 265k added)
Build time: 30+ minutes → 17-18 minutes, just from removing dead weight
Both login bugs resolved, no reports since
All 6 products with their own clearly bounded home in the codebase
No client disruption throughout, legacy and new UI both stayed live

What I'd do differently

Set up the structure before anyone writes code against the old one.

The hardest part of this refactor wasn't the architecture decisions. It was migrating files while new code was still landing in the old locations. If the module structure and path aliases exist from the start, people move their own code naturally. Running a large migration alongside active development adds friction that didn't need to be there.

Add ESLint rules early.

Right now the conventions live in documentation. That works while I'm the only developer. But the moment anyone else touches the codebase under pressure, the first thing they'll do is import from the familiar old path.

A linting rule that fails the build enforces the architecture without relying on anyone's memory. You set it once, it quietly holds the line for you after that. Two lines of config, permanent guardrails.

The thing worth remembering

Messy codebases aren't created by bad developers.

They're created by good developers solving the right problems at the right time, without the bandwidth to also clean up behind themselves. The mess accumulates quietly, one reasonable decision at a time, until one day it feels heavy enough to slow everything down.

The lesson isn't to plan everything perfectly from day one. That's not realistic when a product is still finding its shape.

The lesson is to recognise when the codebase needs to grow up along with the product, and to make that investment before the cost gets too high.

Looking back, the hardest part wasn't technical. It was doing this alongside active feature delivery without letting either side slip. Almost every win came from removing things, not adding them. The faster build came from deleting dead packages. The auth reliability came from moving a variable to the right place. The debuggability came from splitting nearly 9,000 lines of monolithic files into files that know what they are.

If your codebase feels like this right now, you don't need the perfect plan before you start. Pick one product, one module, one folder. Clean it up. Ship it. Then do the next one.

That's really the whole approach.