DEV Community: AIVCJ studio

Personal or Commercial licence: which one for a client site?

AIVCJ studio — Tue, 10 Nov 2026 14:40:53 +0000

For one website for one client, the Personal licence is enough. You can build it, charge the client for your work and hand it over. If you will use the same theme for a second client, or inside a product people pay to use (a SaaS, an app, a paid tool), you need the Commercial licence.

That covers most cases. The rest of this page answers the ones in between, using the exact terms on our License Agreement.

The difference in one table

	Personal	Commercial
End products	One, for you or for one client	As many as you like, for you and any number of clients
A product you sell to many users (SaaS, app, paid product)	No	Yes
Charge your client for your work	Yes	Yes
Resell or share the files	Never	Never

An end product is the finished thing: one website or one app. Staging and production copies of that same site count as one.

Questions agencies ask us

I'm building one site for a client. They pay me, not you. Is Personal fine?
Yes. Personal covers one site for one client, and you can charge them for your work. Buy one Personal licence per client site.

I'll probably use this theme for three clients this year.
Then Commercial is the better buy. It covers every client project, now and later, and you can record each project in your account to get a licence certificate for that client.

My client wants the source code.
They get the finished site you built for them. They may not take the theme's files out of it and reuse them on another site. That rule is the same for both licences.

We're a team of five. Does everyone need a licence?
No. The licence belongs to the buyer: you, or your company if you bought for it. Everyone working for that company may use it.

I'm building a SaaS on top of a dashboard kit like AURORA.
That needs Commercial. Your customers pay to use the product, which is exactly the case Personal excludes.

Can I make my own template from it and sell that?
No, with either licence. You can't sell or share the files, change them and resell them, or make a product whose main value is the item itself (another theme, template or UI kit).

Do updates cost extra?
No. Both licences get every update we publish, from your account.

How does my client know the licence is real?
Every purchase has a licence key (PULSE-XXXX-XXXX-XXXX). Your client can check it on our site; the check shows the item and the licence type, never your personal details.

Before you buy

Sales are final once the files are delivered, so try first. Every theme has a live demo, for example Lunetta, and our pricing page shows both prices side by side. If the files don't work as described, we fix them or replace them.

Not sure which one fits your project? Write to us with a sentence about it. We'll tell you honestly, including when the cheaper one is enough.

First published on Pulse by AIVCJ.

How to re-brand a Next.js SaaS kit from one file

AIVCJ studio — Tue, 10 Nov 2026 14:40:52 +0000

Open src/config/theme.ts, change accent to your brand colour, and save. In AURORA that one value re-colours the marketing site and the dashboard: buttons, links, focus rings, soft fills, glows, the first chart line and the hero light. This guide shows what to change, why it works, and the two things to check before you ship.

AURORA is our AI SaaS kit on Pulse. We built it so that a buyer's first job, making it look like their product, takes minutes instead of a day of hunting through components.

Before you start

You need the kit running locally (npm ci, then npm run dev; the Documentation folder in the download walks through it). Have your brand colour as a hex value, and a second colour from the same family for the gradient.

Step 1: change the theme file

This is the whole file a buyer edits (shortened here; the real file explains every value in a comment at the top).

// src/config/theme.ts
export const theme = {
  accent: "#7458F7",     // your brand colour
  accentTo: "#56CCF2",   // the gradient fades from accent into this
  onAccent: "#FFFFFF",   // text on a solid accent button
  radius: 12,            // corner roundness in px (0 = sharp, 20 = soft)
  fonts: { display: "geist", body: "inter" },
  defaultMode: "dark",   // or "light"; visitors can still switch
  showThemeDial: true,   // the "Try your colour" swatches in the hero
};

Save, and the dev server reloads with the new colour everywhere. There is no second place to change it.

Step 2: check the text on your buttons

onAccent is the colour of text on a solid accent button. It has to stay readable. The rule we follow is the WCAG one: at least 4.5 to 1 contrast for normal text.

