Kompass Laravel Package

Product Decisions This Supports

• Shipping a content-managed surface without a CMS vendor. Kompass provides the boring-but-expensive parts of a CMS — an admin UI (Livewire components in src/Livewire/), a content model (Page, Post, Datafield, Block with polymorphic relations wired in the service provider), migrations, and Blade rendering (kompass:: view namespace). That supports a roadmap item like "blog," "marketing pages," or "resource center" landing in weeks rather than a quarter.
• Build vs. buy vs. adopt. This is a third option: adopt. No license cost (MIT), no per-seat billing, no second deploy target, no third-party DPA — content lives in your own database inside your own Laravel app. It is a credible line item in a "kill the WordPress instance / drop the Contentful contract" evaluation, provided you price in the maintenance you're taking on.
• Stack consolidation. It targets Laravel 11/12, Livewire 4, Tailwind 4, Alpine — the TALL stack. Adopting it reinforces a decision you may already be making ("we standardize on TALL"), rather than adding a new runtime, templating language, or admin framework.
• Structured, reusable content. Blocks plus custom datafields mean the content team can compose pages from approved components (hero, CTA, rich text) instead of free-form HTML — a product decision about editorial guardrails and brand consistency, made in the schema rather than in a style guide.
• Time-to-market for MVPs and internal content. Brochure sites, docs, changelogs, internal tooling copy — anything where "an editor needs to change this without a deploy" and the content model is simple.
• Informing a fork-or-buy gate. Because it is MIT and self-contained (composer package, publishable stubs, namespaced Secondnetwork\Kompass\), the cost of trying it and walking away is low — which itself is a portfolio decision worth making explicitly rather than defaulting to SaaS.

What it does not obviously support, and should not be sold as supporting: enterprise editorial workflow (approvals, audit trails, granular roles), multi-tenant or per-brand content isolation, guaranteed headless/API delivery contracts, and large-scale localization. Those are unproven from the repository, so treat them as unknown rather than absent — and verify before they enter a roadmap.

When to Consider This Package

Consider it when:

• Your application is already Laravel 11/12 with Livewire and Tailwind. The integration surface is composer require, php artisan migrate, and published stubs — no new infrastructure.
• You want content in your database, deployed with your app, behind your auth and gates (registerGates in the service provider). Compliance, data residency, and "no new subprocessor" arguments all get easier.
• The content model is genuinely simple: pages, posts, reusable blocks, a handful of custom fields. If you can sketch it on one whiteboard, this fits.
• You have at least one engineer comfortable reading package source as the primary documentation. The repo is well-organized (AGENTS.md, clear PSR-4 layout, Rector config) but this is not a heavily-documented, heavily-used product.
• You can absorb ownership: pinning a version, writing your own smoke tests around publish/unpublish and slug generation, and being prepared to fork. Note the repository states there is no dedicated test suite — that is a cost you inherit, not a footnote.
• You want a bounded spike: one feature flag, one content surface, one or two sprints.

Look elsewhere when:

• You need SLAs, vendor support, security attestations, or procurement-friendly maturity signals. Ten stars and a single-maintainer bus factor will not survive an enterprise review, and you should not pretend otherwise.
• Editorial workflow is a real requirement: multi-stage approvals, scheduled publishing with audit history, fine-grained per-role permissions, editorial preview environments.
• You need a stable, documented content API for multiple consumers (mobile app, partners, personalization layer). Nothing here reads as a committed delivery contract.
• Your content team expects a polished, familiar editor and you have no budget to improve it. The admin is Livewire-native — good for engineers, potentially rough for a Wordpress-trained editor.
• You need localization at scale, multi-site/multi-brand, or a plugin ecosystem.
• You cannot fund regression tests. With no upstream test suite and cache invalidation happening in model boot methods, silent breakage on upgrade is a realistic failure mode.

How to Pitch It (Stakeholders)

For executives — one paragraph. Kompass is an MIT-licensed Laravel CMS package that lets us add editor-managed content to our existing application without signing a SaaS contract, adding a second deploy target, or sending content to a third party. Editors get an admin inside the product we already run; content is stored in our own database and ships with our normal release process. There is no license fee and switching costs are low because the code is ours to fork. The trade-off is maturity: it is a small, young open-source project with no upstream test suite, so we would own upgrades and quality assurance. Recommendation: fund a short, feature-flagged spike on a bounded surface (for example, the blog plus a handful of marketing pages), then make a go/no-go call with real evidence rather than speculation.

For engineering — the practical case. It is a composer package, PSR-4 under Secondnetwork\Kompass\, targeting Laravel 11/12 and Livewire 4 with Tailwind 4 and Alpine. It publishes migrations and stubs, registers its own service provider with morph maps for Page/Post/Datafield, exposes Blade views under the kompass:: namespace, and builds frontend assets via Vite into public/assets/build. Static analysis via Rector is configured. What it does not give us is tests — so our adoption plan should include: pin the version, write characterization tests around page/post lifecycle, slug generation, and cache invalidation on model save/delete, and keep our content model thin so a fork stays cheap.

The ask. Approve a timeboxed spike with a clear success criterion — "an editor publishes a page and a post end-to-end without a deploy, and we have tests covering that path" — and a clear exit: if the gaps we find require more than a sprint of hardening, we default to a SaaS CMS and revisit later.