DEV Community: Gautam

Why I built Inktag — a ``-shaped tag that locks AI images to your brand

Gautam — Sun, 17 May 2026 20:20:26 +0000

The moment I gave up on stock photos

In January I pulled my image invoices for the prior year. Shutterstock, Unsplash+, the occasional Getty one-off.

$387. For pictures of "diverse team smiling at laptop" and "hands typing on MacBook keyboard."

The thing that bugged me wasn't the money. It was that my blog looked like every other blog on the internet using the same three stock sites. I'd written 40-something posts that year and not one of them looked like mine.

So I switched to AI image gen for everything. Midjourney first, then gpt-image-1 when it launched, then a flux model on fal. And I hit a different wall.

The actual problem with AI images for content sites

It's not quality. Quality is genuinely fine now. The problem is consistency across generations.

I'd write Monday's post and prompt for "a moody wine cellar at golden hour." I'd get back something painterly, warm, beautiful.

I'd write Thursday's post and prompt for "a busy coworking space." Same model, same week. I'd get back something that looked like a different photographer, different palette, different century.

Open my blog homepage and the cards looked like four people had designed the site.

The model has no idea what my brand is. It can't. Each prompt starts from zero. So the surface area for drift is enormous — palette drifts, lighting drifts, that weird AI gloss appears and disappears, sometimes there are people, sometimes there aren't.

I tried the usual fixes:

Reference image + prompt every time. Tedious. And it still drifts after three or four generations because the reference signal is weak relative to the prompt.
A LoRA fine-tuned on my brand. Works, kind of, but now I'm retraining every time I want to tweak the vibe. And it's $$$.
Style presets in Midjourney. Closer, but it lives in a Discord channel, not in my codebase. There's still a human prompting step. I want this in the build pipeline.

None of them put the brand somewhere the model couldn't override.

What I actually wanted

A tag. A React component that took a prompt as a prop. And a config file — set once — that locked the parts the model isn't allowed to choose.

// brand.config.ts — set ONCE per site
export default {
  palette: ["#4a1a14", "#8a3a2a", "#d8a878", "#f0e0c0"],
  style:   "editorial photography, warm low contrast, 35mm",
  aspect:  "16:9",
  format:  "webp",
  neverInclude: ["text overlays", "watermarks", "human faces"],
};

// any blog post — varies per post
<Inktag prompt="a wine cellar at golden hour" />
<Inktag prompt="a busy coworking space at 6pm" />

The shape of the API is the point. The model isn't asked "what should this image look like?" It's only asked "what's the subject?" Everything else is locked at the config layer, before the prompt assembly.

If you imagine the prompt the model actually sees, it's roughly:

[brand style block — fixed]
[palette constraint — fixed]
[aspect — fixed]
[negative prompts: things never to include — fixed]
[subject from <Inktag prompt="..."> — varies]

The brand block is 80% of the prompt by token count. The subject is the last 20%. Drift on the things I care about (palette, style, banned elements) is structurally impossible because they're never up for negotiation.

The part I didn't expect to need

I shipped a v0 that just assembled the prompt and called one provider. It mostly worked. But "mostly" is doing a lot of work there.

Sometimes the model would slip a face into the image even with "no human faces" in the negative prompt. Sometimes the palette would drift on a particular subject (cellars came out the right warm; coworking spaces came out cold blue every time).

So I added a second pass: after generation, run a vision check against the same constraints. Palette histogram has to be within X of the brand palette. No banned elements detected. If it fails, regenerate.

const image = await router.generate(assembledPrompt);
const check = await vision.audit(image, brand);

if (!check.passes) {
  return router.generate(assembledPrompt, { avoid: check.failures });
}

About 8% of generations regenerate. The user never sees the failed one. From the React tag's perspective, you always get back an image that passes the brand check, or it errors loudly.

The part I really didn't expect to need

Cost.

A naive implementation calls the image API on every page render, which is insane. So there's a cache, keyed on (brand config hash, prompt, aspect, format). First render is slow (~2s), every subsequent render of the same <Inktag> instance is ~100ms from R2.

In the last week of beta:

2,341 image requests
184 unique renders (the rest were cache hits)
~92% cache hit rate
Average cost per unique render: $0.015, down from ~$0.042 when I was on a single provider

The 64% cost drop came from routing between providers per-render based on the aspect, the brand style affinity, and current p95 latency. None of those numbers came out of theory — they came out of generating the same 30 prompts across every provider on a Saturday and ranking the results by hand.

