DEV Community: kensaadi

A cantonal parliament asked for one shared taxi dispatch. The government answered that it is the operators' business

kensaadi — Thu, 05 Nov 2026 09:02:28 +0000

On 31 January 2025 two members of the Ticino cantonal parliament, Tiziano Galeazzi and Roberta Soldati, filed a motion on the taxi sector. The point that matters to anyone actually running a dispatch operation is the second one: they ask for "a study of a unified solution (operations centre) for all taxi operators in Ticino".

And they immediately specify what they do not mean: "not understood as cantonal administration, but as an operations centre", preferably run by private parties, so as not to weigh on cantonal finances.

What else it asks

Beyond the shared dispatch, the motion asks the municipalities and the canton to analyse the problem by reactivating a 2023 intercommunal working group, to put contracts, social benefits, wages and tariffs under a single regulation by abolishing the current A and B categories, to identify who should supervise the system, and to look at foreign experience, including capping the number of drivers.

On that last point: it is the motion's request, reported as such. Software for licensed operators has no business holding a position on how many licences there should be.

The government's answer, and the line that counts

The State Council invited parliament not to follow up on the motion. The main reason is municipal autonomy: the proposal, it writes, "would tangibly affect the current municipal autonomy in defining and managing local specificities". It adds that it does not want to take "the indicated path of cantonalisation", preferring to leave room for different solutions across the territory.

So far, an ordinary refusal. Then comes the sentence that is worth more than the rest. An operations centre run by private parties, the government says, "falls within the freedom of commerce and organisation of those who wish to offer taxi services".

Read for what it is: the canton will not build that dispatch centre, and it puts in writing that building it is up to whoever offers the service. It is not a door closing. It is a door pointed at somebody else.

This is worth stating precisely, because it is easy to misread: the government said no to a public solution and observed that a private one is legitimate. It did not endorse anyone.

Ten years, same place

This is not the first attempt. In 2015 a member of parliament filed a motion for a cantonal taxi regulation modelled on Zurich. That act, according to local press, was withdrawn on 11 December 2023 without having produced the regulation.

Ten years between the first request and the second, and Ticino still regulates taxis municipality by municipality. In Lugano alone, more than two hundred professionals compete for the same ground.

Anyone waiting for the solution to arrive from above now has a track record to reason from, and it says the same thing every time.

A note on sourcing

The number of the parliamentary act and its current status could not be verified on the primary source: the cantonal parliament's own site refused connection from here, repeatedly. So the motion is cited through the press, no act number appears, and nothing is claimed about how the vote went. If and when the primary source is reachable, that detail belongs in the piece.

What is left, and to whom

Three things are known. Parliament thinks a shared dispatch would help. The government will not build it. And the same government writes that building it falls within the freedom of those who offer the service.

There is no fourth party in that list.

Original (Italian): In Ticino la centrale unica l'ha chiesta il parlamento

Disclosure: I build UrbanGo, dispatch software for licensed taxi and private-hire operators. Everything above is sourced; this paragraph is the part where I sell something.

Paris announced its robotaxi consortium. None of the three signatories runs vehicles today

kensaadi — Wed, 04 Nov 2026 09:00:00 +0000

On 23 October 2026 the Métropole du Grand Paris, Bolt and Stellantis presented the Greater Paris Autonomous Driving Living Lab: a consortium to run autonomous vehicles in the Paris metropolitan area. Testing should begin in 2028 in at most five municipalities to the north-west, a second phase would study extending to around thirty more, and commercial service is the target for 2030.

All of it conditional on authorisations, as the partners themselves specify.

Who does what

The division of labour is the most instructive part of the announcement.

The Métropole du Grand Paris coordinates with the municipalities, identifies suitable routes and oversees the evaluation of results. Stellantis supplies the vehicles, built on its "L4-Ready" platforms. Bolt, through its subsidiary Bolt Autonomous Driving Solutions, leads service integration and deployment. One Italian outlet adds that Bolt's job is to organise the service as a whole, connecting vehicles, autonomous driving technology and the customer-facing digital platform; that is a single source and worth attributing rather than treating as settled fact.

The driving technology itself is not assigned. Pony.ai is named as a potential supplier, alongside a reference to NVIDIA platforms, but it is not confirmed.

What the announcement does not say

Three things are missing, and together they weigh as much as what is there. No names of the municipalities, no fleet size, no investment figure.

But the biggest gap is another one: nobody is named as the party that will run the cars day to day. Buying them, insuring them, cleaning them, keeping them charged, sending them to the workshop, replacing one when it stops. That is the job a dispatch company does today with a fleet of people, and in this release it has no name.

Of the three parties at the table, none does it today. A metropolitan authority does not run vehicle fleets. A carmaker builds. An intermediation platform intermediates.

The map is drawn by two of them

There is an element here that Zagreb and London did not show: the public authority is not the body authorising from outside, it is a partner in the consortium. The Métropole coordinates with the municipalities and identifies the routes.

Which means the design of which areas get served, and in what order, is born at a table between an authority and a platform. Five municipalities to start, around thirty as a possible extension. Whoever already drives those streets with their own vehicles is not among the signatories.

The pattern, which is already decided

In every European project announced so far the same shape recurs: someone builds the cars, someone supplies the autonomy, someone runs them, and someone else holds the booking. Four roles, and the fourth needs neither workshops nor depots.

In Paris that fourth role went to the one signatory that today owns none of the things that move.

The job of running the cars remains, and will remain. In the Paris consortium it has not been assigned to anyone yet, which means it is a vacancy. The question that matters is not whether it gets filled, but whether whoever fills it reaches the passenger through a relationship of their own, or through somebody else's.

Original (Italian): A Parigi i robotaxi li annunciano Bolt, Stellantis e la Métropole

Disclosure: I build UrbanGo, dispatch software for licensed taxi and private-hire operators. Everything above is sourced; this paragraph is the part where I sell something.

A Munich taxi company wants 500 robotaxis under its own brand, and on paper that is the opposite model

kensaadi — Tue, 03 Nov 2026 09:00:00 +0000

On 27 October 2026 Münchner Taxi Zentrum, the largest taxi dispatch company in Munich, and California-based Tensor Auto signed a letter of intent to bring up to 500 autonomous vehicles to Germany. Reuters reported it.

Before looking at the model, it is worth fixing what this is not. It is not a fleet. It is a letter of intent, conditional on definitive agreements and on level 4 homologation in Germany. None of those cars is on the road, the financial terms were not disclosed, and everything that follows is how the two companies describe themselves in their own press release.

With that said, it is worth reading, because it describes a structure opposite to every other European announcement so far.

How they tell it

According to the release, MTZ would run the vehicles under its own brand, inside its own taxi service. The Robocar "integrates with MTZ's existing dispatch systems, so riders book and ride with MTZ as they do today". Tensor sells the vehicle and supplies the autonomy on a recurring subscription it calls Autonomous Driving as a Service.

Then the line worth stopping on, again from the release: "control of the fleet, the customer and the data stays with the taxi company and therefore in Europe."

MTZ's chief executive, Gregor Beiner, puts it this way: MTZ will bring autonomous vehicles onto Munich's streets "under its own name, with the service quality and data sovereignty our customers trust". He adds that professional drivers "remain indispensable: wherever personal service, assistance or a human touch is needed, they make the difference".

The stated goal beyond Germany is to place another 10,000 Robocars with European operators within twenty-four months of the vehicle becoming available in Europe, which is a date that does not exist yet.

Why it is different from everything else

Line up the other European announcements.

In Zagreb the rides reach the passenger through Uber's app, and Uber has invested in Verne, which owns the cars. In Zurich the service announced in June is booked from Uber's app, with a local company supervising the fleet. In Paris the consortium announced on 23 October puts together a public authority, a carmaker and Bolt, and the box for whoever will actually run the cars is still empty.

In all three, whoever holds the booking is not whoever holds the cars.

In the Munich announcement that same box is occupied by the dispatch company, and the technology is the thing being rented. If it really worked that way, it would be the first European case where the relationship with the passenger stays where it already was.

The conditional is mandatory, because so far this is a document.

Two models on the table, four days apart

The calendar coincidence is worth noticing. On 23 October, in Paris, Bolt puts itself forward to organise an entire robotaxi service. On 27 October, in Munich, MTZ announces it wants to run one while keeping brand, dispatch and customers. Four days.

What to watch

Not the number 500, which is conditional. Two other things.

First, whether integration into the existing dispatch survives contact with the contract. That is the difference between a dispatch company adding vehicles to its own system and a dispatch company becoming somebody else's driver supplier, and the distance between the two is measured in clauses, not in press releases.

Second, the sentence about data sovereignty. It comes from a technology vendor using it to sell, and that is exactly why it is interesting: control of data has become a commercial argument, something an operator asks about before signing.

Original (Italian): A Monaco una centrale taxi annuncia 500 robotaxi sotto il proprio marchio

Disclosure: I build UrbanGo, dispatch software for licensed taxi and private-hire operators. Everything above is sourced; this paragraph is the part where I sell something.

Lavoro su piattaforma e algoritmi: cosa cambia con la direttiva europea per chi progetta il software

kensaadi — Mon, 02 Nov 2026 19:44:12 +0000

Dal 2 dicembre 2026 gli Stati membri devono avere recepito la direttiva UE 2024/2831. Molti degli obblighi che introduce non sono clausole contrattuali. Sono requisiti di architettura.

