DEV Community: Devanshu Goyal

I Gave My 3AM Self a Memory: Building on Cognee's Memory Lifecycle

Devanshu Goyal — Sun, 05 Jul 2026 15:26:30 +0000

You get paged at 3AM. You fix production half-asleep. By the time the graphs go green, the context is gone.

I built BlackoutOps — a morning-after incident brain — for the WeMakeDevs × Cognee "The Hangover Part AI: Where's My Context?" hackathon. It reconstructs the night you can't remember, tells you whether the team has seen the failure before, learns the confirmed root cause, and — because retention policies are real — provably forgets on command.

This is the honest build story: how I designed every feature around Cognee's four memory verbs — remember, recall, improve, and forget — what each one actually did for the build, and the two war stories the live platform handed me for free.

🔗 Repo: https://github.com/devanshug2307/blackoutops (MIT)

What I Built

The interesting part isn't the app — it's that the app has zero storage of its own. No database, no cache, no local vector index. Every button in the war-room UI is a live call to Cognee, organized around Cognee's memory lifecycle rather than a single search() endpoint.

Project:   BlackoutOps — the morning-after incident brain
Built for: WeMakeDevs x Cognee, "The Hangover Part AI" (July 2026)
Stack:     FastAPI + a static war-room UI, ~150-line memory layer
Memory:    Cognee Cloud (remember / recall / improve / forget)
Storage:   none of its own — Cognee is the database
Repo:      github.com/devanshug2307/blackoutops (MIT)

