Build vs. Buy Your Admin Panel (And When You're Fooling Yourself)

Filament and Laravel Nova are both genuinely good pieces of software. I've used both in production. But I've also watched a project start as "we'll just use Filament" and end three months later as a barely-recognizable fork with seventeen custom Livewire components, a hacked-together permission system, and a teammate who visibly flinches whenever someone opens the app/Filament directory. At that point you've bought the worst of both worlds: the constraints of a framework you're fighting, plus the maintenance burden of custom code you wrote under pressure.

So here's my actual decision process, sharpened by getting this wrong a few times.

What These Tools Actually Do

Before I get into the tradeoffs, it's worth being precise about what you're buying.

Laravel Nova is Inertia/Vue, runs $199/project, and gives you a polished UI with Resources, Actions, Lenses, Metrics, and Filters. It's opinionated about Eloquent. It's beautiful out of the box. The extension ecosystem is decent. The licensing is per-project, which stings if you're an agency with twenty clients.

Filament is free, Livewire-based, and has caught up to Nova in features while surpassing it in community momentum. The panel builder, form builder, and table builder are actually usable as standalone packages, which matters. It's grown fast enough that I'd now call it the default choice for new Laravel projects that need an admin.

Both tools share the same core assumption: your data is in Eloquent models, your relationships are normal, and your users mostly need to create, read, update, and delete records with some light filtering and search.

When that assumption holds, they're fantastic. When it doesn't, you're in trouble.

The Honest Scorecard

Let me break down the scenarios I see repeatedly.

When Filament (or Nova) is genuinely the right call

• You're building a back-office for a SaaS app. Users, subscriptions, basic content management, support-staff tooling. Standard Eloquent models. This is the wheelhouse. Filament will have you running in a day.
• The admin users are internal staff who'll tolerate a slightly generic UI. They don't need it to feel like a product, they need it to work.
• You're a solo developer or small team and you need to ship something in a week. The velocity is real.
• The person who owns the admin long-term is comfortable with Filament/Nova's patterns. This is underrated. If your successor is a Laravel developer, handing them a Filament codebase is a gift.

I built an e-commerce back-office on Filament last year for a client in the wholesale distribution space. Orders, inventory adjustments, customer accounts, some basic reporting. Took about four days to get to feature-complete. The client's ops manager learned to add products herself within an hour. That's the tool doing its job.

// This is all you write for a fully functional order resource in Filament.
// Four days to production. That's the pitch.

class OrderResource extends Resource
{
    protected static ?string $model = Order::class;
    protected static ?string $navigationIcon = 'heroicon-o-shopping-cart';

    public static function form(Form $form): Form
    {
        return $form->schema([
            Select::make('customer_id')
                ->relationship('customer', 'name')
                ->searchable()
                ->required(),
            Select::make('status')
                ->options(OrderStatus::class)
                ->required(),
            Repeater::make('items')
                ->relationship()
                ->schema([
                    Select::make('product_id')
                        ->relationship('product', 'name')
                        ->required(),
                    TextInput::make('quantity')
                        ->numeric()
                        ->required(),
                ]),
        ]);
    }

    public static function table(Table $table): Table
    {
        return $table
            ->columns([
                TextColumn::make('id')->sortable(),
                TextColumn::make('customer.name')->searchable(),
                TextColumn::make('status')->badge(),
                TextColumn::make('total')->money('usd')->sortable(),
                TextColumn::make('created_at')->dateTime()->sortable(),
            ])
            ->filters([
                SelectFilter::make('status')->options(OrderStatus::class),
            ]);
    }
}

That's a real, working resource. Not pseudocode. If your admin looks like this, stop reading and go use Filament.

The warning signs you're already writing a custom tool

Here's where I've gotten burned, and where I've watched others get burned.

Your data doesn't live only in your database. I integrated a LIMS system for a biotech client where the "records" were half in Postgres and half pulled from an external API in real time. Filament's Resources assume Eloquent. You can hack around this with custom pages and interacting with the query builder manually, but you're swimming upstream from day one.

Your permissions are complex enough to be a product in themselves. Filament has decent role/permission support via Spatie's package. But I've had clients with permission models that were genuinely complicated — field-level visibility based on the viewer's department, approval workflows with multi-step states, records that behave differently based on who's looking. The moment you're overriding canViewAny, canView, canCreate, canEdit, canDelete and you're adding custom authorization checks inside individual field definitions... you're writing application logic inside a framework's extension points. That's fragile and it's hard to test.

You need a workflow, not a CRUD screen. There's a hard line between "manage records" and "orchestrate a process." An admin panel that shows you an order and lets you edit it is one thing. An admin panel where a staff member needs to move an order through five states, trigger external API calls at certain transitions, see a live view of warehouse status, and leave an audit trail with notes is a workflow tool. Filament can approximate some of this. But you'll spend more time fighting the abstraction than you would building the right thing from scratch.

You've written more than two custom Filament pages. This is my personal canary. One custom page is fine. Two is a yellow flag. If you're writing a third, you've already decided you need custom UI — you just haven't admitted it yet.

The client keeps asking for things that aren't "manage records." Real conversation I've had: "Can we add a button that runs the reconciliation job and shows the output inline?" Sure, Filament has Actions. "Can we have a dashboard with a live feed of inbound API events?" OK, custom page. "Can we build a drag-and-drop scheduling board?" ...you're building a custom tool. Filament isn't the right answer here.

What "Building Custom" Actually Costs

The reason people reach for Filament or Nova even when they shouldn't is that the alternative feels expensive. And honestly, it is — at the start.

A simple custom admin panel built on Laravel with Livewire (or Inertia if the team knows Vue) is maybe two to three weeks of work to get to the functionality you'd have on day two with Filament. That's real money. I don't want to pretend otherwise.

But here's what I've seen play out: a project that starts on Filament and fights it for six months ends up with more code than a custom build would have produced, plus the cognitive overhead of understanding Filament's internals, plus a codebase that's hard to hand off because the customizations are non-obvious.

Custom tooling built intentionally tends to be surprisingly maintainable because it only does what you need. There's no framework seam to worry about. You own the whole thing.

When I build custom, my default stack is: Laravel, Livewire for interactivity, a simple role/permission layer with Spatie, and a component library (I've been using Flux lately, which is Caleb Porzio's commercial Livewire component set). No magic. Just Laravel doing Laravel things.

My Actual Decision Tree

1. Is this primarily CRUD over Eloquent models with standard relationships? Yes → Filament, stop overthinking it.
2. Will you need more than two screens that aren't Resource views? Yes → pause.
3. Are your permissions complex enough to write tests for? Yes → strongly consider custom.
4. Is this a workflow tool or a record management tool? Workflow → custom.
5. Do you have more than one external data source? Yes → custom.
6. Is the client's business logic going to live inside Filament extension points? Yes → custom.

If you're on the fence after that, I'd lean Filament. You can always refactor. But be honest with yourself about which side of the line you're on.

When I'd Reach for Each

Filament: SaaS back-office, content management, e-commerce administration, standard CRM tooling, any internal tool where the data model is sane and the use cases are mostly "show me records and let me edit them." Also: when I'm a solo developer on a time budget and I need to ship.

Nova: Honestly, I've mostly moved to Filament. Nova is still polished and the Vue component ecosystem can be nice if your team knows Vue. The per-project licensing makes it awkward for agencies. I'd reach for it if a client specifically requested it or if I needed a Vue-heavy customization.

Custom: Anything with significant workflow logic. Anything touching multiple external data sources. Any tool where the UX needs to feel like a product rather than an admin panel. Anything where the permission model is a domain problem in its own right. Any project where I find myself looking at the Filament docs and thinking "there must be a way to override this."

The real tell is that last one. If you're spending more time reading about how to extend the framework than you're spending building features, the framework is costing you more than it's saving.

Filament is good software. Use it when it fits. But don't let the fast start of day one blind you to what months two through six are going to look like. I've refactored out of both Filament and Nova mid-project, and it's painful every time. Better to make the call early.