Nell’Unione Europea più di 28 milioni di persone lavorano tramite piattaforme digitali. Fanno consegne, guidano taxi e NCC, traducono, si occupano di assistenza domestica, inseriscono dati. Le piattaforme attive sono circa 500 e tra il 2016 e il 2020 i loro ricavi sono passati da circa 3 a 14 miliardi di euro, soprattutto nelle consegne e nel trasporto di persone.

Per anni il punto debole del modello è stato lo status di queste persone. Formalmente sono lavoratori autonomi, ma nella pratica molti seguono regole, orari e vincoli tipici del lavoro dipendente. Senza le tutele che ne derivano.

Con la direttiva sul lavoro mediante piattaforme digitali, adottata dal Consiglio il 14 ottobre 2024, l’UE diventa il primo legislatore al mondo a regolare questo settore in modo specifico. Il termine per il recepimento nazionale scade il 2 dicembre 2026.

Il dibattito pubblico si è concentrato sull’aspetto giuslavoristico. C’è però un secondo livello, meno discusso, che riguarda direttamente chi scrive e mantiene il software di queste piattaforme.

La presunzione di subordinazione

Il primo pilastro è una presunzione legale confutabile. Se esistono elementi che indicano controllo e direzione, il rapporto tra piattaforma e lavoratore si presume di lavoro dipendente. Questi elementi sono definiti dal diritto nazionale, dai contratti collettivi o dalla prassi dei singoli Stati.

L’onere della prova si inverte. Non tocca più al lavoratore dimostrare di essere un dipendente, ma alla piattaforma dimostrare il contrario.

Questo ha una conseguenza tecnica precisa. Il “controllo e direzione” oggi si esercita quasi sempre attraverso il codice: come vengono assegnati i lavori, chi viene penalizzato se rifiuta una corsa, come si calcola il compenso, quando un account viene limitato. Se la piattaforma deve dimostrare di non esercitare un controllo da datore di lavoro, quella dimostrazione passa dalla logica del sistema e dalla capacità di documentarla.

La gestione algoritmica diventa materia regolata

Il secondo pilastro è il più interessante per chi progetta software. La direttiva introduce le prime regole europee sull’uso degli algoritmi nella gestione del lavoro.

In sintesi:

i lavoratori devono essere informati dell’uso di sistemi automatizzati di monitoraggio e di decisione;

i sistemi devono essere supervisionati da personale qualificato, che gode di una protezione specifica da trattamenti sfavorevoli;

le decisioni significative, come la sospensione di un account, richiedono una supervisione umana;

alcune categorie di dati non possono essere trattate. Tra queste ci sono i dati sullo stato emotivo o psicologico, le conversazioni private, i dati usati per prevedere attività sindacali, quelli da cui dedurre origine etnica, status migratorio, opinioni politiche, convinzioni religiose o salute, e i dati biometrici usati per scopi diversi dall’autenticazione.

A questi si aggiungono obblighi di trasparenza verso le autorità nazionali. Le piattaforme devono dichiarare il lavoro svolto e rendere disponibili le informazioni chiave sulla loro attività e sulle persone che vi lavorano, anche quando operano in più Stati membri.

Da norma a requisito

Letti con gli occhi di un architetto software, questi punti si traducono in requisiti molto concreti.

Ogni decisione automatizzata rilevante deve essere tracciabile. Bisogna sapere quale regola o modello l’ha prodotta, su quali dati e in quale momento. Senza un audit trail serio non c’è modo di spiegare una decisione né di difenderla.

Le decisioni ad alto impatto non possono essere solo automatiche. Serve un flusso in cui un operatore umano riesamina, conferma o annulla, con ruoli e permessi definiti. Chi supervisiona, su cosa, con quali poteri. È un problema di RBAC prima ancora che di processo.

La minimizzazione dei dati deve stare nello schema, non in una policy scritta a parte. Se certi dati non si possono trattare, la soluzione più robusta è non raccoglierli e non derivarli, anziché filtrarli a valle.

L’informazione al lavoratore deve essere generata dal sistema stesso. Un documento statico che descrive “come funziona l’algoritmo” invecchia alla prima release. Serve una documentazione legata alla versione effettiva delle regole in produzione.

La reportistica verso le autorità deve essere un output previsto dal sistema, non un’estrazione manuale fatta quando arriva la richiesta.

Chi è coinvolto davvero

Sarebbe un errore pensare che la questione riguardi solo i grandi nomi delle consegne e del ride hailing. Il perimetro è quello delle piattaforme digitali che organizzano lavoro retribuito, e le scelte di recepimento nazionale definiranno i dettagli. Centrali di dispatch, marketplace di servizi, piattaforme di assistenza e software house che sviluppano questi prodotti per conto terzi farebbero bene a verificare la propria posizione adesso, non dopo il recepimento.

Per chi sviluppa software B2B in questi settori c’è anche un’altra lettura. La conformità diventa un criterio di selezione del fornitore. Un sistema che nasce con tracciabilità, supervisione umana e controllo degli accessi integrati vale di più di uno che deve essere adattato a posteriori.

In conclusione

La direttiva non vieta gli algoritmi nella gestione del lavoro. Chiede che siano conoscibili, supervisionati e documentabili. Per i giuristi è una questione di status e tutele. Per chi progetta il software è una questione di architettura: audit, ruoli, flussi di revisione, modello dei dati.

Il termine di dicembre 2026 è vicino. Le piattaforme che arriveranno preparate saranno quelle che hanno trattato la norma come un insieme di requisiti tecnici fin dall’inizio, e non come un documento da far leggere all’ufficio legale.

Fonte: Consiglio dell’Unione Europea, “EU rules on platform work”, consilium.europa.eu
UrbanGo. La piattaforma che rispetta le norme europee.

Switzerland withdrew the reform that would have made a normal driving licence enough to carry passengers

kensaadi — Mon, 02 Nov 2026 09:00:00 +0000

For anyone who carries passengers for a living in Switzerland, 28 October 2026 is the day nothing changed. That is the news, because for ten years people had been working to change it.

That Wednesday the Federal Council took note of the consultation results on a partial revision of five road-traffic ordinances and, in its own words, "decided not to proceed with the project". It is also asking Parliament to strike off the three motions the revision grew out of.

What would have gone

The project targeted the permit for the professional transport of passengers, which the trade calls the TPP permit. Today, to carry people professionally in a category B car, that permit is mandatory: an extra theory and practical exam, one year of clean driving to show for it, medical requirements stricter than those asked of someone driving the same car without paying passengers, and periodic check-ups.

The revision would have removed all of it. No permit, no extra exam, no year of practice, no higher medical bar. An ordinary driving licence would have been enough. The package also proposed logging driving and rest time with a certified app instead of a tachograph.

Why it stopped

The consultation ran from 19 December 2025 to 3 April 2026 and drew 81 submissions: all 26 cantons, two parties, intercantonal bodies, sixteen national transport associations and others.

One question asked whether professional drivers of light vehicles should leave the working-hours ordinance and fall under the general rules. Of the 71 who filled in that part, 13 were in favour and 54 against. That is the 82% figure, and it is the answer to that specific question, not a general verdict on the reform.

The detail that says most about who objected: among the national transport associations, 12 out of 12 were against. Among cantons, 19 of the 25 that expressed a view. The reasons, writes the federal department, were "linked to road safety and the protection of workers in the taxi sector".

This was not even the radical version. Scrapping the working-time and rest rules outright had already been "largely rejected" in the past; this was the softened version, and it was rejected too.

The one element with real support was the app replacing the tachograph, at 75% in favour. The cantons, at 60%, attached conditions strict enough to remove the practical benefit.

Where it came from, and why that is ironic

The motions grew out of UberPop. The explanatory report says so plainly: when intermediation services entered the market there were "distortions of competition", some drivers had no TPP permit, no tachograph and no cantonal or communal licence, and that "allowed them to offer transport services at lower prices".

On 9 March 2016 two national councillors filed the answer: tighten nothing, loosen everything, and competition becomes fair again. Parliament accepted the motions that December.

Ten years later, justifying its own proposal, the Federal Roads Office wrote that lowering the barriers would make it practical to "offer transport services as a secondary activity or at reduced workloads using one's own private vehicle". Then this: "precisely drivers of this type are particularly interesting for intermediation platforms."

A reform born as an answer to the platforms would have produced exactly the kind of driver the platforms need. The sector noticed, and said no.

What this is not

It is not a ban, and it does not concern Uber, Bolt or any other app: platforms operating in Switzerland work with drivers who are already licensed, and the TPP permit does not touch them. It is the withdrawal of a deregulation proposal, not a crackdown.

It is also not about the taxi licence. The TPP permit is federal and attaches to the person driving. Permission to operate a taxi service in Ticino is granted by the municipalities, a separate layer this decision does not reach.

And the three motions are not struck off yet. The Federal Council proposes it; Parliament decides.

What is left on the table

For drivers, the practical answer is the simplest possible: what you needed yesterday you need tomorrow.

For anyone coordinating a fleet there is a less obvious consequence. The entry bar stays high, and a high bar works for whoever is already inside: the pool of available drivers will not widen overnight, and licensed drivers remain contested.

But read carefully what was defended. The profession was defended, meaning who may sit behind the wheel. Nothing was decided about who holds the booking, and no federal ordinance deals with that.

Original (Italian): Per portare passeggeri in Svizzera non basterà la patente B