(War-room UI below — left: the night's raw fragments; middle: the debrief chat; right: the memory lifecycle, where every card is labeled with the exact Cognee Cloud call it fires.)

The 3AM Hangover

Every on-call engineer knows this specific hangover. At 02:47 a Redis memory alert fires. At 03:15 PagerDuty finds you. For the next forty minutes you are a raccoon in a server room: kubectl logs, redis-cli INFO, a rollback, a config flag you half-remember from a runbook. At 03:56 the dashboards go green and you go back to sleep.

The next morning, the only artifact of that firefight is a green dashboard and a vague sense of dread. What broke? What did you actually run? Why did the rollback work? And the question that costs the most six months later: haven't we seen this exact failure before?

That knowledge normally dies in scrollback, and the org re-diagnoses the same eviction storm from scratch, over and over. The hackathon theme was "Where's My Context?" and this is the most literal lost-context problem I know.

Why a Graph, Not RAG

The artifacts of an incident are fragments in five different dialects: Prometheus alerts, PagerDuty pages, sleepy Slack messages, shell history, deploy logs. The meaning of the night lives in the connections between them, not in any single fragment:

the deploy at 02:30 caused the eviction storm at 02:45
the rollout undo at 03:33 targeted that exact deploy
last night shares a failure pattern with an incident three weeks earlier — different service, same TTL-less-keys-in-shared-Redis mistake

A vector store can hand you "similar text." It cannot tell you that two incidents three weeks apart are the same disease in different clothes. That's a graph traversal. Cognee ingests raw text and builds a knowledge graph where services, people, commands, and causes become connected entities — so I get the connective answers for free. Seeded with two incident nights, my demo graph came out to 98 nodes and 186 edges.

The Four-Verb Lifecycle

Cognee's API is a memory lifecycle, not a database. The moment I mapped features to the four verbs, the architecture fell out of the problem. My whole memory layer is one honest function per verb — about 150 lines total.

Cognee call	In the code	What it does in BlackoutOps
`remember()`	`ingest_artifacts()`	Turns each raw ops fragment — an alert, a Slack line, my shell history — into permanent graph memory in a per-incident dataset.
`remember(session_id=…)`	`store_qa()`	Logs every debrief Q&A as a typed `QAEntry` in session memory, so the app survives a refresh with its context intact.
`recall()`	`ask()`	Auto-routed search across both incident datasets and session memory — graph-completion answers, not nearest-neighbor text.
`improve()`	`file_postmortem()`	Feeds the human-confirmed root cause back into the graph and runs an enrichment pass, so the confirmed pattern leads the next answer.
`forget()`	`purge()`	Dataset-scoped deletion that returns Cognee's own receipt — retention policy as a first-class button.

One decision underpins all of it: datasets are the unit of meaning. Each incident gets its own dataset (incident_2026_07_05, incident_2026_06_14_redis_storm). That single choice buys isolation, explicit routing for cross-incident questions, and surgical deletion.

`remember()`: The Night, Ingested

Everything starts by connecting the same cognee package to Cognee Cloud with serve(), then pushing each raw artifact in as permanent graph memory. No parsing, no schema — Cognee does the entity extraction and graph building.

import cognee

# same package, but memory now lives in Cognee Cloud
await cognee.serve(url=TENANT_URL, api_key=API_KEY)

# each fragment -> permanent graph memory, in a per-incident dataset
for artifact in LAST_NIGHT:          # alerts, Slack, shell history, deploy log
    await cognee.remember(artifact, dataset_name="incident_2026_07_05")

There's a second, sneakier remember in the app, and it was the cheapest "wow" in the whole build. Every debrief Q&A gets stored to session memory as a typed QAEntry:

# session memory: one parameter, and the app survives a refresh
await cognee.remember(
    cognee.QAEntry(question=q, answer=a),
    session_id="morning-after-debrief",
)

Refresh the page and the UI's chat history is gone. But ask "what did we conclude earlier?" and the brain recalls it. The UI forgets; Cognee doesn't. Because the entry is typed, I can also attach a typed FeedbackEntry (👍/👎) to the exact answer it judges — human signal stored right next to the memory it grades.

`recall()`: The Morning Debrief

The debrief chat is one function. Every question is an auto-routed recall() over both incident datasets and session memory. I don't pick the search strategy; I pass every incident dataset and let auto_route=True decide.

entries = await cognee.recall(
    "Have we seen this failure before?",
    datasets=["incident_2026_07_05", "incident_2026_06_14_redis_storm"],
    session_id="morning-after-debrief",
    top_k=12,
    auto_route=True,
)

This is where the demo stops being a chatbot and becomes a memory. Last night's outage was checkout-service v2.14.1 shipping cache warming that wrote per-session keys with no TTL into the shared redis-cache, filling maxmemory and triggering an eviction storm that broke checkout session lookups and cascaded into api-gateway 502s. Three weeks earlier, promo-service had done the exact same TTL-less thing during a sale. Ask "have we seen this before?" and the graph connects the two through their shared entities and answers yes, here's the twin. That's the question a plain vector store fumbles and a knowledge graph nails.

`improve()`: Memory That Learns

Postmortems usually go to a wiki to be read by no one. Here, filing the postmortem writes the human-confirmed root cause back into graph memory and then attempts Cognee's dedicated enrichment pass. I want to be precise and honest about this one, because it's the verb with the most nuance:

# 1) the confirmed pattern goes back through the full remember pipeline
await cognee.remember(POSTMORTEM, dataset_name="incident_2026_07_05")

# 2) then attempt the dedicated improve() enrichment pass
try:
    await cognee.improve(dataset="incident_2026_07_05")
except Exception as e:
    # honest receipt: on tenants that don't expose improve() yet,
    # the remember pipeline above IS the enrichment we got
    note = f"improve() route not exposed on this tenant ({e})"

The effect a user sees is real: after filing the postmortem, "what should we watch for next time?" answers with the confirmed pattern — TTL-less per-session keys in shared Redis — ranked first, now cross-referenced against the June incident. The memory adapts to human-verified truth. This is the part of the lifecycle almost nobody uses, and it's the part that turns a log pile into an institution's memory. I show the honest receipt in the UI either way, because a build story that hides its rough edges is a worse story.

`forget()`: Deletion as a Feature

Incident data is full of internal hostnames and human mistakes, so it has retention policies. BlackoutOps treats deletion as a first-class demo beat, not an apology buried in a settings page:

receipt = await cognee.forget(
    dataset="incident_2026_06_14_redis_storm",
    memory_only=True,   # wipe graph + vector memory, keep the dataset name
)

Purge the June incident, get Cognee's deletion receipt, then ask about it again — and the brain honestly says it has no memory of that night. Watching recall() go from a detailed cross-incident answer to "I have no memory of that" in one click is more convincing than any privacy-policy paragraph. Provable forgetting is rarer, and more valuable, than remembering.

The Tenant That Didn't Exist

Mid-build, every request to my freshly provisioned Cognee Cloud tenant failed with Could not resolve host. The tenant was live — curl --resolve against the right IP returned a healthy heartbeat. The culprit: my Mac's resolver is Cloudflare's 1.1.1.1, which had cached an NXDOMAIN from before the tenant's DNS record existed. Google's 8.8.8.8 already knew the answer; Cloudflare confidently remembered the absence.

The fix became part of the project — a tiny dns_fallback.py that, when the system resolver fails for the tenant host, resolves it over DNS-over-HTTPS and pins the answer by patching socket.getaddrinfo:

def ensure_resolvable(hostname: str) -> str:
    try:
        socket.getaddrinfo(hostname, 443)
        return f"{hostname}: system DNS OK"
    except socket.gaierror:
        pass                                  # system resolver has a stale NXDOMAIN

    ip = _resolve_via_doh(hostname)           # ask dns.google over HTTPS instead
    if not ip:
        return f"{hostname}: UNRESOLVABLE"
    _pinned[hostname] = ip                    # pin it for every client in-process
    socket.getaddrinfo = _patched_getaddrinfo
    return f"{hostname}: pinned to {ip} via DoH fallback"

Then a second layer of the same onion: it still failed under uvicorn, because uvloop does DNS in C and never calls socket.getaddrinfo. One --loop asyncio flag later, everything held. I appreciate the irony: while building an app about stale memory, I was defeated by a stale cache remembering that something didn't exist. Negative memory is still memory. Even DNS needed a forget().

A Bug on a Live Platform

Building on a live cloud during a hackathon is the best fuzzer there is, and I found the next bug the honest way — by breaking my own demo. On this Cloud build, remember() into a dataset name previously deleted with a full forget() fails forever with a 409 RetryError[ProgrammingError]. The name is tombstoned. A memory_only=True forget doesn't have the problem, so that's what BlackoutOps ships with. The minimal repro I filed upstream:

async def cycle(name, memory_only):
    await cognee.remember("v1", dataset_name=name)
    await cognee.forget(dataset=name, memory_only=memory_only)
    try:
        await cognee.remember("v2", dataset_name=name)
        return "re-remember OK"
    except Exception as e:
        return f"re-remember FAILED: {e}"

# A (full forget):        re-remember FAILED: 409 RetryError[ProgrammingError]
# B (memory-only forget): re-remember OK
# observed on Cognee Cloud server 1.2.2.dev0 / SDK 1.2.2, 2026-07-05

It went upstream as topoteretes/cognee#3895. This is also why my historical dataset is named incident_2026_06_14_redis_storm and not the cleaner incident_2026_06_14: I'd already tombstoned the tidy name during testing. The scar is in the codebase, and I left it there on purpose.

Four Lessons for Cognee Builders

If you're about to build on Cognee, here's what I wish I'd known at hour zero:

Design around the lifecycle, not around search. The second I mapped features to the four verbs, the architecture wrote itself — one honest function per verb.
Datasets are your unit of meaning. Per-incident (or per-customer, per-project) datasets give you routing, isolation, and surgical forget() for free.
Session memory is the cheapest wow. One parameter, and your app survives a refresh with its context intact. Reach for it before you build custom state.
Demo the question grep can't answer. Every domain has one cross-cutting question a vector store fumbles. For incidents it's "have we seen this before?" Find yours and make the graph answer it.

Architecture at a Glance

  war-room UI (static)            Cognee Cloud (tenant)
  chat . lifecycle . graph         remember  -> knowledge graph
        |                 HTTP     recall    -> graph + session
  FastAPI (app.py)        ----->   improve   -> pattern enrichment
  memory layer (memory.py) <-----  forget    -> surgical deletion
    . cognee.serve(url, key)       visualize -> force-graph HTML
    . zero local storage

The app keeping no database of its own isn't a limitation I apologized for — it's the entire thesis. The brain is the product, and the brain is Cognee. Reconstruct, ask, learn, forget.

FAQ

What is Cognee's memory lifecycle?
Four verbs instead of one database call: remember() ingests text into a knowledge graph, recall() searches across that graph and session memory, improve() enriches memory with confirmed patterns, and forget() deletes it. Designing around those four is what makes memory feel like memory.

How is a knowledge graph different from a vector database for agent memory?
A vector DB finds semantically similar text. A knowledge graph stores entities (services, people, commands, causes) and their relationships, so it can answer connective questions — like two incidents three weeks apart sharing a root-cause pattern across different services. That traversal is exactly what nearest-neighbor search can't do.

What does session memory do?
Passing session_id writes to a fast session store that also syncs into the graph. Refreshing the browser wipes the UI's chat but the brain still remembers what you concluded. One parameter, big jump in perceived intelligence.

How do you delete data from an agent's memory?
forget(dataset=…) for surgical, dataset-scoped deletion. BlackoutOps uses forget(memory_only=True), which wipes graph and vector memory (recall honestly returns nothing) while keeping the dataset name reusable.

Sources and Links

Built solo in one appropriately sleepless day, with Claude Code (Claude Fable 5) as a pair programmer for scaffolding, debugging, and docs, under human direction — disclosed here per hackathon rules.

BlackoutOps source (MIT): https://github.com/devanshug2307/blackoutops
Cognee: https://github.com/topoteretes/cognee
Cognee docs: https://docs.cognee.ai
The upstream bug + repro: https://github.com/topoteretes/cognee/issues/3895
Hackathon: https://www.wemakedevs.org/hackathons/cognee

If you're building on Cognee and want the full memory lifecycle wired end-to-end, the ~150-line memory.py in the repo is the whole map. Seed the night, and every verb is a live call you can watch fire.

Building NailArt AI: A Complete Technical Breakdown

Devanshu Goyal — Sun, 02 Nov 2025 10:36:47 +0000

How I Built an AI-Powered Virtual Nail Art Try-On Platform with 600+ Designs

In this deep dive, I'll walk you through the entire architecture, tech stack decisions, and implementation details of NailArt AI — a platform that lets users try on nail art designs virtually using AI.

Introduction
The Problem We're Solving
Tech Stack & Why We Chose Each Technology
Architecture Overview
AI Integration: Google Gemini
Database Design: Supabase PostgreSQL
Storage Architecture: Dual-Layer Strategy
Performance Optimizations
SEO Implementation
Virtual Try-On Feature
Admin Dashboard & Content Management
Challenges We Faced & Solutions
What's Next

Introduction

NailArt AI is a comprehensive AI-powered platform that combines image generation, virtual try-on capabilities, and an extensive gallery system. The app allows users to:

Generate unique nail art designs using AI (Google Gemini)
Try on designs virtually by uploading hand photos
Browse 600+ curated designs across 185+ categories
Get detailed tutorials with AI-generated editorial content
Discover designs by colors, techniques, occasions, seasons, and styles

The platform is built with a focus on performance, SEO, and user experience, handling everything from AI image generation to complex filtering and search functionality.

The Problem We're Solving

Before diving into the technical details, let's understand what we're building:

AI Image Generation: Users need instant, high-quality nail art designs generated from text prompts
Virtual Try-On: Users want to see how designs look on their actual hands before going to a salon
Content Discovery: Users need to find relevant designs through intuitive filtering (by color, occasion, technique, etc.)
SEO & Content: Each design needs rich, SEO-optimized content to rank in search engines
Performance: Fast loading times, especially on mobile devices
Scalability: Handle growing content library efficiently

Tech Stack & Why We Chose Each Technology

Frontend: Next.js 15 + React 19 + Tailwind CSS 4

Why Next.js 15?

App Router: Server Components for better SEO and performance
Built-in Image Optimization: Automatic image optimization with next/image
API Routes: Backend functionality without separate server
Server-Side Rendering: Critical for SEO with 1,600+ dynamic pages
Edge Runtime: Deploy functions globally for low latency

Why React 19?

Latest features and performance improvements
Better server component support
Improved hydration

Why Tailwind CSS 4?

Utility-first approach speeds up development
Responsive design out of the box
Easy theming (we use a custom pink/white palette)
Small bundle size with tree-shaking

Backend: Next.js API Routes + Server Components

All backend logic lives in Next.js API routes (/api/*), making deployment simple on Vercel. We use:

Server Components: For SEO-optimized pages (no JavaScript sent to client)
API Routes: For dynamic operations (AI generation, image uploads, etc.)
Edge Functions: For global performance

Database: Supabase PostgreSQL

Why Supabase?

PostgreSQL: Robust, relational database perfect for our structured data
Row Level Security (RLS): Built-in security policies
Real-time Capabilities: For future features like live updates
Auto-generated APIs: REST and GraphQL APIs out of the box
Built-in Auth: User authentication ready to use
Free Tier: Generous free tier for MVP

Our Schema:

-- Main gallery items table
CREATE TABLE gallery_items (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  image_url TEXT NOT NULL,
  prompt TEXT NOT NULL,
  design_name TEXT,
  category TEXT,
  original_image_url TEXT,
  colors TEXT[],           -- Array of color tags
  techniques TEXT[],       -- Array of technique tags
  occasions TEXT[],        -- Array of occasion tags
  seasons TEXT[],          -- Array of season tags
  styles TEXT[],           -- Array of style tags
  shapes TEXT[],           -- Array of shape tags
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
  user_id UUID REFERENCES auth.users(id)
);

-- AI-generated editorial content
CREATE TABLE gallery_editorials (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  gallery_item_id UUID REFERENCES gallery_items(id),
  title TEXT NOT NULL,
  intro TEXT,
  primary_keyword TEXT,
  secondary_keywords TEXT[],
  supplies TEXT[],
  steps TEXT[],
  faqs JSONB,
  -- ... 20+ more fields for rich content
  created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

Storage: Cloudflare R2 + Supabase Storage

Why Dual Storage?

Supabase Storage (Primary)

Used for transactional operations
User uploads (hand photos for try-on)
Temporary files
Integration with database

Cloudflare R2 (CDN Layer)

Global CDN for fast image delivery
Cost-effective ($0.015/GB storage, $0 egress)
Better performance than Supabase for public assets
Automatic sync from Supabase to R2

Our Flow:

User Upload → Supabase Storage → R2 Sync → CDN Delivery

AI: Google Gemini API

Why Gemini?

Multimodal: Handles both image and text generation
Image Generation: gemini-2.5-flash-image-preview for creating nail art
Image-to-Image: gemini-2.0-flash-exp for virtual try-on
Content Generation: gemini-2.5-pro for SEO-optimized editorial content
Cost-Effective: Good pricing compared to alternatives
Fast: Low latency for real-time features

Models We Use:

gemini-2.5-flash-image-preview: Generating nail art from text prompts
gemini-2.0-flash-exp: Applying designs to hand photos (try-on)
gemini-2.5-pro: Generating editorial content (tutorials, FAQs, etc.)

Deployment: Vercel

Why Vercel?

Zero Config: Works perfectly with Next.js
Edge Network: Deploy API routes globally
Automatic Deployments: CI/CD built-in
Analytics: Built-in performance monitoring
Free Tier: Great for MVP

Architecture Overview

High-Level Architecture

┌─────────────────────────────────────────────────────────────┐
│                         Client (Browser)                      │
│  Next.js 15 App Router + React 19 + Tailwind CSS 4          │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                      Vercel Edge Network                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐    │
│  │ API Routes  │  │Server Comp.  │  │ Edge Func.   │    │
│  └──────────────┘  └──────────────┘  └──────────────┘    │
└─────────────────────────────────────────────────────────────┘
          │                    │                    │
          ▼                    ▼                    ▼
┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│   Gemini    │      │   Supabase  │      │   Cloudflare│
│     AI     │      │  PostgreSQL │      │      R2     │
└─────────────┘      └─────────────┘      └─────────────┘

Folder Structure

nail-art-nextjs/
├── src/
│   ├── app/                    # Next.js App Router pages
│   │   ├── page.tsx            # Homepage
│   │   ├── [category]/[slug]/  # Dynamic design pages
│   │   ├── try-on/             # Virtual try-on interface
│   │   ├── nail-art-gallery/   # Gallery listing
│   │   ├── api/                # API routes (24 endpoints)
│   │   └── admin/               # Admin dashboard
│   ├── components/             # 47 React components
│   │   ├── OptimizedImage.tsx  # Image optimization component
│   │   ├── DesignGalleryGrid.tsx
│   │   ├── CollapsibleSection.tsx
│   │   └── ... (43 more)
│   └── lib/                    # 34 utility libraries
│       ├── geminiService.ts    # AI integration
│       ├── supabase.ts         # Database client
│       ├── r2Service.ts        # Storage service
│       ├── galleryService.ts   # Business logic
│       └── ... (30 more)
├── public/                     # Static assets
└── supabase/
    └── migrations/             # Database migrations

AI Integration: Google Gemini

Image Generation Flow

1. Text-to-Image (Design Generation)

// src/lib/nailArtGenerator.ts
export async function generateNailArtImage(prompt: string): Promise<string | null> {
  // API key stored securely in environment variables - never in code
const aiInstance = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

  const enhancedPrompt = `Create a high-quality nail art design: ${prompt}. 
    The image should show:
    - Clean, well-manicured nails
    - Professional nail art application
    - High resolution and detailed work
    - Beautiful lighting and composition
    - Focus on the nail design as the main subject`;

  const response = await aiInstance.models.generateContent({
    model: 'gemini-2.5-flash-image-preview',
    contents: {
      parts: [{ text: enhancedPrompt }],
    },
    config: {
      responseModalities: [Modality.IMAGE, Modality.TEXT],
    },
  });

  // Extract base64 image from response
  const imageData = extractImageFromResponse(response);

  // Upload to R2 CDN
  const imageUrl = await uploadToR2(imageData);

  return imageUrl;
}

2. Image-to-Image (Virtual Try-On)

// src/app/api/generate-nail-art/route.ts
export async function POST(request: NextRequest) {
  const { base64ImageData, mimeType, prompt } = await request.json();

  // Use Gemini's image-to-image capability
  const response = await ai.models.generateContent({
    model: 'gemini-2.0-flash-exp',
    contents: {
      parts: [
        {
          inlineData: {
            data: base64ImageData,
            mimeType: mimeType,
          },
        },
        {
          text: `Apply this nail art design to the nails in the image: ${prompt}. Only change the nails.`,
        },
      ],
    },
    config: {
      responseModalities: [Modality.IMAGE, Modality.TEXT],
    },
  });

  return NextResponse.json({ imageData: extractImageFromResponse(response) });
}

3. Content Generation (Editorial Content)

// src/lib/geminiService.ts
export async function generateEditorialContentForNailArt(
  designName?: string,
  category?: string,
  prompt?: string
): Promise<NailArtEditorial> {
  const sys = `You are a professional nail artist and SEO copywriter...`;

  const response = await aiInstance.models.generateContent({
    model: 'gemini-2.5-pro',
    contents: {
      parts: [
        { text: sys },
        { text: `Design: ${designName}\nCategory: ${category}\nPrompt: ${prompt}` },
      ],
    },
  });

  // Parse JSON response
  return JSON.parse(extractTextFromResponse(response));
}

Rate Limiting

We implement strict rate limiting for AI operations since they're expensive. Rate limits are configurable via environment variables and follow industry best practices:

// src/lib/rateLimiter.ts
export const rateLimiters = {
  aiGeneration: {
    maxRequests: parseInt(process.env.AI_RATE_LIMIT || '10'), // Configurable
    windowMs: parseInt(process.env.AI_RATE_WINDOW || '60000'), // 1 minute default
  },
  tryOn: {
    maxRequests: parseInt(process.env.TRYON_RATE_LIMIT || '5'), // Configurable
    windowMs: parseInt(process.env.TRYON_RATE_WINDOW || '60000'),
  },
};

Note: Actual rate limit values are stored in environment variables and adjusted based on server capacity and usage patterns.

Database Design: Supabase PostgreSQL

Key Design Decisions

1. Array Columns for Tags

Instead of separate junction tables, we use PostgreSQL arrays:

colors TEXT[],
techniques TEXT[],
occasions TEXT[],
-- etc.

Why?

Simpler queries: WHERE 'red' = ANY(colors)
Better performance for read-heavy workloads
Easier to maintain
PostgreSQL arrays are indexed with GIN indexes

2. Separate Editorial Table

Editorial content is in a separate table to:

Keep gallery_items lightweight
Allow lazy loading of rich content
Enable independent updates
Better caching strategies

3. Indexes for Performance

-- Search performance
CREATE INDEX idx_gallery_items_category ON gallery_items(category);
CREATE INDEX idx_gallery_items_design_name ON gallery_items(design_name);
CREATE INDEX idx_gallery_items_created_at ON gallery_items(created_at DESC);

-- Array search (GIN indexes)
CREATE INDEX idx_gallery_items_colors ON gallery_items USING GIN(colors);
CREATE INDEX idx_gallery_items_techniques ON gallery_items USING GIN(techniques);
-- etc.

Query Examples

Get items by category:

const { data } = await supabase
  .from('gallery_items')
  .select('*')
  .eq('category', category)
  .order('created_at', { ascending: false })
  .limit(12);

Get items by color tag:

const { data } = await supabase
  .from('gallery_items')
  .select('*')
  .contains('colors', ['red'])  // PostgreSQL array contains
  .limit(12);

Get items with editorial content:

const { data } = await supabase
  .from('gallery_items')
  .select(`
    *,
    gallery_editorials (*)
  `)
  .eq('id', itemId)
  .single();

Storage Architecture: Dual-Layer Strategy

Why Two Storage Systems?

Supabase Storage:

Transactional operations
User uploads (hand photos)
Database integration
Row Level Security

Cloudflare R2:

Global CDN delivery
Better performance (lower latency)
Lower costs (no egress fees)
Static asset caching

Implementation

// src/lib/r2Service.ts
export async function uploadToR2(
  file: Buffer,
  key: string,
  contentType: string = 'image/jpeg',
  metadata?: Record<string, string>
): Promise<string> {
  const command = new PutObjectCommand({
    Bucket: process.env.R2_BUCKET_NAME, // Stored in environment variables
    Key: `images/${key}`,
    Body: file,
    ContentType: contentType,
    Metadata: {
      ...metadata,
      'license': 'CC0-1.0',
      'source': 'nailartai.app',
    },
    CacheControl: 'public, max-age=31536000, immutable',
  });

  await r2Client.send(command);
  return `${process.env.R2_PUBLIC_URL}/images/${key}`; // CDN URL from env vars
}

Automatic Sync

When a new image is uploaded to Supabase, we automatically sync it to R2:

// src/app/api/sync-r2/route.ts
export async function POST(request: NextRequest) {
  const { supabaseUrl, itemId } = await request.json();

  // Download from Supabase
  const imageBuffer = await downloadFromSupabase(supabaseUrl);

  // Upload to R2
  const r2Url = await uploadToR2(imageBuffer, generateKey(itemId));

  // Update database with R2 URL
  await supabase
    .from('gallery_items')
    .update({ image_url: r2Url })
    .eq('id', itemId);

  return NextResponse.json({ success: true, url: r2Url });
}

Performance Optimizations

1. Image Optimization

Responsive Images:

// src/components/OptimizedImage.tsx
const IMAGE_PRESETS = {
  thumbnail: { width: 200, height: 200 },
  card: { width: 200, height: 112 },
  detail: { width: 400, height: 600 },
  mobile: { width: 150, height: 150 },
};

export default function OptimizedImage({ src, preset, priority }) {
  const { isMobile } = useMobileOptimization();
  const optimizedSrc = getOptimizedImageUrl(src, isMobile);

  return (
    <img
      src={optimizedSrc}
      loading={priority ? 'eager' : 'lazy'}
      fetchPriority={priority ? 'high' : 'low'}
      decoding={priority ? 'sync' : 'async'}
      sizes={preset === 'mobile' ? '100vw' : '50vw'}
    />
  );
}

CDN Optimization:

All images served from Cloudflare R2 CDN
1-year cache headers for static assets
Mobile-specific image sizes

2. Code Splitting

// Dynamic imports for non-critical components
const CategoryShowcase = dynamic(() => import('@/components/CategoryShowcase'), {
  loading: () => <Skeleton />,
  ssr: false, // Only load on client
});

3. Database Query Optimization

Caching:

// src/lib/galleryCacheService.ts
const cache = new Map<string, { data: any; expires: number }>();

export async function getCachedGalleryItems(options) {
  const key = JSON.stringify(options);
  const cached = cache.get(key);

  if (cached && cached.expires > Date.now()) {
    return cached.data;
  }

  const data = await fetchGalleryItems(options);
  cache.set(key, { data, expires: Date.now() + 60000 }); // 1 min cache
  return data;
}

Optimized Queries:

// Only select needed fields
const { data } = await supabase
  .from('gallery_items')
  .select('id, image_url, design_name, category')  // Specific fields only
  .limit(12);

4. Server Components

Most pages are Server Components for better SEO and performance:

// src/app/[category]/[slug]/page.tsx
export default async function DesignDetailPage({ params }) {
  // This runs on the server - no JS sent to client
  const item = await getGalleryItemBySlug(params.slug);
  const editorial = await getEditorial(item.id);

  return (
    <div>
      {/* Fully rendered HTML sent to client */}
      <DesignHero item={item} />
      <EditorialContent editorial={editorial} />
    </div>
  );
}

