Product concept

Flashboard is not intended to be only a CRUD generator or only a UI kit. The goal is to provide a reusable Laravel admin runtime that gives teams a ready-to-use panel shell while keeping business logic inside the host application.

Product positioning

Flashboard should help teams:

• install a package and get a working /admin panel quickly
• describe resources declaratively
• keep table, form, detail, and action UX consistent
• escape into custom pages and operator workflows when CRUD stops being enough

The package should feel closer to an admin runtime than to a loose collection of components.

Core principle

The main public model is not a single universal field() API. Instead, Flashboard splits concerns into explicit surfaces:

• table()
• form()
• detail() or infolist()
• actions()
• pages()

Tables, forms, detail views, and workflow pages all have different constraints. Separate surfaces keep the public API easier to reason about and help the runtime stay predictable.

Mental model

Panel
  -> Resources
  -> Pages
  -> Navigation
  -> Auth
  -> Theme

Resource
  -> table()
  -> form()
  -> detail()
  -> query()
  -> actions()
  -> policies()
  -> pages()

The package owns the runtime and rendering contracts. The host application contributes models, queries, policies, and business rules.

80/20 rule

Flashboard is designed around a practical split:

• 80% of admin work should be solved declaratively
• 20% should be solved through explicit custom pages and extensions

Trying to force every advanced use case into the declarative DSL would make the package heavy and brittle. Ignoring the declarative path would remove most of the DX value.

Operator workspaces

The package is meant to support more than classic resource CRUD. Real internal panels also need:

• review queues
• moderation consoles
• finance approval flows
• reconciliation screens
• processing workspaces

That is why custom pages and workspace payloads are part of the product direction from the start.

Backend-driven contract

The preferred runtime model is backend-driven:

• the backend describes resources, fields, actions, and rules
• the frontend receives a normalized payload
• the frontend renders through package-owned wrappers and layout shells

This keeps behavior consistent across resources and reduces repeated application-specific frontend code.

Success criteria

Flashboard is successful when:

• new resources can be created quickly
• repeated admin patterns stop being rebuilt per project
• complex workflows still fit inside the same panel runtime
• UX remains consistent across list, form, detail, and workspace screens
• teams can customize behavior without forking the package