Hermes

Absolutely — and here's the good news: you don't rebuild it. That portal in the video is a shipped example. You copy its _custom/ folder, change exactly two things — your data model and your brand — and run it from Seed Data, just like the video. Two-thirds of the work already exists.

One note on process: in theory, for a brand-new or complex model I'd send you to Athena first — she'd write a quick PRD and hand the spec back to me. In practice, an invoice portal is well-trodden ground, so let's go direct. If we hit anything gnarly, we loop Athena in.

Start from the shipped example. It lives at _apps/flowkraft/99-custom/_examples/billing-portal-grails/_custom/. A custom app is just four things — copy them to your own folder and edit in place:

Copy the example's _custom/ to _apps/my-billing-portal/_custom/. Everything unchanged — the Grails build, Dockerfile, layouts, theme picker, payments — comes from the grails-playground blueprint at scaffold time. You never fork the whole app; overrides/ holds only the files you actually touch.

That maps almost 1:1 onto the example's bp_* model. There are three touch-points, all in overrides/, all following the existing pattern:

1. The domain — overrides/grails-app/domain/com/flowkraft/Invoice.groovy (plus Customer/InvoiceLine). Add your fields.
2. The REST ingest — ApiInvoiceController at POST /api/invoices/ingest. It upserts the customer by email and the invoice by number; add your new fields to the payload it accepts.
3. The push query — in app-seed.groovy's writePushReport, the SQL that reads your source rows and maps columns → the ingest payload.

The domain — add vatId and you're done:

DataPallas bursts your source invoices and curls each one to /api/invoices/ingest — the portal renders them. So the model, the ingest, and the push SQL just have to agree on field names. Add vat_id to the ingest payload and to the writePushReport query, and every invoice carries your VAT id end to end.

Three small edits, all in overrides/. It's daisyUI 5 + Tailwind 4, so a whole re-theme is one word:

1. Theme — views/common/_themeInit.gsp: set RB_DEFAULT_THEME = 'corporate'. daisyUI ships corporate, business, nord… — corporate is the clean light one.
2. Logo / wordmark — views/layouts/portal.gsp + admin.gsp: swap the DataPallas logo for your mark.
3. Invoice biller — views/_invoiceDocument.gsp: your company name + address.

The badge uses theme colours (bg-primary text-primary-content), so it recolours with the theme automatically. That's the whole re-skin — one theme word, one badge letter, one company name. The DOM ids don't change, so it stays automation-friendly.

Here's your _custom/ — drop it at _apps/my-billing-portal/_custom/. The identity lives in app.json:

app-seed.groovy and overrides/ you carried from the example with your two edits (the vatId field and the Acme brand); the README.md is the recipe. Nothing else to write — the seed script does the scaffolding and writes the push report on its own.

Exactly. Open DataPallas → any database connection → Seed Data tab → run Acme Freight — Billing Portal. The script scaffolds the app, writes the push report, and reveals the app card. Then:

1. Apps Manager → your card appears → Start (Docker) → Launch → /portal and /admin.
2. Processing → Generate Reports → pick Billing Portal Push (Acme) → Burst.
3. Your source invoices flow over REST into the portal — customers log in and pay, admins do CRUD. Auto-created logins, correct statuses, no duplicates on re-run.

Same one-click feel as the video — but your data model, your brand.

Anytime. Notice what you didn't do: you never left daisyUI/Tailwind, never touched the plumbing, never hand-deleted sample code. Two edits and a Seed-Data run.

If you later want the identical portal in React instead of Grails, my colleague Apollo ships the same thing on Next.js — same routes, same DOM ids, same seeded data. Go build.