Commercial

Production-grade enterprise
plumbing for Laravel apps.

Time-aware authorization, a lightweight enterprise shell, scoped settings, and a business partner model borrowed from SAP. The six months of plumbing you'd rather not build.

See what's inside Talk to us

The problem

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 something that looks like SAP.

Your budget is a fraction of what SAP costs. 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.

Capabilities

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.

Semantic Objects and Semantic Links let modules reference each other by intent. Add a Composer package, clear the cache, and the new module appears in navigation automatically. No routing tables to update, no menus to maintain.

Drop-In Modules

Install a package, gain a feature.

A sealed Composer bundle registers itself with the platform on install. Run the caching commands and your application has new capabilities. No wiring, no configuration, 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 one tenancy package up the stack. Roll your own on the open seam, or take ours: Platform.

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

Seven artisan commands. One test DSL. Zero guesswork.

Sync metadata, explain authorization decisions, generate documentation, inspect navigation. The Pest DSL tests your real authorization engine against real SQL. What the CLI says is what production sees.

Proof, not promises

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.

Terminal

$ php artisan ui5:explain --partner=alice --at="2026-06-30"

Partner:    Alice Mueller (partner_id: 42)
Timestamp:  2026-06-30T00:00:00+02:00

Capabilities (3):
  timesheet          via role "Project Manager"
                     granted by group "Engineering"
                     valid 2026-01-01 → 2026-12-31

  reporting          via role "Project Manager"
                     granted by group "Engineering"
                     valid 2026-01-01 → 2026-12-31

  admin.users        via direct grant
                     granted by admin@example.com
                     valid 2026-03-15 → 2026-09-30

Abilities (7):
  timesheet.entry.create     ✓ (role)
  timesheet.entry.approve    ✓ (role)
  timesheet.report.export    ✓ (role)
  reporting.dashboard.view   ✓ (role)
  admin.users.list           ✓ (direct)
  admin.users.edit           ✓ (direct)
  admin.users.impersonate    ✗ (not granted)

Provable 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.

tests/Feature/AuthorizationTest.php

security()
    ->app('timesheet')
    ->role('Project Manager', abilities: [
        'timesheet.entry.create',
        'timesheet.entry.approve',
        'timesheet.report.export',
    ])
    ->group('Engineering', roles: ['Project Manager'])
    ->partner('alice', groups: ['Engineering'],
        validFrom: '2026-01-01',
        validTo:   '2026-12-31',
    )
    ->assertCan('alice', 'timesheet.entry.create')
    ->assertCan('alice', 'timesheet.entry.approve')
    ->assertCanAt('alice', 'timesheet.entry.create',
        at: '2026-06-15',
    )
    ->assertCannotAt('alice', 'timesheet.entry.create',
        at: '2027-01-02',  // grant expired
    );

Ship features, not integration sprints

A new module is a Composer package. Install it, run two cache commands, and the platform picks it up. Navigation, security, help, search. No routing tables, no manual wiring, no release coordination.

Terminal

$ composer require acme/recruitment-module

Installing acme/recruitment-module (1.2.0)
Discovered LaravelUi5 module: Recruitment

$ php artisan ui5:cache
$ php artisan ui5:navigation

Navigation tree (4 modules):
  timesheet          ✓ registered
  reporting          ✓ registered
  admin              ✓ registered
  recruitment        ✓ registered    ← new

Semantic Links (2 new):
  recruitment → partners    (candidate → business partner)
  recruitment → timesheet   (placement → time entry)

Getting started

From zero to production in five steps

The SDK is a Composer package. No proprietary installer, no magic CLI, no separate infrastructure. If you know Laravel, you know this workflow.

Install

Add laravelui5/sdk from the private Satis repository. Your license key authenticates the download.

composer require laravelui5/sdk

Configure (optional)

The SDK ships no config of its own. It inherits config/ui5.php from Core, auto-merged from defaults. If you set up Core, you're already configured. Publish only to override a default (middleware, shell discovery). The SDK discovers your Core modules automatically.

php artisan vendor:publish --tag=ui5-config

Sync

The sync pipeline reads Core's metadata and writes the database catalog: artifacts, abilities, roles, navigation, help topics. Idempotent. Always safe to re-run.

php artisan ui5:sync

Build

Compile help HTML and the full-text search index. LeanShell picks up your modules and wires navigation, search, and the help surface.

php artisan ui5:doc

Deploy

Standard Laravel deployment. Cloudflare, Hetzner, AWS, bare metal. Anywhere Laravel runs. No SAP infrastructure. No sidecar services.

php artisan optimize && php artisan ui5:cache

Read the Docs

Built for your team

Does 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. Our budget says otherwise."

Enterprise UX on a Laravel stack. Professional from day one, no SAP infrastructure.

"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.

The alternatives

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.

What about SAP?

No SAP infrastructure required. The SDK runs inside a standard Laravel app. Deploy anywhere Laravel runs.
Your team works with Eloquent, Pest, Composer, and artisan. No CDS, no ABAP, no transports.

What about Filament or Nova?

Those are CRUD scaffolds. The SDK is a runtime platform: time-aware authorization, business partners, scoped settings, intent-based navigation, built-in help. Different category.
They solve different problems and coexist happily.

Why trust this

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."
Bettina AnderwaldCFO, AH Safety-Engineering

Pricing

One product. One license, per production domain.

The SDK is the product. One Laravel app on one production domain, tenant-aware out of the box. An annual license, distributed via a private Composer repository, white-label ready. When you're ready to run it for many customers, that's one tenancy package away. Roll your own, or take Platform.

The product

SDK

One app. One domain. Everything the SDK ships.

€3,900/ year

per production domain

What you get

1 production domain
1 non-production domain (staging / QA / demo)
Unlimited users, fair-use traffic
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

Operator →

Platform

When one app becomes many: run your product as a SaaS.

Let's talk

priced to your operation

The operator layer, on top of the SDK

Tenancy operations package: provisioning, domain routing, isolation
Laravel Zero onboarding tool you white-label
The operating model: guidelines and the mental hats
Priority support & roadmap input

The seam is open — build your own tenancy package, or take this one.

Explore Platform →

Custom agreements available for deployments over 25 production domains, 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 a production domain?: A distinct Laravel installation serving real users on its own domain. Subdomain tenants (*.yourapp.com) within one installation are not separate domains.
What counts as non-production?: staging.*, qa.*, demo.*, *.test, *.local, *.localhost, and PR preview environments that only serve the development team and tear down automatically.
Do developer laptops need a license?: No. Every developer on the team runs the SDK locally under the same license. Dev laptops are not domains.
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.
Multi-year prepay discounts?: 15% off year 2 on a 2-year prepay, 25% off years 2 and 3 on a 3-year prepay. Applies to the whole bill.
Is there a free trial?: No free trial. Book a live demo of timesheet.biz integrated with the SDK, or ask us for a recorded walkthrough.

Need hands-on help? Architecture review, implementation sprints, and evolution retainers are offered separately by Pragmatiqu IT.

Ship

Build your next SaaS product on a foundation that lasts.

Talk to us Read the Docs

Production-grade enterpriseplumbing for Laravel apps.