Lemme Laravel Package

Product Decisions This Supports

• Whether documentation becomes a product surface, not a side project. Standing up a searchable docs site inside the Laravel app — rather than on a separate microsite with its own deploy pipeline and design system — turns docs into a feature you can gate, personalize, and instrument. That is a packaging and pricing lever (docs for paid tiers, in-app help for onboarding), which makes it a PM decision rather than an engineering convenience.
• Build vs. buy vs. "boring static site" for a docs surface. The real comparison is three-way: (a) adopt this package, (b) hand-roll docs routes in the app, (c) run a mature static generator behind the app's auth. Choosing (c) usually wins on features and hiring familiarity; choosing this package wins on deploy cohesion and reuse of existing auth/tenant/billing. A PM should force that comparison explicitly instead of letting "should we add a dependency?" stand in for it.
• Support-deflection investment. Searchable, accurate docs are a cost-of-support lever. Fund this when tickets-per-1k-MAU trends up or when onboarding funnel drop-off correlates with "didn't know how." Measure deflection (self-serve resolution rate, tickets per active account), not pageviews — a docs package will happily inflate pageviews while tickets stay flat.
• Release coupling. Markdown-in-repo means docs update in the same PR that changes behavior, and docs roll back with the app. That eliminates an entire class of "docs said X, product does Y" incidents and the cross-team dependency on whoever owns the marketing site. Ask: is docs accuracy currently a recurring customer-complaint theme? If yes, this is the argument.
• Time-to-market on a docs commitment. If docs are on the roadmap as a separate workstream, this package potentially pulls it forward a quarter by removing foundations (routing, search, rendering). Frame it as re-sequencing, not new scope.
• Platform conventions precedent. A Laravel-native docs generator establishes "keep it in the monolith, one runtime, one deploy" as the default. That precedent will be cited in future "should this be a separate service?" debates — adopt deliberately, because you're setting policy, not just adding a dependency.
• What it explicitly should not decide: generated API reference (OpenAPI/protobuf), versioned docs per release, localization, or non-engineer authoring workflows. Do not let a docs package be cited in a roadmap as the plan for any of those; they are separate line items with separate budgets.

When to Consider This Package

Worth a time-boxed spike when:

• The docs audience is internal or gated and medium-sized — help center, API how-to guides, tenant-facing runbooks — where docs downtime is annoying, not revenue-impacting.
• Docs should inherit the app's auth, tenancy, and subscription state (gated or personalized docs are a genuine reason to be in-app rather than external).
• Authors are the engineers and PMs writing Markdown in the repo; there is no requirement for marketing/support/localization to author content.
• You want docs to ship and roll back on the existing CI/CD pipeline with no new hosting, secrets, or on-call surface.
• You can accept a small, single-maintainer dependency behind an adapter boundary so removal is a one-module change.

Look elsewhere when:

• Authoring is owned by non-engineers, or you need review workflows, scheduled publishing, per-release versioning, or i18n. A dedicated docs platform or static site generator will beat a small package here, and the team already knows how to use it.
• The audience is large and external. Public docs are an SEO/acquisition asset; that argues for indexable static HTML, CDN delivery, and a mature theme — not for a young package's rendering path.
• You need generated API reference from a schema. Different tool, different budget line.
• Adoption risk tolerance is low. Stars: 3, v1.0.0 first stable release, no published changelog, single maintainer, and — critically — the package description ("generate a documentation site from Markdown") does not match its own description.md ("wraps common, repetitive application tasks behind a fluent API"). You cannot write a spec, size an integration, or promise a date against a README that contradicts itself. That inconsistency is the first thing the spike must resolve, and it is a legitimate reason to stop before the spike.
• Docs are revenue-critical or a competitive differentiator. Then you own the pipeline and the theme.
• Procurement requires vendor support terms or data-residency guarantees. Community-only, no SLA.

The honest baseline: put MkDocs or Docusaurus behind the existing Laravel auth and compare it to this package on integration effort, not on novelty. If the package doesn't clearly win on effort, take the boring option — it has more contributors than this repo has stars.

How to Pitch It (Stakeholders)

For executives (decision + ask): We're evaluating a lightweight Laravel package to stand up a searchable docs surface inside the product, rather than commissioning a separate documentation site. The upside is speed and cohesion: docs live in the same repo, inherit login and plan gating, and ship with the release that changes the product — which lets us use documentation as a support-cost and packaging lever instead of a content-ops project. Cost is days, not a quarter. The risk is genuine and bounded: it's an early-stage, single-maintainer package with minimal adoption and documentation that is internally inconsistent about what it actually does, so it does not go on a revenue path until a short spike proves it out. Ask: approve a 2–3 day spike, not adoption. Worst case we've spent a week and produced a written comparison against the standard static-site approach, which is reusable regardless of the outcome.

For engineering (integration reality): This is a docs-pipeline and conventions decision, and the cost lives in the integration surface, not the composer require — routing, auth middleware, search indexing, and caching all touch code we own. We want a hard adapter boundary so exactly one module imports the package's namespaces, and no published migration is allowed to touch our schema without review. Before commitment we need four facts the README doesn't give us: the declared Laravel/PHP support matrix (including our next upgrade target, since that's the constraint that bites in 6–12 months); whether it publishes config/migrations and whether those are reversible; how the search index is built (request path vs. queued job — a serialized package class is the classic v1→v2 deploy break); and whether rendering is cacheable under Octane. The benchmark to beat is a static docs site served from the app behind existing auth, with zero new dependencies.

Recommendation: Run the spike with pre-agreed exit criteria — version compatibility confirmed against our current and next Laravel major, no schema migrations, no measurable p95 regression on the docs routes, index build off the request path, a documented removal path, and a side-by-side effort estimate versus the static-site baseline. Decide on the spike's evidence. The three stars aren't disqualifying on their own; shipping against a contradictory README without a spike would be.