Production-grade enterprise
plumbing for Laravel apps.
Time-aware authorization, a lightweight enterprise shell, scoped settings, and partners modeled on SAP's Business Partner. The six months of plumbing you'd rather not build.
Your client expects enterprise software. Your timeline says otherwise.
Your team quoted twelve weeks.
The client expects roles, permissions, and audit trails that actually hold up. Building authorization alone could eat half that timeline.
The business side wants Enterprise UX — something that looks and feels like SAP.
The people who need it don't have SAP licenses, and off-the-shelf admin panels don't come close.
Customer one works. Customer two breaks everything.
Your second customer needs a separate environment. Suddenly you're rebuilding infrastructure instead of selling.
Six months in, the plumbing still isn't done.
Every feature request waits behind authorization fixes, shell bugs, and integration work nobody scoped.
These aren't technical problems. They're business risks.
The SDK removes them on day one.
What ships between describe and production
Nine capabilities your team would otherwise build from scratch. Each one is months of senior engineering. Together they turn your Laravel app into enterprise software.
Time-Aware Authorization
Permissions that expire on schedule.
Every role assignment carries a start and end date. Auditors can ask "who had access to what on March 15th?" and get a definitive answer. No custom expiry logic, no cleanup scripts, no guesswork.
LeanShell
An enterprise UI your client will recognize.
Navigation, search, help, dashboards, and cross-module dialogs in one consistent shell. Your users see a professional application from day one, not a collection of screens stitched together.
Business Partners
Customers, vendors, contacts in one model.
The same business partner concept SAP uses, built for Laravel. Authorization runs on partners, not on user accounts. A Partners app ships with the SDK, ready to use.
Scoped Settings
Configuration that respects hierarchy.
User overrides Site, Site overrides Tenant, Tenant overrides Installation, Installation overrides Platform. One API resolves them all. A Settings app ships with the SDK so your users manage their own preferences without filing tickets.
Intent-Based Navigation
Navigate by meaning, not by URL.
Modules declare the business concepts they own and the front door to each; other modules weave links to them — across vendors, through LUX Weave. Install a module and its doorways appear. No routing tables to update, no menus to maintain.
Drop-In Modules
Install a package, gain a feature.
A module ships as a Composer package. Install it, list it in config/ui5.php, run ui5:sync — and your application has new capabilities. No integration sprint.
Tenant-Aware
Every request knows its tenant.
Your app runs inside its own booted tenant from day one. The resolver seam is the SDK's, with no convention to maintain. Operating many of them is the operational layer on top. Roll your own on the open seam, or take ours: Platform, which we build with you.
Help System
Documentation your users actually find.
Help topics live next to the code they describe, compile at build time, and attach to the UI element they document. Full-text search runs in the browser. When you refactor, the help moves with the code.
Developer Experience
Twelve artisan commands. One test DSL. Zero guesswork.
Sync metadata, explain authorization decisions, compile help, build the navigation. The scenario DSL tests your real authorization engine against a real database. What the CLI says is what production sees.
Your auditor asks. You answer.
Three capabilities that turn authorization from "we think it works" into "we can prove it works."
Audit-ready authorization
Your client asks who had access to what, when, and why. One command, full attribution, no forensics. The same engine that enforces permissions at runtime produces the audit trail.
$ php artisan ui5:explain --app=com.acme.timesheet --partner=42 --at="2026-06-30 00:00:00"
App: com.acme.timesheet
Partner: #42 (Alice Mueller)
At: 2026-06-30 00:00:00
--------------------------------------------------------------------------------
ACT
----------------------------------------
act.approveTimesheet ✅ GRANTED
via ROLE role=project_manager 2026-01-01 00:00:00 → 2026-12-31 23:59:59
act.exportTimesheet ✅ GRANTED
via GROUP group=engineering 2026-01-01 00:00:00 → 2026-12-31 23:59:59
act.closePeriod ❌ DENIEDProvable security
Authorization isn't documented in a wiki that goes stale. It's verified in automated tests that run against the real engine. Every permission, every time window, every edge case, confirmed on every deployment.
it('lets alice approve only while her grant is valid', function () {
$alice = fn (string $at) => (new ScenarioBuilder(new Scenario()))
->module(TimesheetModule::class)
->partner('alice', SystemLevel::User)
->grantAbility(ApproveTimesheetAction::class, 'approveTimesheet', 'alice',
validFrom: Carbon::parse('2026-01-01'),
validUntil: Carbon::parse('2026-12-31'))
->at(Carbon::parse($at))
->resolve()
->actor('alice');
expect($alice('2026-06-15'))->can('act.approveTimesheet')->toBeTrue();
expect($alice('2027-01-02'))->can('act.approveTimesheet')->toBeFalse(); // grant expired
});Ship features, not integration sprints
A new module is a Composer package. Install it, list it in config/ui5.php, sync — and the platform picks it up: navigation, security, help, search. The links it offers into your other modules arrive with it. No routing tables, no release coordination.
$ composer require acme/recruitment-module
Installing acme/recruitment-module (1.2.0)
Discovered LaravelUi5 module: Recruitment
# add \Acme\Recruitment\RecruitmentModule::class to 'modules' in config/ui5.php
$ php artisan ui5:sync
$ php artisan ui5:concept
+--------------------+-----------+-----------+----+-----+
| Concept | Label | Model | In | Out |
+--------------------+-----------+-----------+----+-----+
| acme.candidate | Candidate | Candidate | 1 | 1 | ← new
| laravelui5.partner | Partner | Partner | 1 | 2 |
+--------------------+-----------+-----------+----+-----+From zero to production in five steps
The SDK is a Composer package. No proprietary installer, no separate infrastructure. If you know Laravel, you know this workflow.
Install
Add laravelui5/sdk from the private Satis repository. Your install token authenticates the download.
composer require laravelui5/sdkConfigure
Point Core's config/ui5.php at the SDK: the registry, the context factory, the two middleware stacks and the artifact resolvers. Your apps switch their manifest to the SDK's base class, and your User model learns which partner it is.
php artisan vendor:publish --tag=ui5-configSeed
Create the organisation that operates the installation, then the first people who sign in. That seeder is the one step an implementation consultant writes for each company.
php artisan migrate && php artisan ui5:intakeSync
The sync pipeline reads Core's metadata and writes the database catalog: artifacts, abilities, roles, settings, code lists. Idempotent. Always safe to re-run.
php artisan ui5:syncBuild & deploy
Compile the help, publish the shell assets, and deploy like any Laravel app. Anywhere Laravel runs. No platform contract. No sidecar services.
php artisan ui5:help --all && php artisan ui5:publish --forceDoes this sound like your Monday?
"We quoted twelve weeks and the client just added RBAC to the scope."
The SDK is the enterprise plumbing your team doesn't have time to build. Ship on schedule.
"The board wants something that looks like SAP. This system will never live inside it."
Enterprise UX on a Laravel stack, familiar from the first click. Professional from day one, no platform contract.
"Customer two just signed and we're still running on a single-domain setup."
Partner management and tenant-awareness already ship with the SDK. When customer two means many, the operator layer is one tenancy package away. Roll your own, or take Platform.
Three options. One honest comparison.
What if we build it ourselves?
- Your authorization engine alone is 6+ months of senior engineering. Time-aware RBAC, validity windows, source attribution, audit trail, test coverage.
- Every opinion in the SDK comes from a production lesson that was expensive to learn.
Does this run alongside SAP?
- Yes. The SDK runs inside a standard Laravel app — no platform contract, no extra infrastructure. It sits next to your SAP landscape and keeps custom development out of the core, which is what SAP asks for anyway.
- Your team works with Eloquent, Pest, Composer, and artisan — the stack it already knows. Your ABAP people keep doing what they do best.
What about Filament or Nova?
- Those are CRUD scaffolds. The SDK is a runtime layer: time-aware authorization, business partners, scoped settings, intent-based navigation, built-in help. Different category.
- They solve different problems and coexist happily.
Built from production, not from a tutorial
Production-proven
The LUX stack emerged from building timesheet.biz — a production ERP for professional services firms covering quotation to final billing. Real users, real data, real edge cases. Not a demo app.
Laravel-native
Eloquent, Pest, Composer, artisan, service providers, middleware, everything your team already knows. No proprietary framework to learn. No vendor CLI to install. Just Laravel with enterprise plumbing added.
Code keeps running
If your license expires, installed code keeps running. We never brick production. No updates, no new deployments. But your existing app doesn't stop. This is non-negotiable.
Contracts-first
Every service has an interface. Override anything by rebinding in your AppServiceProvider. The SDK is opinionated, not locked down. Swap what you need to swap without forking the package.
Composer-distributed
Distributed via a private Satis repository. Standard Composer workflow, license-server authenticated. No proprietary installer, no marketplace lock-in, no binary blobs.
Upgrade path, not lock-in
The SDK already runs as its own tenant. Operating many is a tenancy package on top. It's additive, not structural. Roll your own on the open seam, or take Platform. Either way: start small, grow when your business grows. No rewrites.
„Durch die Digitalisierung unseres Projektcontrollings konnten wir interne Projektabläufe wesentlich optimieren. Unserer Warnpflicht können wir nun zeitgerecht nachkommen und unsere Kunden rechtzeitig über erforderliche Mehraufwände informieren. Durch die vorhandene Stundenaufzeichnung hat sich die Abrechnungsweise wesentlich erleichtert."
One product. One license, per installation.
The SDK is the product. An annual license per installation you put into production — your own or the one you deliver to a customer, on your servers or on-premise at theirs. Distributed via a private Composer repository, white-label ready: the application you ship carries your name, not ours. When one app becomes many tenants, that is the job of a tenancy layer: roll your own on the SDK's seam, or talk to us about Platform.
Core
The metadata engine. Yours to run in production.
No credit card, no trial period, no expiry. BSL 1.1 — the licence permits production use outright.
What you get
- Production use included — build applications and services and put them live
- One installation, named by you
- A Composer token per environment: production, staging, development
- The full Core runtime: registry, artifacts, UI5 + OData routing, scaffolding commands
laravelui5/odata(MIT) alongside it — that one needs no account at all- An invite to the monthly office hour
SDK
One installation. Everything the SDK ships.
per installation. Your figure is set in the qualification call — that conversation is where volume, delivery model and term are priced.
What you get
- 1 production installation — your infrastructure, rented cloud, or on-premise at your customer
- Non-production tokens for development, staging, QA, CI and demos — not counted
- Unlimited users, fair-use traffic
- Deliver it under your own name: the shell carries your brand
- Tenant-aware: your app runs in its own booted tenant
- Full SDK: LeanShell, time-aware authorization, settings, help system, partners, Pest DSL
- All updates for the license year
- Community support
Platform
When one app becomes many: run your product as a SaaS.
one installation, priced by the tenants you run
The operator layer, on top of the SDK
- A tenancy layer: many tenants on the SDK's seam, one database each
- Onboarding tooling for repeatable customer setups
- The implementation and operating model, from discovery to go-live
- Priority support & roadmap input
The seam is open: build your own tenancy layer, or build it with us.
Explore Platform →Custom agreements for agencies and consultancies delivering to many customers, OEM and embedded distribution, on-premises license-server hosting, or specific compliance requirements (CRA, NIS2, SOC 2, ISO 27001, DSGVO with DPA). Talk to us.
The fine print, stated plainly
- What counts as an installation?
- A distinct deployment of your application serving real users in production. It makes no difference whether it runs on your own servers, in a cloud you rent, or on-premise at your customer — with or without a public domain name. Subdomain tenants (
*.yourapp.com) inside one deployment are not separate installations. - I build for a customer who runs it themselves. Who is licensed?
- You are, and the installation you deliver counts as one of yours. Your customer may hold its production token and operate it — that is expressly permitted. What they get is the right to run what you delivered; building their own applications on the SDK needs their own license.
- What counts as non-production?
- Development, staging, QA, CI and demo environments, drawn on non-production tokens. They are included in every license and are never counted.
- Do developer laptops need a license?
- No. Every developer on the team runs the SDK locally under the same license, on a non-production token.
- What happens when a license expires?
- Installed code keeps running. We never brick production. No updates, no new deployments, no new installs until you renew — and an installation you already delivered to a customer keeps running too. They do not lose their system because you stopped subscribing.
- Multi-year or volume terms?
- Not through self-service checkout. Multi-year, volume, partnership and OEM terms are agreed directly — that is part of what the qualification call is for.
- Is there a free trial?
- Not of the SDK — but you do not need one to start. Core is free and its licence permits production use, so you can build and ship on the engine before the SDK is ever a question. For the SDK itself: book a live demo of timesheet.biz integrated with it, or ask us for a recorded walkthrough.
Need hands-on help? Architecture review, implementation sprints, and evolution retainers are offered separately by Pragmatiqu IT.