5. Critical CSS Inlining

// src/app/layout.tsx
<style dangerouslySetInnerHTML={{
  __html: `
    html{height:100%;font-size:16px}
    body{min-height:100%;background:#f8f6f7;color:#1b0d14;margin:0}
    /* Critical styles only */
  `
}} />

SEO Implementation: A Comprehensive Strategy

With 1,600+ pages to optimize, SEO isn't just a nice-to-have—it's essential for discoverability. Our SEO strategy covers technical SEO, on-page optimization, structured data, and content distribution.

1. Dynamic Metadata Generation

Every page has unique, SEO-optimized metadata generated dynamically:

// src/app/[category]/[slug]/page.tsx
export async function generateMetadata({ params }): Promise<Metadata> {
  const item = await getGalleryItemBySlug(params.slug);
  const editorial = await getEditorial(item.id);

  return {
    title: `${editorial.title} | Nail Art AI`,
    description: editorial.intro,
    keywords: editorial.secondaryKeywords,
    openGraph: {
      title: editorial.title,
      description: editorial.intro,
      images: [{ url: item.image_url }],
    },
    twitter: {
      card: 'summary_large_image',
      title: editorial.title,
      images: [item.image_url],
    },
  };
}

2. Structured Data (JSON-LD)

// Design detail page includes HowTo and FAQ schema
const structuredData = {
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": editorial.title,
  "description": editorial.intro,
  "step": editorial.steps.map((step, i) => ({
    "@type": "HowToStep",
    "position": i + 1,
    "text": step,
  })),
  "totalTime": `PT${editorial.timeMinutes}M`,
  "tool": editorial.supplies,
};