Disclosure: I build UrbanGo, dispatch software for licensed taxi and private-hire operators. Everything above is sourced; this paragraph is the part where I sell something.

Your UI config quietly became a programming language. Here's the fix

kensaadi — Mon, 07 Sep 2026 10:13:09 +0000

It always starts the same way. You send a form's fields from the server so the team can change them without a
deploy. Reasonable. Then one field has to show only when another field has a certain value. Then a field depends on
two others. Then validation has to cross-check them. Then some fields are hidden for some roles.

Six months later that payload is full of conditions, dependencies, and branching. It has no types. It has no tests.
Nobody can debug it. On a checkout or KYC screen an auditor opens it and cannot tell what it does. You never sat
down to design a language. You grew one by accident, and it is running in production right now.

Mike Hadlow gave this a name: the Configuration Complexity Clock. Every server-driven UI project sits somewhere on
that clock, and it only ticks one way.

Blueprint stops it. It is an open-source UI-contract system with a self-hosted visual Builder, and it went public
today. Here is how it works, and where it draws the line on purpose.

The one rule: describe the screen, not the behavior

Blueprint is a UI contract. The contract carries structure, meaning which components go where, with what data
bindings, visibility, and access rules. It never carries behavior. Logic stays in typed, testable code. That single
boundary is the entire design.

A contract is plain JSON:

{
  "version": "1.0",
  "lib": "tw",
  "root": {
    "type": "form",
    "id": "kyc",
    "children": [
      { "type": "field", "id": "email" },
      {
        "type": "field",
        "id": "taxId",
        "visibleWhen": { "field": "country", "equals": "IT" },
        "access": { "resource": "customer.taxId", "action": "read" },
        "validation": { "required": true, "pattern": "^IT\\d{11}$" }
      }
    ]
  }
}

Three things matter here.

visibleWhen is an object, not a function. It is serializable, so it is inspectable, diffable, and a visual tool can read and write it. You give up some expressiveness for that. On regulated screens, that is exactly the trade you want.
access lives inside the field contract. It is not a <CanRead> wrapper bolted on at the call site.
There is no code anywhere in the payload. No expression strings. No eval. It renders under a strict CSP.

The render pipeline (no eval, ever)

The runtime walks the tree and maps each node's type to a real React component from a closed catalog:

import { DashBlueprint } from "@dashforge/blueprint";

<DashBlueprint
  version="1.0"
  lib="tw"                 // or "mui"
  root={contract.root}     // the JSON above
  data={envelope.data}     // values, from your backend
  rules={policy}           // RBAC policy + named rules
  validationMode="strict"
/>;

Nothing gets compiled from a string. A node whose type is not in the catalog throws a hard, visible error. It is
not a silent injection point. That is what makes it safe to render server-supplied UI on a payment page.

The escape hatch: custom nodes

A closed catalog would be a cage without a door. The door is custom nodes. You register real, typed React components
and reference them by type:

<DashBlueprint
  root={contract.root}
  customNodes={{
     // your component, your code, your tests
    "signature-pad": SignaturePad,
    "id-scanner": IdScanner,
  }}
/>;

The catalog covers the 90%. Custom nodes cover the rest, as code, where logic belongs. The payload stays data. This
is the line that stops config from ever turning into a language.

RBAC and visibility as data (shared front and back)

access and visibleWhen are part of the contract, and one policy governs both the API route and the field it protects. On the client this is not decoration: a provider loads that same policy from the server together with the current user's access and wires it into every component, so the rule the server enforces on the route is the rule the UI applies at render. You declare access, you do not hand-write guards. The rest is in the repo.

Where Blueprint sits (and where it does not)

Builder  ──authors──▶  contract (JSON)
                           │
Your backend  ──fills with data──▶  envelope (contract + data + state)
                           │
Your frontend (Blueprint runtime)  ──renders──▶  real UI

Server-driven UI, and not one line of an interpreter reaches the client.

Now the honest part. Blueprint is not a compliance product. It does not run your business logic. It does not
inventory your third-party scripts. It renders structure and data. It shrinks the surface and governs it. It does
not erase the work.

Builder: author the contract visually

Hand-writing JSON does not scale past a few screens. Builder is a self-hosted visual editor. You drag components,
wire visibleWhen and access, validate live, and export the contract. The runtime is open-source. The Builder is
self-hosted. You clone the repo and run it. Your contracts never leave your infrastructure.
Architecture: https://dashforge-ui.com/blueprint/libraries

Try it

It is self-hosted. No SaaS. No hosted demo. You clone it and run it locally, which is exactly the point:

git clone https://github.com/kensaadi/blueprint
# runtime + Builder both live in this repo. run the Builder locally, render contracts with the runtime

You can also scaffold a fresh React 19 and TypeScript app on Dashforge:

npx dashforge-cli my-app --lib tw

Repo (runtime + Builder): https://github.com/kensaadi/blueprint
Docs: https://dashforge-ui.com/blueprint

One trade-off worth arguing about: serializable conditions instead of functions. Less expressive, but inspectable,
diffable, and auditable. On regulated screens that is the whole point. If you have shipped SDUI in production and
hit a wall this does not cover, open an issue on the repo. Edge cases are how the catalog earns its keep.

RBAC in React and Node: enforce the same policy on both sides

kensaadi — Sun, 30 Aug 2026 09:05:49 +0000

The advice is everywhere: the frontend is UX, authorization belongs on the backend. It is true, and on its own it is useless — because it stops exactly where the hard part starts. Hide a button in the UI and forget the server, and the action is a curl away. Protect the server and hardcode the UI, and the two drift apart the first time the rules change. The question nobody answers is how to keep the button you hid and the endpoint you protected agreeing with each other.

The UI is an affordance, the server is the boundary

They are two different jobs. The UI decides what to show — hide or disable a control the user can't use. That is UX. The server decides what to allow — reject the request. That is security. You need both, and they must agree, but only one of them is the security boundary:

UI only → no security. The endpoint is open; the hidden button is theatre.
Server only → the app offers buttons that answer 403.

The mistake is not doing one of them. It is doing them from two different sources of truth, so they fall out of sync the moment someone edits a rule.

One policy, as data

Define the rules once. A policy is roles mapped to permissions — a resource × action pair, allow or deny:

import { createRbacEngine, type RbacPolicy } from '@dashforge/rbac';

const policy: RbacPolicy = {
  roles: [
    { name: 'admin', permissions: [{ resource: '*', action: '*' }] },
    { name: 'sales', permissions: [
      { resource: 'order', action: 'read' },
      { resource: 'order', action: 'refund', effect: 'deny' }, // explicit deny
    ] },
    { name: 'customer', permissions: [
      { resource: 'self', action: 'update' },
    ] },
  ],
};

const engine = createRbacEngine(policy);

An explicit deny overrides an allow, so you can grant broadly and carve out the exceptions. The engine is a pure function of (roles, resource, action) → decision — no framework, no I/O — which is exactly why the same policy can run on the server and in the browser.

The server: the boundary

Every mutating route consults the engine before the controller runs. The 403 is the thing that actually stops the request:

router.patch('/customer/me',
  requireAuth(secret),
  requireRole('customer'),
  rbacGate(engine, 'self', 'update'),   // resource, action
  controllers.customer.updateMe,
);

export function rbacGate(engine, resource, action) {
  return (req, res, next) => {
    if (!req.auth) {
      return res.status(401).json({ error: 'unauthenticated' });
    }
    if (engine.check(req.auth.roles, action, resource) !== 'allow') {
      return res.status(403).json({ error: 'forbidden' });
    }
    next();
  };
}

This is the line that matters. Delete every check in the UI and the app is still secure. Delete this one and no amount of hidden buttons will save you.

The UI: the affordance, from the same policy

Now the frontend renders from the same engine and the same vocabulary — resource and action — so it can never offer what the server forbids:

<Can action="refund" resource="order" fallback={<DisabledButton>Refund</DisabledButton>}>
  <RefundButton orderId={order.id} />
</Can>

or imperatively, when you need the boolean:

const canRefund = useCan({ action: 'refund', resource: 'order' });

The refund control disappears for a sales user because the policy denies order:refund — and if they forge the request anyway, rbacGate answers 403. Same rule, two enforcement points, one source of truth.

Ownership: "their own", not "any"

Most real rules are not can a customer update a customer but can a customer update **their own* record*. That is a condition on the permission, evaluated against the resource:

{
  resource: 'self',
  action: 'update',
  condition: ({ subject, resourceData }) =>
    subject.id === (resourceData as { ownerId: string })?.ownerId,
}

The server passes the loaded record as resourceData; the UI passes the same shape:

<Can action="edit" resource="order" resourceData={{ ownerId: order.ownerId }}>
  <EditButton />
</Can>

Same condition, both sides. The UI stops offering the button on someone else's record; the server refuses the request if it arrives anyway.

The honest part

<Can> and useCan are UX — they never make anything safe. The only thing that makes the app safe is rbacGate on the server; the UI just stops users from walking into a 403. If you ever have to choose, protect the server. The reason to share the policy is not to promote the UI into a security layer — it is to stop the UI and the server from disagreeing as the rules change.

The checklist

One policy, as data: roles → permissions, resource × action, explicit deny wins.
One engine (createRbacEngine), the same policy on the client and the server.
The server is the boundary: rbacGate(engine, resource, action) on every mutating route, returning 403.
The UI is the affordance: <Can> / useCan from the same policy, hiding or disabling.
Ownership as a condition on the permission, with the same resourceData shape on both sides.
Never ship a UI-only check and call it access control.