Who this is for, and who it isn't

It's for content sites with a brand. Blogs, docs sites, marketing sites, newsletters that publish on a schedule and want their hero images to look like they came from the same place.

It is not for:

One-off images (Canva is faster)
Memes (the constraints fight you)
Sites without a brand yet (figure out the brand first, then come back)

That's a real filter. The thing I had to internalize building this is that constraints are the product. If you don't have constraints to lock, there's nothing to lock.

What's in beta and what's next

Working today:

React SDK (<Inktag prompt="..." />)
Brand config + dashboard
Multi-provider routing (OpenAI / fal / Replicate, with Nano Banana on deck)
Post-generation vision check
R2-backed cache

On deck:

Vue and Svelte SDKs
Self-hosted cache option (point it at your own S3/R2)
Public pricing

The beta is at inktag.io — no card, ~200 seats, I'm hand-picking by use case so I can actually reply to people. Reach out if the "every post looks like a different blog" thing resonated.

If you're building in this space or have thoughts on the API shape, I'd love to compare notes in the comments. Especially curious whether anyone else has landed on a different way to keep AI images on-brand across generations — I'd genuinely like to know what I missed.

— Gautam

How I Built a Multi-Tenant Documentation Platform with Next.js 15 (Subdomain Routing, MDX, and ISR)

Gautam — Sun, 22 Feb 2026 22:48:24 +0000

I recently built Dokly, a documentation platform where users get instant subdomains (like acme.dokly.co) for their docs. Think Mintlify/GitBook but affordable.

Here's the technical deep-dive on how multi-tenant subdomain routing works in Next.js 15, including the gotchas that took me days to figure out.

The Architecture Challenge

The goal was simple: one Next.js app serving multiple purposes:

dokly.co           → Marketing site
app.dokly.co       → Dashboard (auth, editor)
*.dokly.co         → User documentation sites
docs.acme.com      → Custom domains (Pro feature)

All from a single deployment. No separate apps. No complex infrastructure.

The Secret: Middleware Routing

Next.js middleware intercepts every request before it hits your pages. We use it to rewrite URLs based on the hostname.

// middleware.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  const hostname = request.headers.get("host") || "";
  const pathname = request.nextUrl.pathname;

  const baseDomain = "dokly.co";

  // Skip static files and API routes
  if (
    pathname.startsWith("/_next") ||
    pathname.startsWith("/api") ||
    pathname.includes(".")
  ) {
    return NextResponse.next();
  }

  // Marketing site: dokly.co
  if (hostname === baseDomain || hostname === `www.${baseDomain}`) {
    return NextResponse.next(); // Uses app/(marketing)/
  }

  // Dashboard: app.dokly.co
  if (hostname === `app.${baseDomain}`) {
    return NextResponse.rewrite(
      new URL(`/dashboard${pathname}`, request.url)
    );
  }

  // User docs: *.dokly.co
  if (hostname.endsWith(`.${baseDomain}`)) {
    const subdomain = hostname.replace(`.${baseDomain}`, "");
    return NextResponse.rewrite(
      new URL(`/sites/${subdomain}${pathname}`, request.url)
    );
  }

  // Custom domain - lookup in database
  const response = NextResponse.rewrite(
    new URL(`/sites/_custom${pathname}`, request.url)
  );
  response.headers.set("x-custom-domain", hostname);
  return response;
}

File Structure That Makes It Work

The App Router's route groups are perfect for this:

app/
├── (marketing)/          # dokly.co (route group, no URL prefix)
│   ├── page.tsx          # Landing page
│   ├── pricing/page.tsx  # Pricing
│   └── layout.tsx        # Marketing layout
│
├── (dashboard)/          # app.dokly.co
│   ├── dashboard/page.tsx
│   ├── project/[id]/
│   │   └── editor/[pageId]/page.tsx
│   └── layout.tsx        # Auth-protected layout
│
└── sites/[subdomain]/    # *.dokly.co (user docs)
    └── [[...slug]]/page.tsx  # Catch-all for all doc pages

The parentheses in (marketing) and (dashboard) create route groups - they organize code without affecting the URL structure.

The Catch-All Route for Docs

Every user's docs site uses the same dynamic route:

// app/sites/[subdomain]/[[...slug]]/page.tsx
import { notFound } from "next/navigation";
import { createClient } from "@/lib/supabase/server";
import { renderMDX } from "@/lib/mdx/processor";