Here are AURORA's own presets, with the ratio each one gets:

Accent	Text on it	Contrast
Violet `#7458F7`	white	4.69 : 1
Cobalt `#2F6BEF`	white	4.70 : 1
Rose `#D4365F`	white	4.67 : 1
Aurora green `#1FC8A0`	near-black `#04140F`	8.84 : 1
Amber `#F5A524`	near-black `#1A1204`	9.09 : 1

Light, bright accents like green and amber fail with white text (about 2 : 1), so they get near-black text instead. If your brand colour is light, do the same. Any contrast checker will give you the number; aim for 4.5 or more.

Step 3: remove the colour dial before you launch

showThemeDial: true shows six swatches in the hero so people trying the demo can see the kit in other colours. Your customers don't need it. Set it to false and the swatches and their small script are gone.

Why one value is enough

The trick is that nothing else in the kit names a colour. Everything is derived from the accent in one stylesheet:

/* src/app/globals.css (shortened) */
:root {
  --accent-soft: color-mix(in oklab, var(--accent) 14%, transparent);
  --accent-line: color-mix(in oklab, var(--accent) 45%, transparent);
  --accent-glow: color-mix(in oklab, var(--accent) 50%, transparent);
  --aurora: linear-gradient(100deg, var(--accent),
    color-mix(in oklab, var(--accent), var(--accent-to)) 55%, var(--accent-to));
}

color-mix() blends two colours in the browser. Mixing in oklab keeps the blends looking even, so a 14% tint of rose looks as light as a 14% tint of blue. Components only ever use --accent-soft, --accent-line and the rest, never a hex value.

The root layout writes your theme.ts values into :root once, on the server, so the first paint is already in your colour. No flash of violet before your brand loads.

How the live colour change animates

The demo's dial changes the colour smoothly over 0.6 seconds. Normally a CSS variable can't animate: the browser doesn't know it is a colour, so it jumps. Registering it tells the browser its type:

@property --accent { syntax: "<color>"; inherits: true; initial-value: #7458f7; }
:root.dial-anim { transition: --accent 0.6s ease, --accent-to 0.6s ease; }

The dial adds the dial-anim class, sets the new values, and removes the class 0.7 seconds later. If the visitor has reduced motion turned on, it skips the class and the colour changes at once.

You can use the same three lines in any project that keeps its brand colour in a CSS variable.

Dark mode, for free

Colours that differ between light and dark are written once with light-dark():

--accent-text: light-dark(
  color-mix(in oklab, var(--accent) 78%, #000),
  color-mix(in oklab, var(--accent) 58%, #fff)
);

Accent-coloured text is darkened on light backgrounds and lightened on dark ones, from the same accent. You never pick a separate "dark mode brand colour", and the two modes can't drift apart.

What it doesn't do

It doesn't change your product name, logo, fonts beyond Geist and Inter, or images. Those are separate steps in the README: the name lives in src/content/site.ts, the logo files in public/assets/, and other fonts load through next/font/local. It also can't make a colour accessible for you; Step 2 is still your job.

If you want to see it before you buy, the dial is live on the AURORA demo. Pick a swatch and watch the dashboard follow.

First published on Pulse by AIVCJ.

What broke when we set up our own templates as a buyer

AIVCJ studio — Tue, 10 Nov 2026 14:40:51 +0000

Most of it worked. All 15 zips installed and built on a clean machine. But we found three packages that were far bigger than they should have been, missing setup docs, a licence file that named the wrong licences, and five bugs a buyer would have hit on their first day. This is the list, with the fixes.

We sell themes and kits on Pulse. Until last week we tested each one as its builder: in the project folder, with our own tools around it. A buyer gets something else. They get a zip, a fresh machine and a README. So we stopped testing the project and started testing the zip.

How we tested

We wrote one script that does what a buyer does, in order, for every product in the store:

Unzip the download into an empty folder.
npm ci, then a type check.
npm run dev and open the home page.
npm run build, then npm start.
Open up to 10 pages at 360, 768, 1280 and 1536 pixels wide, with reduced motion on.
Compare every page with the hosted demo the buyer saw before paying.

It ran on two Node versions, 24.22 and 22.23, because buyers don't all update at the same time. That came to 348 page checks, each compared with the live demo. We also loaded the pages again with the clock set a year ahead, which found a bug we would never have seen.

What was wrong with the zips

Build folders in the download. Three zips carried our local build output (.next-check and .next-dev). Sorted was 77.2 MB. After the fix it is 1.2 MB. Maun went from 22.9 MB to 7.0 MB. A buyer would have downloaded tens of megabytes of files that were useless to them.

Our own files. Some zips had our internal check scripts, a .forge.json, TypeScript build caches and a package name of dp-theme. None of that is harmful, but it is noise, and it tells a buyer nobody looked inside the zip.

The wrong README. Three products shipped our starter kit's README instead of their own. A buyer opening the folder would read about a different project.

No licence file, or the wrong one. Most zips had no licence file. AURORA had one, but it said "Single" and "Unlimited". Pulse sells Personal and Commercial licences, so the zip and the store disagreed.

The fix was one packaging script that every product now goes through. It copies only what the buyer needs, writes the product's own README, adds the Pulse LICENSE.txt, adds .env.example when the code reads environment variables, checks the lockfile matches package.json, and sets engines to Node 20.9 or newer, so npm warns a buyer whose Node is too old.

Five bugs a buyer would have hit

1. A page that scrolled sideways on phones. Lunetta's cabins page moved 250 px to the right at 360 px wide. The table had its own scroll area, but the hidden labels for screen readers sat outside it and stretched the page. The hosted demo had the same bug. We moved the labels inside the scroll area.

2. and 3. Two smaller sideways scrolls. Peel's home page by 8 px (a flag on the map) and Sorted's pricing row by 3 px. Small, but on a phone it feels like the page is loose.

4. A chart label that broke hydration. AURORA's dashboard showed React error #418. The server drew a chart axis label as $0 and the browser drew $0.0. Both are fine on their own. When they differ, React throws away the server HTML and redraws the page. The label went through a compact number format, and Node and the browser did not agree on it. We now pick one explicit format per axis, with fixed decimals, so both sides print the same text.

5. Dates frozen at build time. This is the one the year-ahead load found, in three products. The swatch-test theme shows delivery dates, and the two résumé themes show "this year". Those were written into the HTML when the site was built. Open the site on a later day and the browser computes a different date than the HTML says, and React throws #418 again. A buyer who built the site once and visited it next month would have seen it. We now compute those dates in the browser after the page loads.

Setup docs in every zip

Each download now has a Documentation/index.html that works offline. It walks through six steps, from unzip to a live site, with diagrams of what happens at each step, real screenshots of the product, a tour of the pages, fixes for the problems people usually hit, credits for fonts and images, and how to reach us. It reads well on a phone too.

We checked the guide the same way as the products: 15 guides at 4 widths in light and dark mode, 120 checks, nothing failing.

The numbers after the fixes

	Before	After
Largest zip	77.2 MB (Sorted)	25.2 MB (Lunetta)
Zips with our build folders inside	3	0
Zips with the product's own README, Pulse licence and setup guide	none had all three	15 of 15
Products with a bug a buyer would hit	7	0 (plus 1 one-off we could not repeat)

Second round: 14 of 15 products had zero snags. Playable Résumé showed one #418 once on its home page at 360 px, and not again in 31 tries. We are still watching it.

What we'd tell anyone selling templates

Test the download, not the project. Your project folder has things the buyer's never will, and it hides exactly the bugs they hit first. Set the clock forward a year at least once. And read your own README as if you had never seen the code.

Every Pulse download, including AURORA and Lunetta, is now built by this packaging script. If something still doesn't work as described, write to us and we fix it.

First published on Pulse by AIVCJ.