DEV Community: Zarar Ahmed

There is not a single image file in my template store

Zarar Ahmed — Wed, 12 Aug 2026 02:28:11 +0000

I sell Next.js templates. Every product needs cover art, and the obvious way to do that is to screenshot each template, export a few sizes, and ship the images.

I didn't do that. There is no public/images directory in the storefront. No PNG, no JPG, no WebP, no SVG illustration. Every product's cover art is drawn at render time from two numbers and a string in a TypeScript file.

Here is the entire visual configuration for a product:

{
  slug: "ledgerly",
  name: "Ledgerly",
  category: "Dashboard",
  hues: [160, 200],
  motif: "dashboard",
}

hues is a pair of oklch hue angles. motif picks which abstract layout to draw.

Why bother

The honest answer is that I was avoiding a chore, and it turned into an architecture decision.

Screenshots rot. Every time I changed a template's hero section, its cover art was subtly wrong. I'd have to re-shoot, re-export, re-optimise, re-upload. With eight products that's a small job I would do badly and late.

Drawing the art from data removed the chore entirely. Adding a template is now one object in a catalog file, and the art comes with it.

The side effects turned out to matter more than the thing I was avoiding:

Nothing to lay out badly. No image means no intrinsic size to guess at, so no layout shift while covers load.
Nothing to download. The covers cost zero network bytes. They're DOM nodes with inline styles, compressed along with the rest of the HTML.
Rebranding is a find-and-replace. Changing a product's palette is editing two integers.

The part that actually makes it work: oklch

If you do this in HSL, you get a mess. hsl(60 80% 50%) — yellow — is visually much lighter than hsl(240 80% 50%) — blue — even though both claim 50% lightness. So a card generated at hue 60 looks washed out next to one at hue 240, and you end up hand-correcting every product. At which point you have not saved yourself anything.

oklch() is perceptually uniform: the same lightness value looks like the same lightness to a human eye across every hue. That is the single property that makes generated art viable, because it means one set of lightness and chroma values works for every product, and only the hue changes.

The whole color system is one helper:

const o = (l: number, c: number, h: number, a?: number) =>
  a === undefined ? `oklch(${l} ${c} ${h})` : `oklch(${l} ${c} ${h} / ${a})`;

And then everything is expressed relative to the product's two hues:

<span
  className="h-4 w-12 rounded-full"
  style={{
    background: `linear-gradient(90deg, ${o(0.6, 0.2, h1)}, ${o(0.65, 0.16, h2)})`,
  }}
/>

0.6 lightness and 0.2 chroma are tuned once, by eye, on one product. They then look correct on all of them. That is the entire trick.

Motifs, or: don't draw the template, evoke it

The second decision was what to actually draw.

The temptation is to render a tiny faithful replica of each template. Don't. It's enormous work, it looks like a broken screenshot at small sizes, and it drifts out of date exactly like the screenshots you were trying to avoid.

Instead each motif is an abstract arrangement of blocks suggesting a kind of interface. The dashboard motif is a narrow sidebar, a row of stat tiles, and a bar chart:

<div className="flex min-h-0 flex-1 items-end gap-1 rounded-md bg-white/[0.04] p-2">
  {[38, 62, 48, 78, 58, 88, 70, 95, 64, 82].map((height, i) => (
    <span
      key={i}
      className="flex-1 rounded-sm"
      style={{ height: `${height}%`, background: /* … */ }}
    />
  ))}
</div>

Those bar heights are hardcoded. They're not data, they're composition: a shape chosen because it reads as "chart" at 300px wide. Random heights look like noise; a designed sequence looks intentional.

Neutral elements use plain white at low alpha (bg-white/[0.06]) rather than the brand hue. If everything is tinted, nothing reads as accent. The hues are spent only where they carry meaning: the active nav item, the primary button, the chart.

Each motif sits inside a shared browser frame which does a lot of work for very little code. It tells you "this is a website" instantly, so the abstract shapes inside are read as an interface rather than as decoration.

When this is a bad idea

It works here because I'm selling interfaces, and interfaces are made of rectangles. Abstract rectangles evoke them honestly.

It would be a terrible approach for a photography portfolio, an illustration marketplace, or anything where the specific visual content is the product. You cannot procedurally generate a photograph, and you shouldn't try.

There's also a real trade-off I accepted: a generated cover tells you the category, not the design. It can't sell the actual template. That's fine for me because every product links to a complete live demo, so the cover only has to get someone to click. If you have no demo, a real screenshot is probably doing more work than a pretty abstraction.

The takeaway

If your product art is systematic — categories, tiers, types — consider whether it can be derived from data instead of drawn by hand. You get consistency for free, and adding a product stops involving a design task.

Start with oklch. Without perceptual uniformity you'll spend all the time you saved hand-correcting colors.

I write this stuff while building Nocturne, a store of dark, animation-heavy Next.js templates. The free starter is MIT and has the same token system if you want to poke at it: github.com/Rucs0/nocturne-ember.

I built a storefront that works with zero API keys, and it made the code better

Zarar Ahmed — Sun, 19 Jul 2026 15:33:42 +0000

I sell Next.js templates. The store takes payments through Stripe, stores orders in Postgres, keeps ZIPs in object storage, and emails download links through Resend.

It also runs perfectly with none of those configured. Clone it, npm install, npm run dev, and you get a working storefront: you can browse the catalog, "buy" a template, and download a real ZIP file. No .env. No accounts. No
keys.

That started as a convenience. It turned into the single best architectural decision in the codebase, and it's the reason I can hand the repo to someone and have them productive in ninety seconds.

The rule