interface Props {
  params: Promise<{ subdomain: string; slug?: string[] }>;
}

export default async function DocsPage({ params }: Props) {
  const { subdomain, slug } = await params;
  const pageSlug = slug?.join("/") || "index";

  const supabase = await createClient();

  // Get project by subdomain
  const { data: project } = await supabase
    .from("projects")
    .select("*")
    .eq("subdomain", subdomain)
    .eq("is_public", true)
    .single();

  if (!project) notFound();

  // Get page content
  const { data: page } = await supabase
    .from("pages")
    .select("*")
    .eq("project_id", project.id)
    .eq("slug", pageSlug)
    .eq("is_published", true)
    .single();

  if (!page) notFound();

  const { content } = await renderMDX(page.content);

  return (
    <article className="prose dark:prose-invert max-w-none">
      <h1>{page.title}</h1>
      {content}
    </article>
  );
}

ISR: The Performance Secret

Documentation doesn't change every second. We use Incremental Static Regeneration (ISR) to cache pages at the edge:

// app/sites/[subdomain]/[[...slug]]/page.tsx
export const revalidate = 60; // Revalidate every 60 seconds

// Also configure Supabase client for ISR
const supabase = createClient({
  global: {
    fetch: (url, options) =>
      fetch(url, { ...options, next: { revalidate: 60 } })
  }
});

Result? First request hits the database. Next 60 seconds of requests are served from Vercel's edge cache. Sub-100ms load times globally.

MDX Processing with next-mdx-remote

Users write MDX in a browser editor. We compile it server-side:

// lib/mdx/processor.ts
import { compileMDX } from "next-mdx-remote/rsc";
import remarkGfm from "remark-gfm";
import rehypeSlug from "rehype-slug";
import rehypePrettyCode from "rehype-pretty-code";
import { mdxComponents } from "@/components/mdx";

export async function renderMDX(source: string) {
  const { content, frontmatter } = await compileMDX({
    source,
    components: mdxComponents,
    options: {
      parseFrontmatter: true,
      mdxOptions: {
        remarkPlugins: [remarkGfm],
        rehypePlugins: [
          rehypeSlug,
          [rehypePrettyCode, { theme: "github-dark" }],
        ],
      },
    },
  });

  return { content, frontmatter };
}

Custom components (Callouts, Tabs, Code blocks) are passed via mdxComponents, letting users write rich documentation.

Custom Domains (The Tricky Part)

Custom domains require:

User adds domain in dashboard
They configure DNS (CNAME to cname.vercel-dns.com)
Domain is added to Vercel (manually for now, API for scale)
Middleware detects non-dokly.co domains and looks up the project

// For custom domains, look up by domain instead of subdomain
if (hostname !== baseDomain && !hostname.endsWith(`.${baseDomain}`)) {
  const { data: project } = await supabase
    .from("projects")
    .select("subdomain")
    .eq("custom_domain", hostname)
    .single();

  if (project) {
    return NextResponse.rewrite(
      new URL(`/sites/${project.subdomain}${pathname}`, request.url)
    );
  }
}

Gotchas I Hit

1. Vercel Pro Required for Wildcards

Wildcard domains (*.dokly.co) require Vercel Pro ($20/month). No workaround.

2. Middleware Runs on Every Request

Keep middleware fast. Don't make database calls unless absolutely necessary. Use header rewrites and let the page handle the DB lookup.

3. ISR Cache Keys Include Hostname

This is actually good - acme.dokly.co/getting-started and beta.dokly.co/getting-started are cached separately.

4. next-mdx-remote RSC vs Client

Use the RSC version (next-mdx-remote/rsc) for server components. The old client version adds unnecessary JS bundle size.

The Stack

Framework: Next.js 15 (App Router)
Database: Supabase (PostgreSQL + Auth + Storage)
Styling: Tailwind CSS + shadcn/ui
MDX: next-mdx-remote + Shiki syntax highlighting
Hosting: Vercel (Pro for wildcards)
Payments: Stripe

What's Next

Building:

Auto-generated llms.txt for AI agent discoverability
BYOK AI writing assistant
GitHub sync for docs-as-code workflows

Try It

If you're building developer tools or need documentation, give Dokly a try. The free tier includes subdomain hosting, MDX editor, and search.

Questions about the architecture? Drop them in the comments - happy to dive deeper into any part.

Building in public at @gsharm_