Hello Api Laravel Package

Product Decisions This Supports

• API-first architecture bet: Apiato bakes in the assumption that the product's primary interface is a versioned HTTP API (mobile clients, partners, internal services). Adopting it is a commitment to that bet, so it belongs in the platform/architecture decision record, not a library-level choice. v13.2.0 adds a "modern responsive UI" starter — this softens the edge of the bet without reversing it: verify whether it is opt-in scaffolding or a default surface before citing "API-only" in the ADR.
• Build vs. buy for boilerplate: It replaces weeks of scaffolding — auth (Passport/JWT), request validation, Fractal transformers, repositories, pagination, error handling, API documentation generation, and test harnesses. The PM decision is "do we want our team writing this, or standardizing on someone else's conventions?" v13.2.0 extends the bought-in surface to include a baseline admin/consumer UI, which is incremental value only if that UI is genuinely optional.
• Modularity / team scaling roadmap: The Porto SAP container model (Domain → Container → Section → Action/Task) maps cleanly to bounded contexts. This is a lever for parallelizing work across squads later without a monolith rewrite — useful when the roadmap anticipates 3+ squads or a marketplace/multi-tenant surface.
• Time-to-market for MVP and pilot APIs: Because it ships a working "Hello" API skeleton with generators, a thin vertical slice (one container, one endpoint, tests, docs) can land in days — de-risking a partner-integration pilot or a design-partner commitment. If the new UI starter is solid, a design-partner demo with a real back-office screen is now a smaller lift; scope it as a demo asset, not a product commitment.
• Consistency as a product quality goal: Uniform response envelopes, error formats, and versioning are user-visible API contracts. Standardizing early avoids a breaking-change tax on integrators later. A bundled UI helps here only if it consumes the same envelope conventions; if it introduces a second rendering path, it becomes a consistency risk to police.
• Framework scope and positioning (new decision surfaced by v13.2.0): Apiato's identity was "API-only, no Blade surface." A responsive UI feature means the project is drifting toward a broader full-stack starter. That's a legitimate PM question — "do we want a framework that stays narrow, or one that grows scope?" — and it should be answered explicitly, because it affects how much of the UI layer you inherit versus write.

When to Consider This Package

Adopt when:

• The product is API-first (mobile clients, partners, internal services) and Laravel is already the team's stack. v13.2.0 means "no UI at all" is no longer a hard requirement — but confirm with the maintainers/PR whether the responsive UI is optional scaffolding; if it is not cleanly optional, the API-only criterion still applies as originally written.
• You expect the domain to grow into distinct modules, and want enforced boundaries before entropy sets in.
• You have at least one engineer comfortable with DDD/hexagonal-adjacent patterns who can own the conventions and review drift.
• You can tolerate opinionation: the framework's value is the constraint. Teams that fight conventions get the overhead without the payoff.
• You're comfortable pinning to the Laravel versions Apiato supports, rather than tracking Laravel's release cadence on day one.
• New: You want a starting admin/consumer UI without separately wiring a frontend — treat the v13.2.0 UI as an accelerant for internal tools and demos, and audit it (accessibility, auth boundary, build tooling, upgrade path) before shipping it to customers.

Look elsewhere when:

• The app is a small CRUD service or an internal tool — the Action/Task/Repository layering is pure abstraction tax at that scale; plain Laravel with a few form requests is cheaper to hire for and cheaper to change. A UI starter does not change this; the layering cost is unchanged.
• The roadmap is frontend-heavy or requires a deep Livewire/Inertia/SPA surface — a bundled responsive UI is not a substitute for a frontend architecture. You'd still be paying for an API framework and fighting it.
• You need day-one support for the newest Laravel major, or depend on packages that assume default Laravel structure.
• Maintenance risk is a blocker: ~3.1k stars but 0 listed dependents and a single-primary-maintainer profile. v13.2.0's first-time contributor is a mild positive signal for community health but does not materially change the bus-factor assessment. Most usage is still "fork the starter project," so upgrades are manual and community support is thinner than base Laravel. If your org has a policy against low-bus-factor dependencies in the critical path, this still fails it.
• You need a mainstream hiring pool. "Apiato experience" is not a résumé line; budget for onboarding.
• New: You need a stable, narrowly-scoped framework contract. A feature drop that expands the framework's surface into UI suggests roadmap direction is set by contributor PRs rather than a published product plan — a governance risk worth weighing if you are standardizing multiple teams on it.

Mitigation if you adopt anyway: treat it as a template you own, not a dependency you consume. Fork it, vendor it, assign an internal owner, and write down the upgrade policy before the first sprint. With v13.2.0 specifically: decide at fork time whether you are taking the responsive UI or excluding it, so a future UI change can't force a merge conflict into your product surface.

How to Pitch It (Stakeholders)

To executives: Apiato is a pre-built, MIT-licensed foundation for API-first products on Laravel. It compresses the "boring but mandatory" first phase — authentication, validation, response formatting, documentation, testing scaffolding — from an estimated several weeks into days, and it imposes a module structure that lets us add squads later without re-architecting. The latest release (v13.2.0) also ships a modern responsive UI starter, which can shorten time-to-demo for a back-office or partner-facing screen. Cost is zero in licensing; cost is in a learning curve, in owning the template ourselves, and in monitoring a project that is actively expanding its scope.

To engineering: You get Laravel plus enforced conventions: containers as bounded contexts, Actions for use cases, Tasks for reusable steps, repositories behind interfaces, transformers for output, and generated API docs and tests. v13.2.0 adds a responsive UI layer from a first-time contributor — treat it as contributed scaffolding, not a blessed frontend architecture: review the PR, check the auth/route boundary against the API containers, and confirm it can be excluded at fork time. Everything else is unchanged: more files and indirection per feature, a smaller community than vanilla Laravel, and upgrade work we perform rather than composer update. If we adopt it, we fork it and assign an owner; we do not treat it as a passive dependency.

The honest one-liner: high leverage for the right shape of product, real lock-in for the wrong one — decide on the API-first + modular-domain criteria, not on the star count, and note that v13.2.0 means the framework's scope is still moving, so buy the template on your terms rather than the project's.