const faqSchema = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": editorial.faqs.map(faq => ({
    "@type": "Question",
    "name": faq.q,
    "acceptedAnswer": {
      "@type": "Answer",
      "text": faq.a,
    },
  })),
};

3. Sitemaps

We generate multiple sitemaps for better indexing:

// src/app/sitemap.xml/route.ts
export async function GET() {
  // Generate sitemap index
  return `<?xml version="1.0" encoding="UTF-8"?>
    <sitemapindex>
      <sitemap><loc>https://nailartai.app/sitemap-designs.xml</loc></sitemap>
      <sitemap><loc>https://nailartai.app/sitemap-categories.xml</loc></sitemap>
      <sitemap><loc>https://nailartai.app/sitemap-static.xml</loc></sitemap>
    </sitemapindex>`;
}

4. Image SEO

// Optimized image metadata
<img
  src={item.image_url}
  alt={generateImageAltText(item.design_name, item.category, item.prompt)}
  // ... other attributes
/>

// Generated alt text
function generateImageAltText(designName, category, prompt) {
  return `${designName || 'Nail Art Design'} - ${category || 'Nail Art'} | ${prompt || 'AI Generated Design'}`;
}

5. Advanced Sitemap Strategy

The Challenge: With 600+ designs across 185+ categories, we need intelligent sitemap management to ensure all content gets indexed efficiently.