The engine is @dashforge/rbac — open source, on npm, framework-free. createRbacEngine(policy) is a pure function you run unchanged in React and in your API. The Checkout Kit demo wires the whole loop end to end — the rbacGate middleware and <Can> in the UI, mirrored in the Go and Node editions.

Originally published on dashforge-ui.com.

Availability slots across timezones and DST

kensaadi — Sun, 30 Aug 2026 08:49:50 +0000

TL;DR: 09:00 is wall-clock time in a timezone, not a UTC instant. Resolve the offset in the business's zone and convert to UTC last, or you're an hour off across zones and grow a phantom slot on the DST change.

source → https://dashforge-ui.com/guides/availability-slots-timezones-dst

An availability engine looks trivial until it ships. It works on your machine, in your timezone, on an ordinary week. Then a customer in another timezone sees every slot an hour off, or the clocks change and a Sunday grows a slot that doesn't exist. Every one of these is the same mistake: treating a wall-clock time as if it were a fixed point in time.

"09:00" is not an instant

A working window — open 09:00 to 12:00 — is wall-clock time in the business's timezone. It is not a UTC offset and not a number of minutes from midnight UTC. 09:00 in a Paris salon is 07:00 UTC in summer and 08:00 UTC in winter, because Paris is UTC+2 under DST and UTC+1 otherwise. The same "09:00" maps to two different instants depending on the date.

So the rule that makes the whole engine correct: build the window in the business's timezone, resolve the offset there, and only then convert to UTC.