Every integration is optional and independently detected. That's the whole idea, and it lives in about eight lines:

export const integrations = {
  db: Boolean(process.env.DATABASE_URL),
  stripe: Boolean(process.env.STRIPE_SECRET_KEY),
  s3: Boolean(
    process.env.S3_BUCKET &&
    process.env.AWS_ACCESS_KEY_ID &&
    process.env.AWS_SECRET_ACCESS_KEY,
  ),
  email: Boolean(process.env.RESEND_API_KEY),
};

/** True when Stripe isn't configured - checkout simulates a purchase. */
export const demoMode = !integrations.stripe;

Note that these are four independent booleans, not one NODE_ENV check and not a single DEMO=true flag. That distinction is what makes it useful rather than cute. You can run with a real database and no Stripe. Or real Stripe and no object storage. Each combination is a valid, working configuration, because every consumer degrades on its own.

What "degrades" actually means

The temptation with a flag like this is to throw a banner up and disable things. That's not degradation, that's a broken site with an apology on it. The rule I settled on: the user-visible flow must complete. Not just "show an
error nicely".

No database. The product catalog is a TypeScript file. When a database is connected it mirrors that catalog into a table and lets rows override commerce fields — price, name, active. When it isn't, the catalog is the data:

export async function getProducts(): Promise<Template[]> {
  const db = getDb();
  if (!db) return listedTemplates;
  try {
    const rows = await db.query.products.findMany();
    if (rows.length === 0) return listedTemplates;
    // ...merge DB overrides onto the static catalog
  } catch (err) {
    console.error("products: falling back to static catalog:", err);
    return listedTemplates;
  }
}

The catch matters more than the if. A database that's configured but unreachable degrades to exactly the same place as a database that was never configured. Production has been down to that path during a Postgres restart
and the store stayed browsable.

No Stripe. Checkout signs a short-lived access grant and redirects to the success page, which is the same page a real purchase lands on. You get the same confirmation, the same download button, the same email prompt. Two hours
of validity instead of a permanent entitlement, and every token is stamped demo: true so nothing downstream can mistake one for a real sale.

No object storage. This is my favourite one, because the honest answer was harder than the lazy one. The lazy version returns a 404 or a text file named template.zip. The download is the product; a fake download makes the whole demo worthless.

So the repo contains a small ZIP writer — about 190 lines, store method, no compression — that generates a valid archive on the fly:

// Fixed DOS date: 2026-01-01, so archives are byte-stable.
const DOS_DATE = ((2026 - 1980) << 9) | (1 << 5) | 1;

You get a real .zip that a real unzip program opens, containing a README explaining that storage isn't configured. It is genuinely a working download,
which is the point.

That writer earned its keep later. Every real download now streams the ZIP through the app and injects a per-buyer license file, using the same code to append a stored entry to an existing archive without recompressing it. I
wouldn't have written a ZIP encoder to solve watermarking. I wrote it to make demo mode honest, and watermarking came free.

No email. Here the degradation is deliberately not transparent, and it's worth explaining why.

The library flow, enter your email and get a magic link to your purchases, sends the link to the address on file. That's the entire security model: having the link is tied to controlling the inbox. With no mail provider, "degrading gracefully" would mean returning the link in the HTTP response, and that would hand anyone the library for any address they can spell.

So this one fails closed, and it fails identically for every input:

if (!integrations.email) {
  return NextResponse.json(
    { error: "Library links are temporarily unavailable. Please contact support." },
    { status: 503 },
  );
}

The same endpoint also returns an identical response whether or not an address has purchases, so it can't be used to enumerate who my customers are.

That's the real lesson. Demo mode is not "make everything work anyway." It's "decide, per integration, what the honest fallback is" — and sometimes the
honest fallback is a clean refusal.

What it bought me

Onboarding is npm install. No credential-sharing ritual, no .env.example scavenger hunt to get a first page render.

Most development doesn't touch a paid API. Building the checkout UI, the success page, the library, the download flow — none of it needs Stripe keys. Test-mode webhooks are for verifying the integration, not for laying out a
button.

Failure paths are the default path. This is the one I didn't anticipate. In a normal codebase the "database is down" branch is written once, never executed, and quietly rots. Here it's the branch that runs every time I start
the dev server. It cannot rot, because it's the one I use most.

It forced a real answer about the source of truth. "What happens with no database?" is unanswerable if the database is the product data. Making demo mode work meant deciding that code is canonical and the database holds
overrides. That's a better architecture, and I only reached it because the constraint refused to let me be vague.

What it costs

Two things, honestly.

Every integration point needs a branch, and each branch is a decision, not a default. Four integrations across roughly 5,500 lines is very manageable.
Twenty would not be.

Unexercised branches can lie. The fallback paths run constantly in development, but the real paths only run in production. I've shipped a bug where the demo path worked and the real one didn't — the mirror image of the
usual problem, and just as annoying. Demo mode is not a substitute for integration tests against the real thing.

The tradeoff has been overwhelmingly worth it, but "every integration is optional" is a discipline with a running cost, not a free lunch.

The bit I'd steal for any project

Skip the storefront specifics — the transferable idea is one sentence:

Detect each dependency independently, and define an honest fallback for each one, where "honest" sometimes means refusing.

Not one DEMO flag. Not NODE_ENV === "development". A boolean per integration, and a real decision about what the product does without it. You'll end up with software that runs anywhere, onboards in one command, and —
because the degraded paths are the ones you use daily — degrades correctly when it counts.

I built Nocturne, a small collection of dark, animation-heavy Next.js templates. The free starter, Ember, is MIT on GitHub
and uses the same design system — no email required, though there's a form if you'd rather have the ZIP.