Our Solution: Multiple Specialized Sitemaps

Instead of one massive sitemap, we use a sitemap index with specialized sitemaps:

// src/app/sitemap-index.xml/route.ts
export async function GET() {
  return `<?xml version="1.0" encoding="UTF-8"?>
    <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
      <sitemap><loc>https://nailartai.app/sitemap-static.xml</loc></sitemap>
      <sitemap><loc>https://nailartai.app/sitemap-designs.xml</loc></sitemap>
      <sitemap><loc>https://nailartai.app/sitemap-categories.xml</loc></sitemap>
      <sitemap><loc>https://nailartai.app/sitemap-images.xml</loc></sitemap>
      <sitemap><loc>https://nailartai.app/sitemap-gallery.xml</loc></sitemap>
    </sitemapindex>`;
}

Sitemap Types:

Static Sitemap (sitemap-static.xml): Core pages (homepage, gallery, categories index)
Designs Sitemap (sitemap-designs.xml): All individual design pages (highest priority: 0.8)
Categories Sitemap (sitemap-categories.xml): Category filtering pages, color pages, technique pages
Images Sitemap (sitemap-images.xml): Image metadata for Google Images
Gallery Sitemap (sitemap-gallery.xml): Gallery overview pages

Why This Structure?

Prevents Duplicates: Only canonical URLs in each sitemap
Priority Management: Important pages get higher priority scores
Search Engine Optimization: Different engines can focus on relevant content
Pagination Support: Handles 1,000+ items per sitemap automatically

Sitemap Priority System:

function getCategoryPriority(category?: string): number {
  // High-value categories get higher priority
  const highPriorityCategories = [
    'Christmas Nail Art', 'Halloween Nail Art', 
    'Wedding Nail Art', 'French Nail Art'
  ];

  if (category && highPriorityCategories.includes(category)) {
    return 0.9; // Highest priority
  }

  return 0.8; // Standard design pages
}

