Grimoire Stack

A spooky SaaS skeleton that lets you build multiple production-ready apps from a single shared core.

Comment

Inspiration

Kiroween’s Skeleton Crew theme made me ask a simple question:

What if I could build internal tools the way you build Halloween costumes – reuse the same skeleton, then change the outfit?

Every hackathon I end up rebuilding the same stack over and over: auth, layouts, dashboards, CRUD, design system, docs. I wanted to prove that with the right skeleton, I could ship multiple production-feeling apps in the time most people build one.

That became Grimoire Stack – a spooky, reusable SaaS skeleton for internal tools, dashboards, and CRMs.

What it does

Grimoire Stack is a monorepo skeleton plus two fully working apps:

  • Skeleton Core – shared library with:

    • 15+ reusable UI components (buttons, cards, navigation, layout shells)
    • React hooks and utilities
    • Shared Prisma models and DB helpers
    • Auth + theming + layout primitives

  • Haunted Tasks – team task dashboard with a 3-stage workflow:

    • Summoned → In Ritual → Banished
    • Assign tasks, track progress, and filter by status in one view.

  • Coven CRM – lightweight CRM with a 4-stage pipeline:

    • Familiar → Enchanting → Bewitched → Vanished
    • Track contacts, deals, notes, and their progress through the funnel.

Both apps share the exact same skeleton (design system, layouts, auth, DB patterns) but implement completely different business logic. Roughly ~38% of the codebase is reusable infrastructure, which let me build the second app much faster than the first.

Everything runs inside an elegant, dark Halloween UI that still feels like something a real team could use.

How I built it

I designed the skeleton first, then layered apps on top:

  1. Specs & steering docs with Kiro + MCP
  • I used Kiro AI and a custom MCP server to drive a spec-first workflow.
  • In .kiro/steering/* I defined:
    • Product vision (who the skeleton is for and why it exists)
    • Technical architecture (monorepo layout, shared core, app boundaries)
    • Code structure and UI style guide.
  • In .kiro/specs/*/requirements.md I wrote structured requirements for:
    • skeleton-core
    • haunted-tasks
    • coven-crm
  • The MCP server exposes endpoints like:
    • Get theme tokens – programmatic access to colors/spacing/typography.
    • Generate app blueprints – starter structure for new apps (e.g. inventory, events, wiki).
    • Validate structure – check whether an app follows the skeleton pattern.
  1. Skeleton Core
  • Built a shared library containing:
    • Layout components (app shell, sidebar, top nav)
    • Table/list views, forms, and status badges
    • Empty states with ghostly flavor
  • Centralized design tokens so both apps automatically inherit the same styling.
  1. Hooks & automation

I wired up a set of Kiro hooks (agent workflows) around the repo, for example:

  • Auto-regenerate skeleton documentation when core components change.
  • Generate app summaries so docs stay in sync with features.
  • Run linting and sanity checks on save.
  • Trigger Prisma generate whenever the schema changes.
  • Validate imports to ensure apps correctly consume skeleton-core.

These hooks, plus the MCP endpoints, turned the skeleton into something I could iterate on very quickly.

  1. Apps on top of the skeleton
  • Created two Next.js apps under apps/haunted-tasks and apps/coven-crm.
  • Reused skeleton-core components everywhere, only adding pages and domain logic.
  • Extended the shared Prisma schema with app-specific entities (tasks, boards, contacts, pipelines).
  1. Tooling & tests
  • Used Next.js + React + TypeScript for the frontends.
  • Styled everything with Tailwind CSS and a spooky but professional palette.
  • Added Vitest tests for core utilities and business logic.

Challenges I ran into

  • Defining a real skeleton, not just a template.
    It’s easy to copy a starter; it’s harder to decide what truly belongs in a shared core versus what should live in each app. I refactored several times to keep the skeleton generic but still useful.

  • Shipping two apps on a hackathon deadline.
    Building two fully functional apps is ambitious. The only way it worked was committing to the skeleton pattern early and forcing myself to reuse components instead of “just duplicating it this once.”

  • Monorepo complexity.
    Managing shared types, Prisma models, MCP hooks, and local dev across multiple Next.js apps led to a few “why does this import only break in this app?” debugging sessions.

Accomplishments I’m proud of

  • I shipped two working apps (tasks + CRM) that:
    • Share layouts, UI components, auth, and styling.
    • Have completely different workflows and domain logic.
  • I proved the skeleton pattern actually saves time once the core is solid.
  • I treated this like a real product, not just a demo:
    • Steering docs, specs, and implementation guides.
    • A consistent design system and polished UI.
    • Hooks + MCP integration to keep code and docs from drifting apart.

What I learned

  • Investing early in infrastructure and design systems pays off, even in a short hackathon.
  • Spec-driven development with tools like Kiro + MCP makes it much easier to stay organized when you’re juggling multiple apps.
  • AI is most helpful when it’s embedded into a workflow (hooks, codegen, doc sync), not just used ad-hoc.

What’s next for Grimoire Stack

This is just the first version of the skeleton. Next steps I’d like to explore:

  • Add more app templates (inventory, events dashboard, internal wiki).
  • Swap SQLite for Postgres and ship true multi-tenant org support.
  • Publish skeleton-core as a package so other teams can bootstrap internal tools quickly.
  • Push the MCP + hooks idea further: built-in automation for task triage, CRM enrichment, and analytics on top of the skeleton.

I want Grimoire Stack to become the spooky starter kit you grab when you need a serious internal app in hours, not weeks.

Built With

Share this project:

Updates