The bug: computing slots in UTC (or the server's clock)

Build each boundary as a wall-clock instant in the availability timezone and let the date library resolve the offset on the resulting wall clock. Here that is luxon; the Go edition uses time.Date(y, mo, d, 0, minute, 0, 0, loc) — the same idea.

import { DateTime } from 'luxon';

// "minutes from midnight" → an instant, resolved IN `zone`.
function wallClock(year, month, day, minutesFromMidnight, zone) {
  const days   = Math.floor(minutesFromMidnight / 1440);
  const rem    = minutesFromMidnight - days * 1440; // 0..1439
  const hour   = Math.floor(rem / 60);
  const minute = rem % 60;
  return DateTime.fromObject({ year, month, day, hour, minute }, { zone })
    .plus({ days });
}

The whole trick is { zone }: luxon resolves the UTC offset for that wall clock, on that date — so 09:00 in August gets +02:00 and 09:00 in January gets +01:00, automatically. You never write an offset down.

Then step candidate starts in the zone and keep the ones that fit the window, converting to UTC only at the end:

Prove it: 09:00 in Paris in August is 07:00 UTC

This is the single assertion that pins the whole thing. Paris is UTC+2 in August, so a 09:00 window start must come out as 07:00 UTC — not 09:00 UTC:

const slots = computeSlots({
  availability: weekdayAvail('Europe/Paris', MONDAY),
  date: '2026-08-17',
  durationMinutes: 60,
  now: new Date('2026-08-01T00:00:00Z'),
});

expect(slots[0].startAt.toISOString()).toBe('2026-08-17T07:00:00.000Z');

Compute slots in UTC or the server's clock and this comes out as 09:00Z — an hour wrong, silently, for every customer, forever.

The spring-forward day

The reason to build in the zone rather than add fixed offsets is the transition days. On spring-forward night the local clock jumps 02:00 → 03:00, so the day has 23 hours and the 02:00–03:00 wall time never happens (on fall-back it happens twice). Because each boundary is resolved as a wall clock in the zone — not as "midnight UTC plus N hours" — the offset flips at the right instant and the slots land where a human expects.

That is pinned by a test. A 01:00–05:00 window on the EU spring-forward Sunday is four wall-clock hours but only three real ones, so a 60-minute service yields three slots, not four — the 02:00 local slot is absent, because that hour does not exist:

// 2026-03-29, Europe/Paris — the clock jumps 02:00 → 03:00
const slots = computeSlots({
  availability, // Sunday 01:00–05:00, Europe/Paris
  date: '2026-03-29',
  durationMinutes: 60,
  now: new Date('2026-03-01T00:00:00Z'),
});

// local 01:00, 03:00, 04:00 → UTC 00:00, 01:00, 02:00
expect(slots.map((s) => s.startAt.toISOString())).toEqual([
  '2026-03-29T00:00:00.000Z',
  '2026-03-29T01:00:00.000Z',
  '2026-03-29T02:00:00.000Z',
]);

A "midnight UTC + N hours" engine emits a phantom fourth slot here; this one does not.

The honest part: these two assertions pin the offset case and the spring-forward gap for Europe/Paris. The fall-back day (the hour that runs twice) and every other zone are the same wall-clock resolution, not special-cased code — they follow from the same property, but only these two are behind a test. Copy the wallClock approach and you inherit the property; copy an "add hours to UTC" approach and no test will save you.

Store UTC, compare on instants, render local

Slots come out as UTC instants; store bookings the same way. Conflict detection is then timezone-free — a half-open [start, end) overlap on millisecond instants:

function intervalsOverlap(aStart, aEnd, bStart, bEnd) {
  return aStart < bEnd && bStart < aEnd; // instants, location-independent
}

The customer's browser renders those instants in their timezone. The business defines availability in its timezone. Nothing in between ever stores a wall-clock string as if it were an instant.

The checklist

A working window is wall-clock time in the business's timezone, not a UTC offset.
Build each boundary with the zone attached; let the library resolve the offset on that wall clock. Never hardcode +02:00.
Step candidate starts as zoned datetimes; convert to UTC only on output.
Store bookings as UTC instants; compare with a half-open interval overlap on millis.
Render in the customer's timezone in the UI, never on the server.
Test the offset case and a spring-forward date.

A booking slot at "09:00" is not a point in time. That single wrong assumption is why availability engines ship, run fine all week, then quietly grow a slot that doesn't exist on the Sunday the clocks change.

"09:00" is wall-clock time in the business's timezone. In Paris it's 07:00 UTC in summer and 08:00 UTC in winter — same string, two different instants.

The fix is one rule: build the window in the business's timezone, let the date library resolve the offset there, and convert to UTC only at the end. Never write "+02:00" by hand.

Do the naive "midnight UTC + N hours" and two things break:
→ every customer in another timezone sees slots an hour off
→ the spring-forward day has 23 hours, so it grows a phantom slot at 02:00 — an hour that doesn't exist

I wrote it up with the real code and the two tests that pin it: the Paris offset, and a spring-forward case that returns 3 slots, not 4.

source → https://dashforge-ui.com/guides/availability-slots-timezones-dst

If you build scheduling, this is the bug you don't find until production.

useFieldArray is not updating across steps — and why it can't

kensaadi — Thu, 27 Aug 2026 20:48:19 +0000

If you have a wizard where step two appends to items and step four also appends to items, and the two steps never see each other's data — you have not misconfigured anything. Two useFieldArray instances pointed at the same name cannot observe each other, by design. Each one keeps a private snapshot of that array internally.

react-hook-form documents it plainly:

No two useFieldArray for the same field can be instantiated, as each handles its own snapshot of state internally.

For a single-page form this never surfaces. For a wizard it surfaces on day one.

Why the rule exists

This is not neglect, and it is worth understanding before you work around it.

The reason react-hook-form is fast is that state lives close to the inputs and is not centralised. Inputs are uncontrolled, the form does not re-render on every keystroke, and each useFieldArray owns its slice. Sharing one array across mounting boundaries asks for the opposite architecture — a central store that every instance subscribes to.

That tension is real. It is why the request keeps reopening rather than getting fixed.

The three shapes where it bites

Multi-page forms. Different steps need to update the same field array, and there is no first-party way to share one instance across them.

Conditional fields inside an array item. Uncontrolled inputs do not re-render when a value changes, so showing or hiding a nested field based on a sibling's value simply does not react.

Arrays that mount and unmount. Toggled sections, wizard steps and tab navigation all remount the array — the scenario most likely to lose state in a way that looks like a bug in your own code.

Fix 1 — conditional fields: subscribe narrowly with useWatch

For "show this field only when a sibling has a certain value", there is a clean first-party answer. Do not reach for watch() on the whole form: that re-renders everything and throws away the reason you picked this library.

Instead, extract the dependent field into its own component and subscribe to that one array item with useWatch:

import { useFormContext, useWatch } from 'react-hook-form';

// One component per conditional field. The subscription is narrow,
// so the re-render is narrow too.
function CourierNote({ index }: { index: number }) {
  const { control, register } = useFormContext();

  // Subscribes to exactly items.<index>.method — nothing else re-renders.
  const method = useWatch({
    control,
    name: `items.${index}.method`,
  });

  if (method !== 'courier') return null;

  return (
    <input
      {...register(`items.${index}.note`)}
      placeholder="Delivery instructions"
    />
  );
}

function ItemRow({ index, name }: { index: number; name: string }) {
  const { register } = useFormContext();
  return (
    <div>
      <input {...register(`${name}.sku`)} />
      <select {...register(`${name}.method`)}>
        <option value="pickup">Pickup</option>
        <option value="courier">Courier</option>
      </select>

      <CourierNote index={index} />
    </div>
  );
}

The whole trick is the component boundary. useWatch re-renders the component that called it, so keeping that component tiny keeps the cost tiny. You get reactivity without giving up the uncontrolled model.

Fix 2 — sharing one array across steps: own the context

For the wizard case there is no first-party answer. The pattern that circulates — and the one that actually works — is to instantiate the field array once and hand it down through your own React context, so every step reads the same instance instead of creating a second one.

import { createContext, useContext, type ReactNode } from 'react';
import {
  useFieldArray,
  useFormContext,
  type UseFieldArrayReturn,
} from 'react-hook-form';

const ItemsContext = createContext<UseFieldArrayReturn | null>(null);

export function ItemsProvider({ children }: { children: ReactNode }) {
  const { control } = useFormContext();

  // The ONLY useFieldArray('items') in the tree.
  const fieldArray = useFieldArray({ control, name: 'items' });

  return (
    <ItemsContext.Provider value={fieldArray}>{children}</ItemsContext.Provider>
  );
}

export function useItems() {
  const ctx = useContext(ItemsContext);
  if (!ctx) throw new Error('useItems must be used inside <ItemsProvider>');
  return ctx;
}

Now every step consumes the same instance:

function StepTwo() {
  const { fields, append } = useItems();
  return (
    <>
      {fields.map((f, i) => <ItemRow key={f.id} index={i} name={`items.${i}`} />)}
      <button type="button" onClick={() => append({ sku: '', method: 'pickup' })}>
        Add item
      </button>
    </>
  );
}

function StepFour() {
  // Same array, same snapshot — because it is literally the same instance.
  const { fields, remove } = useItems();
  return (
    <ul>
      {fields.map((f, i) => (
        <li key={f.id}>
          {f.id} <button type="button" onClick={() => remove(i)}>×</button>
        </li>
      ))}
    </ul>
  );
}

The detail that decides whether this works

The provider must be mounted above the step switch, not inside it.

// ✅ survives step changes
<FormProvider {...methods}>
  <ItemsProvider>
    {step === 2 && <StepTwo />}
    {step === 4 && <StepFour />}
  </ItemsProvider>
</FormProvider>

// ❌ remounts on every step change — you are back where you started
<FormProvider {...methods}>
  {step === 2 && <ItemsProvider><StepTwo /></ItemsProvider>}
  {step === 4 && <ItemsProvider><StepFour /></ItemsProvider>}
</FormProvider>

If the provider unmounts, the field array unmounts with it, and the second mount is a brand-new instance with a fresh snapshot. Which is the original bug, reintroduced by the fix.

It works. It is also a piece of state architecture you now own and maintain — in a library you adopted specifically so you would not have to.

Where we stand

I maintain a form orchestrator built on top of react-hook-form, so it would be a strange article to end with a pitch. Our own useDashFieldArray does not solve this either.

It is a thin adapter: it pre-computes the field path and exposes a live index, then delegates every operation straight through to RHF.

const { fields, append, remove } = useDashFieldArray<Item>('items');

fields.map((field) => (
  <TextField key={field.id} name={`${field.name}.sku`} />
));

Better DX — you stop hand-building items.${index}.sku strings — but two instances on the same name behave exactly as RHF's do, because underneath they are RHF's. Fixing this properly means owning array state centrally, which is a different architecture, not a wrapper.

So the honest summary for today:

Conditional fields inside an array → solved, use useWatch at the component level.
One array shared across wizard steps → not solved upstream. Own a context, and mount it above the steps.

If someone has a third pattern that holds up in production, I would genuinely like to see it.

Sources

react-hook-form — useFieldArray documentation the quoted rule
react-hook-form — useWatch documentation

This is part of Fault Lines, a set of open fronts in the React form ecosystem, each traced to primary sources and dated.

Dashforge: an application orchestrator for React

kensaadi — Thu, 20 Aug 2026 06:52:28 +0000

React solved rendering. Dashforge tries to solve orchestration — theming, forms,
permissions, and visibility moved out of your components, declaratively, predictably,
reusably. Two skins (MUI and Tailwind), one contract.

Building complex applications isn't about building components.

Inside a single module you're juggling forms, permissions, roles, visibility conditions, fields that depend on other fields, business logic. And all that logic ends up scattered across the app: a <Controller> here, an if (user.role === …) there, a useEffect watching one field to update another, a context for theming.

If React solves the rendering problem, Dashforge tries to solve the orchestration problem.

Dashforge moves that complexity out of the components and makes it declarative, predictable, and reusable. At its core it uses react-hook-form; on top of it, a stable contract — identical across the MUI and Tailwind editions. Let's go through it piece by piece.

1. Theming — token-first, build-time and run-time

Components don't hard-code colors or spacing: they consume typed design tokens (@dashforge/tw-tokens, a pure TypeScript package, zero runtime). From there, the tokens travel on two rails.

Build-time — the utilities. A Tailwind preset emits the usual utilities (bg-primary-600, text-neutral-900):

// tailwind.config.ts
import { dashforgePreset } from '@dashforge/tw-theme';
export default { presets: [dashforgePreset()], content: ['./src/**/*.{ts,tsx}'] };

Run-time — the CSS variables. The provider republishes those same tokens as CSS variables on <html>:

<DashforgeTailwindProvider>
  <App />
</DashforgeTailwindProvider>

Here's the trick: bg-primary-600 doesn't resolve to a fixed color — it resolves to var(--tw-color-primary-500). The provider sets that variable; change the variable, the color changes — no re-render, no Tailwind rebuild. The store is reactive (Valtio) with cross-tab sync, so dark mode or a live theme change is just a variable flip.

In the MUI edition the same token surface feeds a runtime MUI theme (via Emotion): same source of truth, only the delivery differs.

Concrete payoffs: dark mode is free (components don't even know it exists), a redesign is a token change rather than a sweep across a hundred files, and the design system is typed instead of being a convention your team has to remember.

2. Forms — declarative orchestration

If you use react-hook-form (and you should), you know the tax: a <Controller> for every field, and a handful of watch / useWatch / useEffect scattered through the component to react to values.

// Plain RHF — same pattern, every field, every form
<Controller
  name="email"
  control={control}
  rules={{ required: 'Email is required' }}
  render={({ field, fieldState }) => (
    <TextField {...field} label="Email"
      error={!!fieldState.error}
      helperText={fieldState.error?.message} />
  )}
/>

With Dashforge the field is bound by name to the form. Binding, errors, "touched" state: inside the component.

<TextField name="email" label="Email" rules={{ required: 'Email is required' }} />

Per-field subscriptions → fewer re-renders than plain RHF, zero <Controller> at the call site. And this pattern is native to both CSS libraries: if you build admin apps all day, that alone is a reason to adopt it.

2.1 Reactions — logic outside the render

The real case: fields that depend on other fields. In an e-commerce app you pick a category and the right subcategories must appear, loaded from an API. With RHF you end up with useEffect + local state + cleanup + race-condition handling, all inside the component.

Dashforge declares it outside the render, in a reaction:

const reactions = [{
  id: 'load-subcategories',
  watch: ['category'],                 // the same "watch" as react-hook-form — not by accident
  run: async (ctx) => {
    const category = ctx.getValue('category');
    if (!category) return;

    const req = ctx.beginAsync('subs');                  // stale-response guard
    ctx.setRuntime('subcategory', { status: 'loading' });

    const options = await fetchSubcategories(category);  // external fetch, stays out of render

    if (ctx.isLatest('subs', req)) {                     // drop out-of-order responses
      ctx.setRuntime('subcategory', { status: 'ready', data: { options } });
    }
  },
}];

The reaction declares what happens between fields. The fetch never enters the render; the data lives only inside the reaction. And the classic race condition ("the user already changed the value but the previous response just arrived") is handled by beginAsync / isLatest, not hand-written.

When the form mounts, React takes over — reactions attach via a prop:

<DashForm
  defaultValues={{ category: '', subcategory: null }}
  reactions={reactions}
  onSubmit={save}
>
  <Select name="category"    label="Category" options={CATEGORIES} />
  <Select name="subcategory" label="Subcategory" /> {/* options populated by the reaction */}
</DashForm>

A few lines orchestrate a form that would take real effort to build by hand.

3. RBAC — permissions as data, not as `if`

In an enterprise app, "who can do what" isn't a UI decision: it's a rule that comes from the backend. The problem is that it usually gets re-translated by hand into dozens of scattered if (user.role === 'admin'). Dashforge keeps it in one place and lets components apply it. Three pieces.

3.1 Policy — what's allowed

An object of roles and permissions (action + resource + effect). In production you fetch it from your backend (JWT claims, a /me/policy endpoint), you don't hand-write it in the client:

import { RbacProvider, type RbacPolicy } from '@dashforge/rbac';

const policy: RbacPolicy = {
  roles: [
    { name: 'admin',  permissions: [{ action: '*',    resource: '*',       effect: 'allow' }] },
    { name: 'editor', permissions: [{ action: 'edit', resource: 'booking', effect: 'allow' },
                                    { action: 'read', resource: 'booking', effect: 'allow' }] },
    { name: 'viewer', permissions: [{ action: 'read', resource: 'booking', effect: 'allow' }] },
  ],
};

3.2 RbacProvider — who you are (the link to authentication)

The provider takes the policy and the subject: the current user with their roles — also coming from your authentication system. This is where RBAC connects to the user's real identity. It mounts once, at the top of the app:

function App() {
  const currentUser = { id: 'user-123', roles: ['editor'] }; // from your auth / backend

  return (
    <RbacProvider policy={policy} subject={currentUser}>
      <BookingForm />
    </RbacProvider>
  );
}

From here on, every component "knows" who the user is and what they're allowed to do.

3.3 access — how permissions propagate to components

Each component declares which resource/action it needs and what to do when the permission is missing (hide / disable / readonly). The object is inline, so you see exactly what's in it.

<DashForm defaultValues={{ customerName: '', status: 'pending' }} onSubmit={save}>
  {/* viewer → read-only · editor/admin → editable */}
  <TextField
    name="customerName"
    label="Customer name"
    access={{ action: 'edit', resource: 'booking', onUnauthorized: 'readonly' }}
  />

  {/* disappears entirely if you can't delete */}
  <Button access={{ action: 'delete', resource: 'booking', onUnauthorized: 'hide' }}>
    Delete booking
  </Button>
</DashForm>

The provider resolves access against the policy and the subject: change the user's role and the same form re-resolves itself — admin sees and edits everything, editor loses the admin-only fields, viewer gets a read-only name and no Save button. No if in the JSX, no permission logic duplicated page by page. And the access declaration is identical in the MUI and Tailwind editions.

4. visibleWhen — the end of scattered conditional rendering

visibleWhen is a reactive visibility predicate: return false and the component renders null. It lives in two contexts.

Inside a form — on the engine. It reaches the form engine directly and reads a field's value:

<Select
  name="subcategory"
  label="Subcategory"
  visibleWhen={(engine) => Boolean(engine.getValue('category'))}
/>

Outside a form — on state. It captures local/external state in the closure: the component decides for itself whether to show up, without the classic {condition && <Component/>} cluttering your JSX. Many display-only components expose it precisely for this.

<Alert visibleWhen={() => hasUnsavedChanges}>You have unsaved changes</Alert>

Either way, the condition is a declared property of the component, not a rendering branch you repeat by hand.

Wrapping up

There's a single thread: what are usually scattered imperative functions — <Controller>, useEffect, permission ifs, dark: variants, conditional rendering — become declarative properties of forms, components, and schema in Dashforge. Readable, testable, reusable. And because everything flows through the shared bridge, the same schema runs identically on MUI and Tailwind: you only change the import line.

import { TextField, Select, Button } from '@dashforge/tw';   // Tailwind
// import { TextField, Select, Button } from '@dashforge/ui'; // MUI

Who it's for: React/TypeScript teams, enterprise and fintech applications, back offices, complex dashboards, products with heavy business logic. If you're building a small app or a landing page, Dashforge probably won't help you — and that's fine.

Try it without installing dependencies — the CLI ships two templates, landing or dashboard:

npx dashforge-cli my-app --lib tw   # or --lib mui
cd my-app && pnpm dev

📚 Docs, live demos, and repo: https://dashforge-ui.com

If you build data-driven apps in React, the one question I care about: would orchestrating forms, permissions, and dependencies outside your components make you adopt Dashforge? Let me know in the comments — that's the feedback that steers the roadmap.

I gave Tailwind typed props. Then it ate React Hook Form.

kensaadi — Fri, 19 Jun 2026 17:31:59 +0000

I spent years thinking my React forms were a CSS problem.

They weren't. They were a wiring problem — and I'd been paying for it on every single field, in every single project.

This is the story of how questioning one small thing — why is styling hidden inside strings? — led me somewhere I didn't expect: to components that already know what form they live in, who's allowed to use them, and when they should exist at all.

It started with className

Like most React developers, I've written this code thousands of times:

<div className="flex items-center justify-between gap-4 p-4 rounded-xl bg-white">

There's nothing wrong with Tailwind. It solved a real category of problems that hand-written CSS created — naming, dead styles, cascade surprises. I'm not here to relitigate that. I reach for it on every project.

But after years of building business apps, one thing kept nagging me.

React is built around props. Everything is a prop. Except styling — layout, spacing, color, visual state — which lives inside one big opaque string. No autocomplete. No type-checking. No refactor safety. The compiler has no idea what's in there.

So I asked a dumb question:

What would Tailwind components look like if every utility that mattered were a typed prop instead of a substring?

Props-first, on top of Tailwind

Instead of a className soup, I wanted the visual API to be the type system:

<Button variant="solid" color="primary" size="md">
  Save
</Button>

variant, color, size — autocompleted, type-checked, self-documenting. Behind the scenes each one still resolves to plain Tailwind utility classes (compiled with tailwind-variants), and every color and spacing value comes from design tokens wired into the Tailwind config through a preset — not magic numbers, the same scale across the whole system.

className isn't even on the component. There's exactly one override path: an sx escape hatch, where tailwind-merge guarantees your utility wins over the variant's. One way in, no specificity roulette.

Under the hood the interactive primitives are Radix (and React Aria for the hard ones), so accessibility, focus management, and keyboard behavior aren't something I reinvented badly at 11pm.

"Wait, this is just Chakra / MUI's sx."

Fair — props-first styling isn't a new idea, and I'm not going to pretend I invented it. But there's a real difference: this is build-time Tailwind utilities over headless Radix primitives, not a runtime CSS-in-JS engine. Dark mode is a CSS-variable swap from a theme layer — the same class resolves to a different value when a data- attribute flips, no dark: explosion in every recipe.

And honestly? The styling was never the interesting part. It was just the door.

Then React Hook Form happened

The first real app exposed the actual problem.

A typical RHF field looks like this:

<Controller
  name="email"
  control={control}
  render={({ field, fieldState }) => (
    <>
      <input {...field} />
      {fieldState.error && <p>{fieldState.error.message}</p>}
    </>
  )}
/>

Nothing wrong with it. But by your 50th field, the shape is undeniable. Controller, render prop, field wiring, error wiring — copy, paste, again. And again. And again.

So I asked the next dumb question: why does every developer manually re-connect every field to the form?

What if the component already understood forms?

<TextField name="email" label="Email" />
<PasswordField name="password" label="Password" />

No Controller. No render prop. No error plumbing. The field reads its value, validation state, and error directly from a form bridge via context — and it errors only after blur or submit, so you don't get red text screaming at someone mid-keystroke.

This is where I stopped thinking I'd rebuilt Tailwind. The real cost in business UIs was never CSS or even rendering. It was orchestration — the glue wiring everything to everything else.

Fields that know when they exist

Every app eventually grows dependent fields:

const customerType = watch("customerType");

useEffect(() => {
  if (customerType !== "business") setValue("vatNumber", "");
}, [customerType]);

A watch, a conditional render, a cleanup effect — per rule, times hundreds of rules. That's not business logic. It's plumbing.

What if the field described its own condition?

<TextField
  name="vatNumber"
  visibleWhen={{ field: "customerType", equals: "business" }}
/>

No watch. No effect. No manual reset. The field already knows when it should be on screen — and the engine handles the teardown.

Buttons that know who's allowed to press them

Same story with permissions, scattered across every screen:

{permissions.includes("invoice:update") && <button>Save</button>}

Why is that check outside the component? Why doesn't the button know who can use it?

<Button access="invoice:update">Save</Button>

The rule lives where it matters — on the node itself. Unauthorized can mean hide, disable, or readonly, your call. The permission logic stops being a render-time && smeared across the codebase.

The part I didn't plan

Here's the reveal, and it's the bit I'm actually proud of.

There are two component libraries: one rendered with MUI, one rendered with Tailwind + Radix. Same component names, same orchestration props — name, visibleWhen, access — different pixels.

They share zero styling code.

What they do share is one headless engine: the form bridge, the visibility engine, the RBAC layer. The application-awareness — what a field knows about the app it lives in — is a separate, framework-agnostic core. The styling layer is swappable. The intelligence underneath is not.

That's when it clicked. I wasn't building UI components anymore. I was building application-aware components — things that understand styling, forms, validation, visibility, and permissions, not because they contain business logic, but because they understand how they participate in an application.

Where this lives

This is DashForge — React + MUI + React Hook Form + Tailwind CSS, with the Tailwind track (@dashforge/tw) built on Radix and tailwind-variants. It's an early alpha; the core architecture is already running in real apps, the API surface is still settling.

If the orchestration idea resonates — if you've also written the same watch / useEffect / permission check for the hundredth time — the repo is here:

👉 https://github.com/kensaadi/dashforge
👉 https://dashforge-ui.com/tw

A star helps me gauge whether to keep pushing this. And I'd genuinely like to hear how you deal with form orchestration at scale — drop it in the comments.

Production RBAC patterns for Go and Node startups

kensaadi — Wed, 17 Jun 2026 09:56:56 +0000

A founder told me last year:

"We need admin features shipped by Friday. Can we just hardcode the roles for now?"

That was 7 months ago. They're still paying for that decision today.

This article is the breakdown I wish I had given them before that Friday — the patterns that separate a quick MVP version of RBAC from one that won't bite you back in six months.

If you're a startup CTO, technical founder, or senior engineer about to ship admin/dashboard features for the first time, this is for you.

The 4 signs your RBAC is a time bomb

I've reviewed this exact pattern in 5+ early-stage codebases. Every one of them eventually hit the wall. Look for these signs:

1. Roles hardcoded in the JWT

{
  "sub": "user_123",
  "role": "admin"
}

Simple. Until you need to:

Add a new role → migration + token refresh strategy
Give one user a temporary elevated permission → "we'll just reissue tokens"
Audit who had admin last month → good luck

2. Permission checks scattered across 40+ controllers

// In every single handler:
if user.Role != "admin" {
    return c.Status(403).JSON(...)
}

By the time you have 30 endpoints, you've made the same mistake 30 times. Refactoring is a full sprint.

3. One admin superuser that can do everything

Until a sales rep accidentally deletes a customer record because they were elevated to admin "just for that one task last week."

4. Zero audit trail

When the data goes missing, your only investigative tool is git blame on the source code and a desperate grep through CloudWatch logs.

If you've nodded at any of these — keep reading.

The real problem: policies-as-code

Most teams treat permissions like business logic. They live in source files, gated by if statements, deployed with the rest of the code.

This is the original sin.

Code changes need deploys. Permissions change daily.

When marketing onboards a new role next quarter, when a customer success rep needs view-only access to billing, when legal asks "who could have read this customer's data on Tuesday at 3pm?" — every one of these requires a permission change. If permissions live in code, every one of these requires a deploy.

Production RBAC starts with one shift in mental model: permissions are data, not code.

Three rules for production-grade RBAC

Rule 1: Policy-as-data, not policy-as-code

Policies live in your database. Source code only knows how to check them, not define them.

A reasonable schema (Postgres flavor, equivalent in MongoDB):

-- Roles
CREATE TABLE roles (
  id         SERIAL PRIMARY KEY,
  name       TEXT UNIQUE NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Permissions (action on resource)
CREATE TABLE permissions (
  id         SERIAL PRIMARY KEY,
  resource   TEXT NOT NULL,   -- e.g., "orders", "customers"
  action     TEXT NOT NULL,   -- e.g., "read", "delete"
  UNIQUE (resource, action)
);

-- Role <-> Permission mapping
CREATE TABLE role_permissions (
  role_id        INTEGER REFERENCES roles(id),
  permission_id  INTEGER REFERENCES permissions(id),
  PRIMARY KEY (role_id, permission_id)
);

-- User <-> Role mapping
CREATE TABLE user_roles (
  user_id  INTEGER REFERENCES users(id),
  role_id  INTEGER REFERENCES roles(id),
  PRIMARY KEY (user_id, role_id)
);

In MongoDB the same idea is one document per role:

{
  "_id": "sales",
  "permissions": [
    { "resource": "customers", "action": "read" },
    { "resource": "orders",    "action": "read" },
    { "resource": "orders",    "action": "create" }
  ],
  "updatedAt": "2026-06-10T14:00:00Z"
}

The difference: now you change a permission with UPDATE, not with git push.

Rule 2: Granular permissions (action-level, not role-level)

The wrong abstraction is role === permission. The right abstraction is permission === (resource, action).

Bad:

if user.Role == "admin" { /* do everything */ }

Good:

if user.Can("orders", "delete") { /* delete the order */ }

The Can() function looks up: does this user, through any of their roles, have the permission (orders, delete)? Cache it per-request with the user's permission set loaded once on auth.

This means:

New permission? Insert one row. No deploy.
Promote a role? Add a row to role_permissions. No deploy.
Demote a user? Remove a row from user_roles. No deploy.

Rule 3: Audit trail — non-negotiable

Every sensitive action logs to an append-only table:

CREATE TABLE audit_log (
  id         BIGSERIAL PRIMARY KEY,
  actor_id   INTEGER REFERENCES users(id),
  action     TEXT NOT NULL,              -- e.g., "order.delete"
  resource   TEXT NOT NULL,              -- e.g., "orders/42"
  before     JSONB,                      -- snapshot before
  after      JSONB,                      -- snapshot after (NULL for delete)
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

Append-only. No UPDATE, no DELETE. When the customer record disappears, you have a complete trail of who, when, and what changed.

This sounds like overhead until the first time you need it. Then it's the cheapest insurance you ever bought.

RBAC vs ABAC vs ReBAC: which one do you need?

A quick decision tree:

Plain RBAC — most startups need this and nothing more.

Users have roles. Roles have permissions. Done.

ABAC (Attribute-Based Access Control) — only if your access depends on attributes of the request, not just the user.

"Sales reps can only see customers in their region"
"This document is editable only during business hours"
ABAC adds policy engines and complexity. Skip unless required.

ReBAC (Relationship-Based, Zanzibar-style) — only for sharing/multi-tenant graphs.

"User A shared this document with User B who shared a folder with Team C"
Google Docs, Notion, Figma need this. Your B2B SaaS probably doesn't.

If you're not sure — start with RBAC + audit log. You can always layer ABAC on top later.

A concrete implementation walkthrough

Here's the minimal viable production-grade RBAC in real code.

Go middleware (Fiber)

package middleware

import (
    "github.com/gofiber/fiber/v2"
)

type PermissionChecker interface {
    Can(userID int, resource, action string) (bool, error)
}

func RequirePermission(checker PermissionChecker, resource, action string) fiber.Handler {
    return func(c *fiber.Ctx) error {
        userID := c.Locals("user_id").(int)

        allowed, err := checker.Can(userID, resource, action)
        if err != nil {
            return c.Status(500).JSON(fiber.Map{"error": "permission check failed"})
        }
        if !allowed {
            return c.Status(403).JSON(fiber.Map{"error": "forbidden"})
        }
        return c.Next()
    }
}

// Usage in routes:
// app.Delete("/orders/:id",
//     RequirePermission(permChecker, "orders", "delete"),
//     handlers.DeleteOrder)

The middleware is stateless about which roles exist. It just asks: "can this user do this action on this resource?" The answer comes from the DB.

Node middleware (Express)

// middleware/requirePermission.js
function requirePermission(checker, resource, action) {
  return async (req, res, next) => {
    try {
      const allowed = await checker.can(req.user.id, resource, action);
      if (!allowed) {
        return res.status(403).json({ error: 'forbidden' });
      }
      next();
    } catch (err) {
      return res.status(500).json({ error: 'permission check failed' });
    }
  };
}

module.exports = requirePermission;

// Usage:
// router.delete('/orders/:id',
//   requirePermission(permChecker, 'orders', 'delete'),
//   handlers.deleteOrder);

Same pattern, different language. The permission set is loaded once at login and cached on the user session — checker.can() is an in-memory lookup against a Set per request.

Frontend gating: where most teams stop too early

Most articles end here with a one-component <Can> example and a "server-side check is the source of truth" disclaimer. That's correct, but it's the bare minimum of what production RBAC needs on the frontend.

A real RBAC layer on the frontend has at least 5 concerns:

Hook-level access — read user permissions anywhere without prop drilling
Inline gating — show/hide buttons, columns, table actions
Route-level gating — block entire pages, redirect unauthorized users
Admin UI — non-engineers need to view/edit roles and permissions
Audit visibility — someone needs to read the audit log without DB access

Skip any of these and you'll re-invent them six months later. Here's the shape they should have.

1. The hook

// useAuth() returns user + a Set of permission keys
const { user, permissions } = useAuth();

// usePermissions() is a focused alias when you don't need user data
const permissions = usePermissions();

permissions.has('orders:delete');  // true | false
permissions.canAny(['orders:delete', 'orders:archive']);
permissions.canAll(['customers:read', 'customers:update']);

The permission set is loaded once on auth, cached in React context, and every check is O(1).

2. Inline gating with `<Can>`

<Can resource="orders" action="delete">
  <DeleteButton onClick={handleDelete} />
</Can>

// With a fallback (shows a disabled button + tooltip instead of hiding)
<Can
  resource="orders"
  action="delete"
  fallback={<DisabledButton tooltip="You don't have permission to delete orders" />}
>
  <DeleteButton onClick={handleDelete} />
</Can>

// With multiple permissions (any of these is enough)
<Can anyOf={["orders:delete", "orders:archive"]}>
  <DangerActions />
</Can>

The fallback prop is the key detail most implementations miss. Hiding a button creates a worse UX than showing it disabled with a "why you can't" tooltip — users feel less broken when they know the rule exists.

3. Route-level gating with `<RoleGuard>`

// Inside the router
<Route
  path="/admin/orders"
  element={
    <RoleGuard
      anyOf={["orders:read"]}
      fallback={<ForbiddenPage />}
      redirect="/dashboard"
    >
      <OrderManagementPage />
    </RoleGuard>
  }
/>

Whole pages refuse to render. Better than letting the user load the page and then erroring on every API call.

4. The admin UI — the part nobody writes themselves

This is where DIY RBAC implementations fall apart. Engineers build the middleware and the hook and stop. Then someone in product asks: "Can sales also export customers?" and the answer is: "Sure, I'll deploy that change next week."

A real admin UI lets non-engineers:

See the role × permission matrix (the same diagram everyone draws on a whiteboard)
Toggle permissions per role with a click
Assign users to roles
See the audit log filterable by actor, action, date range, IP

This is what an <PermissionMatrix> admin component looks like from the consumer side:

<PermissionMatrix
  roles={roles}                  // ["customer", "sales", "admin"]
  resources={resources}          // ["orders", "customers", "products"]
  actions={["read", "create", "update", "delete"]}
  value={currentPolicy}          // current role × permission map
  onChange={handlePolicyChange}  // saves to DB, no deploy
  readonly={!permissions.has('admin:manage_roles')}
/>

Behind it: the same roles / permissions / role_permissions tables from Rule #1. Edits hit the DB directly. No code change, no deploy, no engineer in the loop.

5. The audit log viewer

<AuditLogViewer
  filters={{
    actor: userId,
    actionPrefix: "order.",       // "order.delete", "order.update", etc.
    dateRange: last30Days
  }}
  columns={["actor", "action", "resource", "before", "after", "ip"]}
  exportable                     // CSV export for compliance reviews
  paginate
/>

When the data goes missing or the auditor asks who did what, you don't psql into prod. You filter the UI.

Audit logging in two lines

Wrap your mutation handlers with a logger:

func DeleteOrder(c *fiber.Ctx) error {
    orderID := c.Params("id")
    order, _ := db.GetOrder(orderID)

    if err := db.DeleteOrder(orderID); err != nil {
        return err
    }

    audit.Log(c.Locals("user_id").(int), "order.delete",
        "orders/"+orderID, order, nil, c.IP(), c.Get("User-Agent"))

    return c.SendStatus(204)
}

Same pattern in Node. The audit log table is append-only. Months from now, when something disappears, you'll have the full trail.

The RBAC layer in Dashforge — what end-to-end actually looks like

Everything above — the schema, the middleware, the hooks, the components, the admin UI — is the actual design of the RBAC layer in Dashforge.

The reason this article exists is that every piece of this puzzle is usually built separately by separate teams, in different shapes, with different bugs. The middleware is in one repo, the React <Can> is invented case-by-case, the audit log is "TODO for next sprint", the admin panel never gets built. Six months later you have four half-finished RBAC systems that don't talk to each other.

Dashforge ships them as one coherent layer:

The full stack, day-1 ready

┌──────────────────────────────────────────────────────────────────┐
│  Admin UI (React)                                                 │
│  ── PermissionMatrix   roles × actions toggle grid                │
│  ── UserRolesEditor    assign/revoke roles per user               │
│  ── AuditLogViewer     filter, search, CSV export                 │
└─────────────────┬────────────────────────────────────────────────┘
                  │ same auth context, same permission set
┌─────────────────▼────────────────────────────────────────────────┐
│  React components                                                 │
│  ── useAuth()  /  usePermissions()  /  <Can>  /  <RoleGuard>      │
│  Available in BOTH Tailwind and MUI flavors                       │
└─────────────────┬────────────────────────────────────────────────┘
                  │ HTTP, JWT carries user_id only
┌─────────────────▼────────────────────────────────────────────────┐
│  Backend middleware                                               │
│  ── Go (Fiber) and Node (Express) — same contract                 │
│  ── RequirePermission(resource, action)                           │
│  ── Audit log middleware (auto-wraps mutations)                   │
└─────────────────┬────────────────────────────────────────────────┘
                  │
┌─────────────────▼────────────────────────────────────────────────┐
│  Database (MongoDB, Postgres-ready via provider pattern)          │
│  ── roles, permissions, role_permissions, user_roles, audit_log   │
└──────────────────────────────────────────────────────────────────┘

Single source of truth — the database. Every layer reads from the same tables. You change a permission once, the change propagates automatically:

Middleware blocks unauthorized requests
React <Can> hides UI accordingly
Audit log records everything
Admin panel reflects the new state

No code changes anywhere. No deploy.

What you get on day 1

When you open the checkout-kit, the RBAC layer is already wired up with three working roles and the full admin UI:

Backend (Go or Node — pick one):

RequirePermission(resource, action) middleware wrapping every protected route
PolicyChecker service that loads user permissions on auth, caches them per session
Audit logger that wraps mutation handlers automatically (no per-handler boilerplate)
REST endpoints for /admin/roles, /admin/permissions, /admin/users/:id/roles, /admin/audit-log

Frontend (Tailwind OR MUI flavor — both shipped):

<AuthProvider> initialized in your root component
useAuth() and usePermissions() hooks ready to import
<Can> with fallback, anyOf, allOf props — the full API documented above
<RoleGuard> for route-level protection (drop-in for React Router)
<PermissionMatrix> admin component — pre-styled, pre-wired to the API
<UserRolesEditor> — searchable user list with role assignment
<AuditLogViewer> — filterable, exportable, paginated

Three roles, pre-seeded:

customer — read their own orders, update their own profile
sales — read/create/update orders and customers, no delete
admin — everything, plus role/permission management

Extending to a fourth role is one row in the roles table and a few clicks in the admin UI. No code change required.

Why bundling matters

You can build all of this yourself. Here's the realistic timeline I've seen in startups:

Component	Time to build properly (mid-senior engineer)
DB schema + migrations	4-6 hours
Middleware Go + Node	6-10 hours
React hooks + Context	4-6 hours
`<Can>` + `<RoleGuard>` with edge cases	6-10 hours
`<PermissionMatrix>` admin UI	16-24 hours
`<UserRolesEditor>` with search/pagination	8-16 hours
`<AuditLogViewer>` with filters/export	12-20 hours
Audit middleware + before/after snapshot logic	8-12 hours
End-to-end tests, documentation, bugfixes	16-24 hours
Total realistic	80-130 hours (2-3 weeks)

That's not counting design iterations, the inevitable "wait, we forgot about row-level permissions" mid-sprint, or onboarding a new engineer who needs to understand all of it.

Dashforge ships it all on day 1, in your repo, code you own. You modify it freely. There's no SaaS subscription, no vendor lock-in, no monthly fee. Buy it once, deploy it forever.

How it composes with the rest of the kit

The checkout-kit isn't just RBAC. The same auth + permission layer also powers:

Stripe checkout flow — pricing tiers gated by role (admin sees test-mode toggles, customer sees buy CTAs only)
Product catalog — sales can create products, customer can only browse
Order management — full CRUD for admin/sales, read-only for customer
Multi-tenant ready — extend the policy with a tenant_id column and you have row-level security
Stripe webhook handlers — already protected with API-key auth, audit logged

The whole thing is one repo, one auth model, one permission set. Not five disconnected libraries glued together with hope.

If you're about to start building this from scratch — pause and take a look at the kit. You'll save 2-3 weeks of work and get a layer that's already been thought through. Drop a comment if you want me to share more on a specific piece (the schema migrations, the audit log middleware, the admin UI patterns).

Your turn

If you've shipped RBAC in production recently, I'd love to hear what tradeoffs you made:

Did you build from scratch, or use a library (Casbin, Oso, Permify)?
ABAC, ReBAC, or plain RBAC + audit?
What's the one thing you'd do differently?

Drop a comment — I'm collecting patterns for a follow-up piece on RBAC at scale (10K+ users, multi-tenant).

If you found this useful and want more deep-dives on Go/Node infrastructure patterns for startups, follow me here on dev.to.

DEV Community: kensaadi

A cantonal parliament asked for one shared taxi dispatch. The government answered that it is the operators' business

What else it asks

The government's answer, and the line that counts

Ten years, same place

A note on sourcing

What is left, and to whom

Paris announced its robotaxi consortium. None of the three signatories runs vehicles today

Who does what

What the announcement does not say

The map is drawn by two of them

The pattern, which is already decided

A Munich taxi company wants 500 robotaxis under its own brand, and on paper that is the opposite model

How they tell it

Why it is different from everything else

Two models on the table, four days apart

What to watch

Lavoro su piattaforma e algoritmi: cosa cambia con la direttiva europea per chi progetta il software

Switzerland withdrew the reform that would have made a normal driving licence enough to carry passengers

What would have gone

Why it stopped

Where it came from, and why that is ironic

What this is not

What is left on the table

Your UI config quietly became a programming language. Here's the fix

The one rule: describe the screen, not the behavior

The render pipeline (no eval, ever)

The escape hatch: custom nodes

RBAC and visibility as data (shared front and back)

Where Blueprint sits (and where it does not)

Builder: author the contract visually

Try it

RBAC in React and Node: enforce the same policy on both sides

The UI is an affordance, the server is the boundary

One policy, as data

The server: the boundary

The UI: the affordance, from the same policy

Ownership: "their own", not "any"

The honest part

The checklist

Availability slots across timezones and DST

"09:00" is not an instant

The bug: computing slots in UTC (or the server's clock)

Prove it: 09:00 in Paris in August is 07:00 UTC

The spring-forward day

Store UTC, compare on instants, render local

The checklist

useFieldArray is not updating across steps — and why it can't

Why the rule exists

The three shapes where it bites

Fix 1 — conditional fields: subscribe narrowly with useWatch

Fix 2 — sharing one array across steps: own the context

The detail that decides whether this works

Where we stand

Sources

Dashforge: an application orchestrator for React

1. Theming — token-first, build-time and run-time

2. Forms — declarative orchestration

2.1 Reactions — logic outside the render

3. RBAC — permissions as data, not as if

3.1 Policy — what's allowed

3.2 RbacProvider — who you are (the link to authentication)

3.3 access — how permissions propagate to components

4. visibleWhen — the end of scattered conditional rendering

Wrapping up

I gave Tailwind typed props. Then it ate React Hook Form.

It started with className

Props-first, on top of Tailwind

Then React Hook Form happened

Fields that know when they exist

Buttons that know who's allowed to press them

The part I didn't plan

Where this lives

Production RBAC patterns for Go and Node startups

The 4 signs your RBAC is a time bomb

The real problem: policies-as-code

Three rules for production-grade RBAC

Rule 1: Policy-as-data, not policy-as-code

Rule 2: Granular permissions (action-level, not role-level)

Rule 3: Audit trail — non-negotiable

3. RBAC — permissions as data, not as `if`

2. Inline gating with `<Can>`

3. Route-level gating with `<RoleGuard>`