Automatic Sitemap Updates:

When new content is created, we automatically update sitemaps:

// src/app/api/regenerate-sitemap/route.ts
export async function POST(request: NextRequest) {
  const { newContent } = await request.json();

  // Revalidate relevant sitemaps
  revalidatePath('/sitemap.xml');
  revalidatePath('/sitemap-designs.xml');

  // Ping search engines
  await Promise.all([
    fetch(`https://www.google.com/ping?sitemap=https://nailartai.app/sitemap-index.xml`),
    fetch(`https://www.bing.com/ping?sitemap=https://nailartai.app/sitemap-index.xml`)
  ]);

  return NextResponse.json({ success: true });
}

6. IndexNow Implementation: Instant Indexing

The Challenge: Waiting for search engines to discover new content can take weeks. We needed instant indexing for new designs.

Our Solution: IndexNow Protocol

IndexNow is an open protocol that allows websites to notify search engines (Bing, Yandex, etc.) immediately when content changes.

Implementation:

// src/lib/indexnowService.ts
export async function submitToIndexNow(urls: string[]): Promise<boolean> {
  const request = {
    host: 'nailartai.app',
    key: process.env.INDEXNOW_API_KEY, // Stored securely in environment variables
    keyLocation: `https://nailartai.app/${process.env.INDEXNOW_API_KEY}.txt`, // Key file location
    urlList: urls
  };

  // Submit to multiple IndexNow-compatible search engines
  const endpoints = [
    'https://api.indexnow.org/indexnow',
    'https://www.bing.com/indexnow',
    'https://yandex.com/indexnow'
  ];

  const promises = endpoints.map(endpoint =>
    fetch(endpoint, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(request)
    })
  );

  await Promise.all(promises);
  return true;
}

Usage:

// When a new design is created
async function createNewDesign(item: GalleryItem) {
  // ... save to database ...

  // Submit to IndexNow for instant indexing
  await submitToIndexNow([
    `https://nailartai.app/${category}/${slug}`,
    `https://nailartai.app/design/${slug}`
  ]);
}

Results:

New content indexed within hours instead of weeks
Better crawl efficiency
Improved search visibility for fresh content

7. Category Pages SEO Strategy

The Challenge: Category pages need to rank for broad terms like "Christmas Nail Art" while also helping users discover relevant designs.

Our Strategy:

1. Dynamic Metadata Per Category:

// src/app/nail-art-gallery/category/[category]/page.tsx
export async function generateMetadata({ params }): Promise<Metadata> {
  const category = decodeURIComponent(params.category);

  return {
    title: `${category} Nail Art Designs | Nail Art AI`,
    description: `Browse our collection of ${category} nail art designs. Discover stunning AI-generated nail art in the ${category} category.`,
    keywords: [
      category.toLowerCase(),
      `${category} nail art`,
      `${category} nail design`,
      `${category} manicure`,
      'nail art',
      'AI nail art'
    ],
    openGraph: {
      title: `${category} Nail Art Designs`,
      description: `Discover beautiful ${category} nail art designs...`,
      images: [getCategoryThumbnail(category)],
    },
  };
}

2. Structured Data for Category Pages:

const categorySchema = {
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": `${category} Nail Art Designs`,
  "description": `Browse our collection of ${category} nail art...`,
  "mainEntity": {
    "@type": "ItemList",
    "itemListElement": items.map((item, index) => ({
      "@type": "ListItem",
      "position": index + 1,
      "item": {
        "@type": "CreativeWork",
        "name": item.design_name,
        "url": generateItemUrl(item),
      }
    }))
  }
};

3. Internal Linking Strategy:

Category pages link to:

Related categories (color-based, occasion-based)
Popular designs within the category
Related techniques and styles
Parent category (if applicable)

4. Content Distribution:

Each category page includes:

Category description with keywords
Popular designs showcase
Related tags and filters
Breadcrumb navigation
Related categories section

8. Individual Design Page SEO

The Challenge: Each of 600+ design pages needs unique, SEO-optimized content that ranks for specific long-tail keywords.

Our Multi-Layered Approach:

1. AI-Generated Editorial Content:

Every design gets comprehensive editorial content:

// src/lib/geminiService.ts
export async function generateEditorialContentForNailArt(
  designName?: string,
  category?: string,
  prompt?: string
): Promise<NailArtEditorial> {
  const sys = `You are a professional nail artist and SEO copywriter. Create UNIQUE, DESIGN-SPECIFIC content...`;

  const response = await ai.models.generateContent({
    model: 'gemini-2.5-pro',
    contents: {
      parts: [
        { text: sys },
        { text: `Design: ${designName}\nCategory: ${category}\nPrompt: ${prompt}` }
      ],
    },
  });

  // Returns comprehensive content:
  // - SEO-optimized title (50-60 chars)
  // - Meta description (150-160 chars)
  // - Primary keyword + secondary keywords
  // - Quick facts, supplies, steps
  // - FAQs (5-6 Q&A pairs)
  // - Internal links
  // - And 15+ more fields
}

2. Keyword Optimization:

// Extract and optimize keywords from design data
function generateKeywords(item: GalleryItem, editorial: Editorial): string[] {
  const baseKeywords = ['nail art', 'AI nail art', 'nail design', 'manicure'];

  const categoryKeywords = item.category ? [
    `${item.category} nail art`,
    `${item.category} nail design`
  ] : [];

  const colorKeywords = (item.colors || []).map(color => 
    `${color} nail art`
  );

  const techniqueKeywords = (item.techniques || []).map(technique =>
    `${technique} nail art`
  );

  return [
    ...baseKeywords,
    ...categoryKeywords,
    ...colorKeywords,
    ...techniqueKeywords,
    ...(editorial.secondaryKeywords || [])
  ];
}

3. Multiple Structured Data Types:

Each design page includes multiple schema types:

CreativeWork: Main content type
HowTo: Step-by-step tutorial
FAQPage: Q&A section
BreadcrumbList: Navigation hierarchy
ImageObject: Image metadata

4. Internal Linking:

Design pages link to:

Related designs in same category
Related designs with same colors/techniques
Category page
Technique pages
Color pages
Occasion pages

9. Pinterest Automation & RSS Feeds

Why Pinterest Matters:

Pinterest is a visual search engine (450M+ users)
Pins drive traffic for months (unlike social media)
Perfect platform for nail art content
85% of users plan purchases on Pinterest

Our Pinterest Strategy:

1. Pinterest Rich Pins Setup

Rich Pins show additional information (author, category, description) making pins more engaging.

// src/lib/pinterestRichPinsService.ts
export function generatePinterestRichPinMetaTags(data: PinterestRichPinData) {
  return {
    'og:type': 'article',
    'og:title': data.title,
    'og:description': data.description,
    'og:image': data.imageUrl,
    'article:author': data.author,
    'article:published_time': data.publishedTime,
    'article:section': data.section,
    'article:tag': data.tags.join(',')
  };
}

