I Got Tired of Rebuilding Admin Dashboards, So I Made One Installable

Every admin dashboard I worked on looked different on paper — but structurally, they were the same.

Same sidebar.
Same header.
Same colors.
Same responsiveness problems.

Yet for every new project, we rebuilt the layout from scratch.

That changed the day I spent several minutes debugging a slightly “off” dashboard width in a new project and realized something was wrong with our process, not the layout.

The Moment I’d Had Enough

I was collaborating with a colleague on a new internal project. He built the initial admin layout, and when I opened it, something felt… off.

The width wasn’t right.

Not obviously broken. Just wrong enough to be annoying.

So I spent several minutes digging through the layout:

• container widths

• padding

• sidebar calculations

• Tailwind classes stacked on Tailwind classes

Eventually I found the issue, but the real question hit me harder:

Why are we still debugging dashboard layouts in 2025?

We had already solved this problem before. Multiple times.

The Real Problem (It Wasn’t the Layout)

The real issue wasn’t that dashboards are hard to build.

It was that:

• We kept rewriting the same TailwindCSS

• We copied files between projects and fixed breakages

• We re-tested mobile responsiveness every time

• Minor inconsistencies kept creeping in across projects

All this before writing a single line of business logic.

That’s when the idea became obvious:

What if the dashboard itself was just… installable?

The Idea: A Reusable Dashboard as an npm Package

Instead of rebuilding or copying layouts, I wanted to:

• Install a package

• Get a consistent admin dashboard structure

• Skip layout and responsiveness setup

• Focus purely on features and logic

Not a design system.
Not a full-blown framework.

Just a solid dashboard foundation.

Building the Dashboard (The Comfortable Part)

I started fresh and rebuilt the dashboard using:

• React

• TypeScript

• TailwindCSS

It intentionally mirrored what we already used internally:

• Same color palette

• Same font face

• Same sidebar/header/content structure

• Same responsive behavior

This part was easy. Familiar. Almost relaxing.

Then I decided to package it.

That’s where things got… spicy.

Turning It into an npm Package (The Humbling Part)

I genuinely thought this would be straightforward.

It wasn’t.

I actually gave up halfway through the first attempt.
Then came back.
Then almost gave up again.

But a new project landed — one that needed the exact same dashboard — and I refused to rebuild it from scratch.

So I pushed through.

“Why Is My Design Broken?” — The Debugging Saga

I packaged the dashboard, installed it into a host project, and…

The layout broke.

Spacing was off.
Styles were missing.
Everything looked almost right — which is the worst kind of wrong.

After a lot of back-and-forth, I realized two key issues:

1. The styles weren’t being bundled correctly

2. The host project wasn’t resolving the style paths properly

This led to a painful loop:

• fix

• build

• publish

• install

• notice something else broke

The package went through several versions.

I think we’re currently on version 8 — the first one I’d confidently call “stable”.

What Finally Worked

Once I slowed down and treated this like a real library (not a side hack), things clicked.

The final approach looked like this:

• Build and test the dashboard normally with React + TypeScript

• Set React as a peer dependency

it is very important to note that you don’t ship React with your library, you share the host app’s React instance

• Clean up the project structure

• Properly bundle styles so they work in consuming apps

• Add a build step

• Publish to npm

Simple in theory. Unforgiving in practice.

A Tiny Usage Example

Once installed, using the dashboard looks something like this:

import { DashboardLayout } from "admin-dashboard";

function App() {
  return (
    <DashboardLayout>
      <h1>Dashboard Overview</h1>
      {/* Your actual features live here */}
    </DashboardLayout>
  );
}

export default App;

That’s it.

Sidebar.
Header.
Responsive layout.

Handled.

Why This Was 100% Worth It

Now, when I start a new project:

• I install the package

• I get a familiar, consistent dashboard instantly

• Mobile responsiveness is already solved

• Styling is no longer a recurring discussion

Most importantly, I get to focus on functionality, not layout déjà vu.

This wasn’t about building a “cool npm package”.

It was about:

• Saving time

• Reducing cognitive load

• Enforcing consistency

• Treating internal tooling like a first-class citizen

Final Thoughts

If you’ve rebuilt the same admin dashboard more than twice, this isn’t a motivation problem.

It’s a systems problem.

And sometimes, the most impactful solution isn’t a new feature —
it’s packaging the thing you’re already tired of rebuilding.

If this sounds familiar, maybe your next productivity win isn’t another refactor…

Maybe it’s your first npm package.