Synapse Laravel Package

Product Decisions This Supports

• Build vs. buy for internal tooling: Rather than commissioning a bespoke admin/back-office app or signing an enterprise low-code contract, this gives teams a ready-made configurable builder that drops into an existing Laravel app — a third path between "build from scratch" and "buy SaaS."
• Roadmap acceleration on three expensive-to-build capabilities simultaneously: visual page builder, typed collections with instant REST API, and an n8n-style flow engine. Any one of those is a multi-quarter investment; here they're a package dependency.
• Self-hosted / data-residency product lines: MIT license plus prefixed tables, its own auth guard, and an opt-in panel means it can be offered where SaaS low-code vendors are disqualified (regulated industries, on-prem customers, strict data-residency requirements).
• Customer-facing portals and embedded builder features: multi-tenant collection design and end-user auth (SSO/2FA) support the "let customers configure their own pages/data" roadmap item without building a tenant-isolation layer from zero.
• AI posture decision: because AI is explicitly optional rather than load-bearing, it supports a "no AI dependency" or "AI as accelerator, not requirement" product strategy — useful when sales/legal want to avoid AI-vendor entanglement.
• Use cases that fit: internal back-office CRUD, admin panels, workflow automation over external data sources, lightweight no-code portals, and prototypes where speed to a working data model matters more than polish.
• A low-regret integration option: it lives alongside the host app and lets existing routes take precedence, so choosing it doesn't foreclose other roadmap bets — an important factor when prioritizing.

When to Consider This Package

Consider it when:

• You already run a Laravel + Filament application and want to add builder/automation capability inside it rather than beside it.
• Self-hosting and data residency are hard requirements — hosted low-code is off the table.
• You have engineering capacity to spike, pin the version, and potentially fork or patch (MIT helps, but 12 stars / 0 dependents means you are the early adopter).
• The first target is internal tooling or a pilot, not a customer-critical path.
• You value the prefixed-tables / own-auth-guard / opt-in-panel design that limits blast radius on your existing app and keeps an exit ramp open.

Look elsewhere when:

• You need an SLA, enterprise support, or a stable public API contract — this is single-maintainer, pre-1.0 territory.
• Your team has no Laravel/Filament depth to evaluate, debug, and operate it.
• You need a large community, third-party plugins, or ecosystem momentum to de-risk hiring and knowledge transfer.
• You're on a non-PHP stack, or you want a fully hosted solution with zero maintenance.
• The requirement is production-grade, multi-tenant, security-sensitive functionality on a tight timeline — treat maturity risk as a blocker until proven otherwise.

Practical adoption posture: treat as a time-boxed technical spike with a written exit plan, not a platform commitment. Pin the version, review the migration/table conventions, and validate the auth-guard and route-priority behavior against your app before committing roadmap surface.

How to Pitch It (Stakeholders)

For executives: This is an MIT-licensed, self-hosted app builder that installs into our existing Laravel application instead of replacing it. It gives us three capabilities we'd otherwise build separately — a visual page/config builder, typed data collections with an auto-generated REST API, and a workflow automation engine — plus SSO/2FA and external data-source support. Because it runs alongside our app with prefixed tables, its own auth guard, and route precedence that defers to ours, the switching cost if it doesn't work out is low.

The honest framing: the project is early-stage — small community, no downstream dependents, single-maintainer risk. So the recommendation is a bounded spike against one internal-tool use case, with success criteria and a kill decision, not a platform bet. Upside: meaningful reduction in time-to-build for back-office and internal data apps, no vendor lock-in, no SaaS data-residency problem, and no AI dependency.

For engineering: it's a Laravel/Filament-native package that composes with what we have — no bespoke runtime to learn, MIT license to fork if needed. Ask for a two-to-four week evaluation covering: integration footprint (tables, routes, guard), upgrade path, and a working end-to-end demo of one collection → API → flow → page. Treat AI features as optional and out of scope for the decision.