2. Pinterest RSS Feed for Automation

We generate an RSS feed optimized for Pinterest automation tools:

// src/app/api/pinterest/rss/route.ts
export async function GET(request: NextRequest) {
  const items = await getGalleryItems({ limit: 50 });

  const rssXml = `<?xml version="1.0" encoding="UTF-8"?>
    <rss version="2.0" xmlns:pinterest="https://www.pinterest.com/xmlns/">
      <channel>
        <title>Nail Art AI - Latest Designs</title>
        ${items.map(item => `
          <item>
            <title><![CDATA[${item.design_name} - ${item.category} Nail Art]]></title>
            <description><![CDATA[Try this ${item.category} nail art design virtually...]]></description>
            <link>https://nailartai.app/${category}/${slug}</link>
            <enclosure url="${item.image_url}" type="image/jpeg"/>
            <pinterest:image>${item.image_url}</pinterest:image>
            <pinterest:description>${optimizedDescription}</pinterest:description>
          </item>
        `).join('')}
      </channel>
    </rss>`;

  return new NextResponse(rssXml, {
    headers: { 'Content-Type': 'application/rss+xml' }
  });
}

3. Automation Integration

Option A: IFTTT/Zapier

Connect RSS feed to Pinterest:

Trigger: New RSS item
Action: Create Pinterest pin
Automatic pinning of new designs

Option B: Pinterest API (Future)

Direct API integration for programmatic pinning:

Bulk pin creation
Board management
Analytics integration

4. Pinterest Optimization

Each pin includes:

Optimized Title: Under 100 characters, keyword-rich
Compelling Description: Under 500 characters, includes hashtags
High-Quality Image: 1000x1500 pixels (2:3 ratio)
Relevant Hashtags: 5-10 hashtags per pin
Clear CTA: "Try this design virtually!"

RSS Feed URL: https://nailartai.app/api/pinterest/rss

Features:

Automatically includes latest 50 designs
Filterable by category (?category=christmas)
Sortable (?sortBy=newest)
Includes all Pinterest Rich Pin metadata
Optimized for automation tools

10. Marketing SEO Strategies

Beyond Technical SEO: Content Distribution

1. Content Clusters:

We organize content into topical clusters:

Main Category: "Christmas Nail Art" (primary keyword)
├── Related Designs: "Red Christmas Nail Art"
├── Related Techniques: "Gel Polish Christmas Nail Art"
├── Related Occasions: "Holiday Party Nail Art"
└── Related Colors: "Red and Gold Nail Art"

Each cluster internally links to strengthen topical authority.

2. Long-Tail Keyword Targeting:

We target specific, low-competition keywords:

"Christmas nail art with red and gold"
"French manicure for wedding"
"Halloween nail art easy tutorial"
"Summer nail art with glitter"

3. User Intent Optimization:

Pages are optimized for different user intents:

Informational: "How to create Christmas nail art"
Navigational: "Christmas nail art designs"
Transactional: "Try Christmas nail art virtually"

4. Content Freshness:

New designs added weekly
Editorial content updated quarterly
Category pages refreshed monthly
Sitemaps updated automatically

5. Social Signals:

Pinterest pins drive traffic
Social sharing buttons on every page
Optimized Open Graph tags
Twitter Card metadata

6. Local SEO (Future):

For location-based searches:

"Nail art near me"
"Nail salon with virtual try-on"
City-specific category pages

11. SEO Performance Monitoring

Key Metrics We Track:

Indexing Status:
- Number of pages indexed
- Indexing rate (new pages)
- Coverage issues
Rankings:
- Keyword rankings for primary terms
- Category page rankings
- Design page rankings
Traffic Sources:
- Organic search traffic
- Pinterest referrals
- Direct traffic
- Social media
Technical SEO:
- Core Web Vitals scores
- Mobile usability
- Page speed
- Structured data validation

Tools We Use:

Google Search Console: Indexing, coverage, performance
Google Analytics: Traffic, behavior, conversions
Pinterest Analytics: Pin performance, clicks
Bing Webmaster Tools: Additional search engine visibility
IndexNow Dashboard: Instant indexing status

12. SEO Automation

Auto-SEO Service:

When new content is created, we automatically:

Generate SEO metadata
Create structured data
Update sitemaps
Submit to IndexNow
Generate internal links
Create Pinterest Rich Pin data

// src/app/api/auto-seo/route.ts
export async function POST(request: NextRequest) {
  const { content, pageType } = await request.json();

  // Generate complete SEO package
  const seoData = await autoGenerateSEOForNewContent(content, pageType);

  // Update sitemap
  await updateSitemapForNewContent(content);

  // Submit to IndexNow
  await submitToIndexNow([seoData.canonicalUrl]);

  // Generate Pinterest data
  await generatePinterestRichPinData(content);

  return NextResponse.json({ success: true, seoData });
}

Benefits:

Zero manual SEO work
Consistent SEO quality
Instant indexing
Comprehensive optimization

Virtual Try-On Feature

User Flow

User selects a design from gallery
User uploads hand photo
AI applies design to nails
User sees result with comparison slider

Implementation

// src/app/try-on/TryOnContent.tsx
export default function TryOnContent() {
  const [sourceImage, setSourceImage] = useState<string | null>(null);
  const [generatedImage, setGeneratedImage] = useState<string | null>(null);
  const [selectedDesign, setSelectedDesign] = useState<GalleryItem | null>(null);

  const handleGenerate = async () => {
    if (!sourceImage || !selectedDesign) return;

    setIsLoading(true);

    try {
      // Convert image to base64
      const base64Data = await imageToBase64(sourceImage);

      // Call AI API
      const response = await fetch('/api/generate-nail-art', {
        method: 'POST',
        body: JSON.stringify({
          base64ImageData: base64Data,
          mimeType: 'image/jpeg',
          prompt: selectedDesign.prompt,
        }),
      });

      const { imageData } = await response.json();
      setGeneratedImage(`data:image/jpeg;base64,${imageData}`);
    } catch (error) {
      setError('Failed to generate image');
    } finally {
      setIsLoading(false);
    }
  };

  return (
    <div>
      <StepIndicator currentStep={currentStep} />
      {currentStep === 1 && <DesignGalleryGrid onSelect={setSelectedDesign} />}
      {currentStep === 2 && <EnhancedUploadArea onUpload={setSourceImage} />}
      {currentStep === 3 && (
        <DraggableComparisonSlider
          before={sourceImage}
          after={generatedImage}
        />
      )}
      <StickyGenerateButton
        onGenerate={handleGenerate}
        disabled={!sourceImage || !selectedDesign}
      />
    </div>
  );
}

Image Processing

// Convert file to base64
function imageToBase64(file: File): Promise<string> {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.onload = () => {
      const result = reader.result as string;
      resolve(result.split(',')[1]); // Remove data URL prefix
    };
    reader.onerror = reject;
    reader.readAsDataURL(file);
  });
}

Admin Dashboard & Content Management

