Most small and mid-sized companies run on a patchwork of tools: one app for tasks, a spreadsheet for holidays, a separate CRM, an invoicing service, and a stock sheet someone updates on Fridays. Each tool has its own login and its own copy of the client list, and none of them know what the others are doing. Finishing a production order doesn’t touch the stock count; approving a holiday doesn’t show up in the team calendar.

All-in-one suites solve this by being enormous. EPOK Frame takes the opposite approach: a small, solid core and a set of modules that plug into it. A company gets exactly the tools it uses, and those tools share one set of people, clients, files and history.

A handful of requirements shaped every technical decision:

Always on, for every company on the platform:

Eleven modules, each self-contained and switchable per company:

EPOK Frame is one Laravel application, deployed and migrated as a single unit — but internally it’s divided into modules with hard boundaries. Each module is one folder containing everything it needs: database migrations, models, controllers, validation, services, events and listeners, web and API routes, and its own React pages and components.

Every module also ships a manifest declaring its sidebar entries, dashboard widgets, permission keys, searchable models and dependencies on other modules. At boot, the platform discovers each module folder and registers it — routes, migrations, permissions and navigation included. Adding a module means adding a folder; nothing in the core changes.

I chose this over microservices on purpose. One codebase, one database and one deployment are far cheaper to run and reason about, and the module boundaries still keep each part independent.

All companies share one database. Every tenant-owned table carries a company_id column, and that one column is all that separates one company’s data from another’s — so the filter can’t be left to individual queries.

Every tenant model uses a BelongsToTenant trait, which registers a global query scope. From then on, every query on that model gets WHERE company_id = ? appended at the query-builder level before any SQL is sent, and every new record has its company_id stamped automatically. A controller can’t forget the filter, because controllers never write it.

Before any of that runs, a request passes a layered set of checks: authentication, whether the module is enabled for the company, whether the user’s role grants the permission, and whether the record in the URL belongs to the user’s company.

Platform staff sit outside the tenants. They see across companies in platform-level views and can enter a company to support it; entering sets a session context that scopes their reads and writes exactly as if they were a member, and creating a record without that context is refused outright.

A single shared database was a deliberate trade-off. It means one schema to migrate, platform-wide reporting as ordinary queries, and no need to provision databases on the fly — which shared hosting doesn’t allow. The cost is that isolation depends on the application, which is exactly why it’s enforced in one place, at the lowest layer, and covered by automated tests.

A module never imports another module’s models or services. Instead, modules announce what happened — TaskCompleted, LeaveRequestApproved, InteractionLogged — and any other module can listen.

Listeners are registered only for the modules the current company has enabled. If a company doesn’t use Time Tracking, its listener simply isn’t there, and nothing needs a guard clause or a feature flag. Completing a task updates project progress; approving leave notifies the employee and blocks out the calendar; starting a production order draws its materials from the warehouse. None of these modules know the others exist.

Comments, files, tags, activity history and notifications are built once in the core and attached to records through polymorphic relationships. A module opts in by adding a trait to its model and placing a shared React component on its page.

That’s why a CRM contact, an invoice, an employee profile and a production order all get threaded comments, attachments, tags and a full change history from a single implementation — one set of tables, one set of components, one place to fix a bug. The record types that can receive attachments are checked against an explicit allowlist, so a crafted request can’t attach anything to a record it shouldn’t reach.

Access follows a four-level hierarchy: platform owner, platform admin, company admin and company user. Underneath sit granular permission keys in module.action form — tasks.edit_own, hr.approve_leave_requests, crm.export — declared by each module in its manifest and registered automatically.

Permissions understand ownership: tasks.edit lets you edit any task, tasks.edit_own only the ones you created or were assigned. Company admins build their own roles — sales rep, accountant, warehouse operator — from a checklist grouped by module, and a custom role can never exceed the admin’s own permissions. The server enforces every check through route middleware and policies; the same permission list is shared with the interface, so buttons a user can’t use are never rendered. Platform admins can suspend a company but not delete it — that’s reserved for the platform owner.

The interface is React, delivered through Inertia.js: Laravel controllers return a page component and its data directly, with no separate client-side API layer, router or state store. Navigation feels like a single-page app while the server stays the single source of truth. A custom page resolver lets each module keep its React pages inside its own folder, and every page receives the user, their permissions and the company’s enabled modules — so the sidebar builds itself.

Next to the interface runs a REST API under /api/v1, authenticated with Sanctum tokens and guarded by the same module and permission checks. Every response uses one envelope — data, meta, message — and errors carry machine-readable codes such as VALIDATION_ERROR, FORBIDDEN or MODULE_DISABLED. Resource classes define exactly which fields leave the server; raw database models are never returned.

The whole platform needs only PHP and MySQL. Sessions and search run on the database, background jobs are processed by a cron-driven scheduler, and front-end assets are compiled before deployment, so the server never needs Node.js. Each of these is a single environment setting — Redis, Meilisearch or S3 can be switched in as load requires, without code changes.

The interface is deliberately quiet: data first, no decorative gradients or ornament, with hierarchy built from spacing, weight and colour — in the spirit of the Linear, Vercel and Stripe dashboards.

The whole visual language lives in design tokens defined as CSS custom properties. Dark mode is the default — deep navy surfaces with the brand green as the only accent — and the light theme is tuned rather than inverted: the green darkens for text on white so it keeps its contrast. Switching themes changes a single attribute on the page.

Typography follows a strict rule: Orbitron is reserved for brand moments — the wordmark and the sign-in screen — while Inter carries the entire working interface and JetBrains Mono handles code and identifiers. The layout adapts from a full 260 px sidebar on desktop to a 68 px icon rail on tablets and a drawer on phones, and motion is used only to communicate a change of state.

A shared library of token-driven components — buttons, inputs, modals, tables, badges, dropdowns, tabs and toasts — gives every module the same look and behaviour without a line of module-specific styling.

The choices that shaped the platform, and what each one cost:

EPOK Frame turns “which software should we buy?” into a settings page. The same installation can run a services agency on projects, CRM, invoicing and time tracking, a manufacturer on warehouse and production, and a freelance studio on three modules — each company seeing only its own data and its own tools.