Bulk Content Generation

We built scripts to generate hundreds of designs automatically:

// scripts/generate-bulk-nail-art.js
const PROMPT_CATEGORIES = [
  { name: 'Christmas Nail Art', prompts: [...], priority: 1 },
  { name: 'Valentine Nail Art', prompts: [...], priority: 2 },
  // ... 185+ categories
];

async function generateForCategory(category, count) {
  for (const prompt of category.prompts.slice(0, count)) {
    // Generate image
    const imageData = await generateNailArtImage(prompt);

    // Upload to storage
    const imageUrl = await uploadToR2(imageData);

    // Save to database
    await supabase.from('gallery_items').insert({
      image_url: imageUrl,
      prompt: prompt,
      design_name: extractDesignName(prompt),
      category: category.name,
      colors: extractColors(prompt),
      techniques: extractTechniques(prompt),
      // ... more tags
    });

    // Generate editorial content (async, non-blocking)
    generateEditorialAsync(item.id);
  }
}

Editorial Content Generation

// Generate rich content for each design
async function generateEditorialForItem(item: GalleryItem) {
  const editorial = await generateEditorialContentForNailArt(
    item.design_name,
    item.category,
    item.prompt
  );

  await supabase.from('gallery_editorials').insert({
    gallery_item_id: item.id,
    title: editorial.title,
    intro: editorial.intro,
    primary_keyword: editorial.primaryKeyword,
    secondary_keywords: editorial.secondaryKeywords,
    supplies: editorial.supplies,
    steps: editorial.steps,
    faqs: editorial.faqs,
    // ... 20+ more fields
  });
}

Challenges We Faced & Solutions

1. AI API Costs

Challenge: Generating images and content for 600+ designs is expensive.

Solution:

Rate limiting to prevent abuse
Batch processing during off-peak hours
Caching generated content
Using cheaper models (flash) when possible, pro only for editorial

2. Image Storage Costs

Challenge: Storing thousands of high-resolution images.

Solution:

Dual storage: Supabase for transactional, R2 for CDN
Image compression (60-65% quality)
Responsive image sizes
CDN caching (1-year TTL)

3. SEO for 1,600+ Pages

Challenge: Each design needs unique, SEO-optimized content.

Solution:

AI-generated editorial content for each design
Dynamic metadata generation
Structured data (JSON-LD)
Multiple sitemaps
Image alt text generation

4. Performance on Mobile

Challenge: Large images and complex layouts slow on mobile.

Solution:

Mobile-specific image sizes
Lazy loading
Code splitting
Critical CSS inlining
Service worker for caching

5. Database Query Performance

Challenge: Complex queries with arrays and joins.

Solution:

GIN indexes on array columns
Query optimization (select only needed fields)
Caching layer
Pagination

What's Next

Planned Features

User Accounts: Save favorite designs, personal galleries
Social Sharing: Share designs on Pinterest, Instagram
Advanced Filters: Filter by difficulty, time, cost
AR Try-On: Real-time AR using camera
Design Customization: Edit colors, add patterns
Community: User-submitted designs, ratings
Salon Integration: Book appointments directly

Technical Improvements

GraphQL API: More flexible queries
Real-time Updates: WebSocket for live gallery updates
Advanced Caching: Redis for query caching
Image Processing: On-the-fly image transformations
Analytics: User behavior tracking
A/B Testing: Test different UI variations

Key Takeaways

Choose the right tools: Next.js + Supabase + Cloudflare R2 + Gemini = perfect stack for this use case
Optimize early: Performance optimizations should be considered from day one
SEO matters: With 1,600+ pages, proper SEO implementation is crucial
AI is expensive: Rate limiting and caching are essential
Mobile first: Most users will be on mobile, optimize accordingly
Iterate fast: Use AI to generate content, focus on user experience

Conclusion

Building NailArt AI has been an incredible learning experience. Combining modern web technologies with cutting-edge AI capabilities has allowed us to create something truly unique. The platform is now live at nailartai.app with 600+ designs and growing.

If you're building something similar, I hope this breakdown helps! Feel free to reach out with questions or check out the code on GitHub.

Tech Stack Summary:

Frontend: Next.js 15, React 19, Tailwind CSS 4
Backend: Next.js API Routes, Server Components
Database: Supabase PostgreSQL
Storage: Supabase Storage + Cloudflare R2
AI: Google Gemini API
Deployment: Vercel
CDN: Cloudflare R2

Links:

Live App

Questions? Comments? Let me know in the comments below!

DEV Community: Devanshu Goyal

I Gave My 3AM Self a Memory: Building on Cognee's Memory Lifecycle

What I Built

The 3AM Hangover

Why a Graph, Not RAG

The Four-Verb Lifecycle

remember(): The Night, Ingested

recall(): The Morning Debrief

improve(): Memory That Learns

forget(): Deletion as a Feature

The Tenant That Didn't Exist

A Bug on a Live Platform

Four Lessons for Cognee Builders

Architecture at a Glance

FAQ

Sources and Links

Building NailArt AI: A Complete Technical Breakdown

How I Built an AI-Powered Virtual Nail Art Try-On Platform with 600+ Designs

Table of Contents

Introduction

The Problem We're Solving

Tech Stack & Why We Chose Each Technology

Frontend: Next.js 15 + React 19 + Tailwind CSS 4

Backend: Next.js API Routes + Server Components

Database: Supabase PostgreSQL

Storage: Cloudflare R2 + Supabase Storage

AI: Google Gemini API

Deployment: Vercel

Architecture Overview

High-Level Architecture

Folder Structure

AI Integration: Google Gemini

Image Generation Flow

Rate Limiting

Database Design: Supabase PostgreSQL

Key Design Decisions

Query Examples

Storage Architecture: Dual-Layer Strategy

Why Two Storage Systems?

Implementation

Automatic Sync

Performance Optimizations

1. Image Optimization

2. Code Splitting

3. Database Query Optimization

4. Server Components

5. Critical CSS Inlining

SEO Implementation: A Comprehensive Strategy

1. Dynamic Metadata Generation

2. Structured Data (JSON-LD)

3. Sitemaps

4. Image SEO

5. Advanced Sitemap Strategy

6. IndexNow Implementation: Instant Indexing

7. Category Pages SEO Strategy

8. Individual Design Page SEO

9. Pinterest Automation & RSS Feeds

10. Marketing SEO Strategies

11. SEO Performance Monitoring

12. SEO Automation

Virtual Try-On Feature

User Flow

Implementation

Image Processing

Admin Dashboard & Content Management

Bulk Content Generation

Editorial Content Generation

Challenges We Faced & Solutions

1. AI API Costs

2. Image Storage Costs

3. SEO for 1,600+ Pages

4. Performance on Mobile

5. Database Query Performance

What's Next

Planned Features

Technical Improvements

Key Takeaways

Conclusion

`remember()`: The Night, Ingested

`recall()`: The Morning Debrief

`improve()`: Memory That Learns

`forget()`: Deletion as a Feature