Forem: Kamil Uhryn

Building TouchSlides: A Real-Time Presentation Remote on Cloudflare's Edge

Kamil Uhryn — Mon, 10 Nov 2025 19:27:54 +0000

How I built a globally-distributed, lightning-fast presentation remote control app using Cloudflare Workers, Durable Objects, and Next.js

Full disclosure: This was my first time diving deep into Cloudflare's edge platform. I'd only used their free Web Analytics before and was genuinely curious - could the "edge" really be that fast? What started as a weekend side project to scratch my own itch turned into a surprisingly polished piece of software that I now use for all my presentations. Spoiler alert: the performance claims are real. 🚀

The Problem That Started It All 🎯

We've all been there. You're about to give an important presentation. Your laptop is connected to the projector, slides are ready, but you're stuck behind a podium, tethered to your computer by a clicker that barely works. You can't walk around, engage with your audience, or check your speaker notes without awkwardly turning away from them.

I wanted something better: a presentation remote that works on any phone, from anywhere in the world, with zero lag. No apps to install, no Bluetooth pairing, no proximity requirements. Just open a URL on your phone and control your presentation in real-time.

That's how TouchSlides was born.

The Vision: Edge-First, Real-Time, Global 🌍

From day one, I had three non-negotiable requirements:

Sub-100ms latency - Slide changes must feel instant
Works anywhere - No geographic limitations
Zero setup - Share a PIN, scan a QR code, done

Traditional architectures wouldn't cut it. A centralized server would add latency for global users. WebSockets from a single origin would struggle with scale. I needed something distributed by default, running as close to users as possible.

Enter Cloudflare Workers.

Why Cloudflare's Edge Network? 🚀

Cloudflare Workers run your code in over 300+ data centers worldwide. When someone in Tokyo uses TouchSlides, their requests hit Tokyo servers. When someone in London connects, they hit London servers. No cross-continental roundtrips. No single points of failure.

But here's the really clever part: Durable Objects.

The Real-Time Sync Challenge 🔄

WebSockets are stateful. You need a server that stays alive and remembers connections. But Workers are stateless by design - they spin up, handle a request, and disappear. How do you maintain persistent WebSocket connections?

Durable Objects solve this beautifully. They're stateful objects that live on the edge, with guaranteed single-instance consistency. Think of them as mini-servers that:

Maintain WebSocket connections
Store state in memory
Live in the nearest data center to your users
Automatically handle failover

Here's how my PresentationSession Durable Object works:

export class PresentationSession {
  private state: DurableObjectState;
  private presenter: WebSocket | null = null;
  private remotes: Map<string, WebSocket> = new Map();
  private currentSlide: number = 0;

  constructor(state: DurableObjectState) {
    this.state = state;
  }

  async fetch(request: Request) {
    const url = new URL(request.url);
    const role = url.searchParams.get('role'); // 'presenter' or 'remote'
    const userId = url.searchParams.get('userId');

    const pair = new WebSocketPair();
    const [client, server] = Object.values(pair);

    server.accept();

    if (role === 'presenter') {
      this.presenter = server;
      this.broadcast({ type: 'presenter_connected' });
    } else {
      this.remotes.set(userId, server);
      this.broadcast({ type: 'remote_connected', data: { userId } });
    }

    server.addEventListener('message', (event) => {
      const message = JSON.parse(event.data);
      this.handleMessage(message, role);
    });

    return new Response(null, { status: 101, webSocket: client });
  }

  private handleMessage(message: any, senderRole: string) {
    switch (message.type) {
      case 'slide_change':
        this.currentSlide = message.slideIndex;
        this.broadcast({ 
          type: 'slide_change', 
          slideIndex: message.slideIndex 
        }, senderRole);
        break;
      case 'next_slide':
        this.currentSlide++;
        this.broadcast({ type: 'slide_change', slideIndex: this.currentSlide });
        break;
      // ... more message types
    }
  }

  private broadcast(message: any, excludeRole?: string) {
    const payload = JSON.stringify({ ...message, timestamp: Date.now() });

    if (excludeRole !== 'presenter' && this.presenter) {
      this.presenter.send(payload);
    }

    if (excludeRole !== 'remote') {
      this.remotes.forEach(remote => remote.send(payload));
    }
  }
}

What makes this special?

Automatic proximity - Cloudflare routes connections to the nearest Durable Object instance
Zero coordination - Each presentation has exactly one Durable Object, guaranteed
Instant broadcast - All connected remotes get updates simultaneously
Fault tolerance - If a data center fails, Cloudflare migrates the object

The Architecture: Four Layers Working in Harmony 🏗️

Layer 1: The Frontend (Next.js 14 + App Router) 🎨

I chose Next.js 14 with the new App Router for its server component capabilities and edge runtime support. The UI is built with:

Tailwind CSS for rapid, consistent styling
Framer Motion for smooth animations
Lucide React for beautiful icons

Key pages:

/                    → Landing page
/dashboard           → List of presentations
/edit/[id]           → Upload slides, add notes
/present/[id]        → Full-screen presenter view
/remote/[id]         → Mobile remote controller
/p/[pin]             → Public share page

The design philosophy: Dark gradients, glass morphism, rounded corners. I wanted it to feel premium-like Apple's attention to detail combined with Headspace's calming aesthetics.

// Example: The remote controller
'use client';

export default function RemotePage({ params }) {
  const [presentation, setPresentation] = useState(null);
  const [currentSlide, setCurrentSlide] = useState(0);
  const [ws, setWs] = useState(null);

  useEffect(() => {
    const websocket = new WebSocket(
      `${WORKER_URL}/api/ws/presentation/${params.id}?role=remote&userId=${userId}`
    );

    websocket.onmessage = (event) => {
      const message = JSON.parse(event.data);
      if (message.type === 'slide_change') {
        setCurrentSlide(message.slideIndex);
      }
    };

    setWs(websocket);
  }, [params.id]);

  const goToNextSlide = () => {
    ws.send(JSON.stringify({ type: 'next_slide' }));
  };

  return (
    <div className="mobile-remote">
      <button onClick={goToNextSlide}>Next →</button>
      <div className="notes">{presentation.slides[currentSlide].notes}</div>
    </div>
  );
}

Layer 2: The Worker (Hono + TypeScript) ⚙️

Cloudflare Workers are JavaScript/TypeScript functions that run on every request. I used Hono - a blazingly fast web framework (think Express, but for the edge).

My worker handles:

Authentication (JWT tokens)
REST API (presentations, slides, users)
WebSocket upgrades (routing to Durable Objects)
Static file serving (images from R2)

// Main worker entry point
import { Hono } from 'hono';
import { cors } from 'hono/cors';
import authRouter from './routes/auth';
import presentationsRouter from './routes/presentations';
import slidesRouter from './routes/slides';
import websocketRouter from './routes/websocket';

const app = new Hono<{ Bindings: Env }>();

// CORS middleware
app.use('*', cors({
  origin: (origin) => origin, // Validated against ALLOWED_ORIGINS
  credentials: true,
}));

// API routes
app.route('/api/auth', authRouter);
app.route('/api/presentations', presentationsRouter);
app.route('/api/slides', slidesRouter);
app.route('/api/ws', websocketRouter);

export default app;

Why Hono over vanilla Workers?

Type-safe routing with TypeScript
Middleware composition
Request validation with Zod
Cleaner code organization

Layer 3: Data Storage (D1 + R2 + KV) 💾

Cloudflare offers three storage primitives, each optimized for different use cases:

D1 (SQLite at the Edge) 🗄️

Relational database for structured data. My schema:

CREATE TABLE users (
  id TEXT PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  password_hash TEXT NOT NULL,
  name TEXT NOT NULL,
  created_at TEXT DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE presentations (
  id TEXT PRIMARY KEY,
  user_id TEXT NOT NULL,
  title TEXT NOT NULL,
  pin TEXT UNIQUE NOT NULL, -- 6-digit PIN for public access
  transition_type TEXT DEFAULT 'fade',
  share_enabled INTEGER DEFAULT 0,
  share_notes TEXT,
  created_at TEXT DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

CREATE TABLE slides (
  id TEXT PRIMARY KEY,
  presentation_id TEXT NOT NULL,
  slide_key TEXT NOT NULL, -- R2 object key
  thumbnail_key TEXT NOT NULL,
  notes TEXT,
  order_index INTEGER NOT NULL,
  FOREIGN KEY (presentation_id) REFERENCES presentations(id) ON DELETE CASCADE
);

Key design decisions:

PIN system - Every presentation gets a unique 6-digit PIN for easy sharing
Cascading deletes - Delete a presentation, slides go too
Order index - Enables drag-and-drop reordering
Share settings - Control public access and add custom notes

R2 (Object Storage) 📦

S3-compatible storage for slides and thumbnails. Zero egress fees (huge cost saver).

// Upload slide to R2
export class StorageService {
  async uploadSlide(
    key: string, 
    file: ArrayBuffer, 
    contentType: string
  ): Promise<void> {
    await this.env.PRESENTATIONS_BUCKET.put(key, file, {
      httpMetadata: { contentType }
    });
  }

  async getSlide(key: string): Promise<Response> {
    const object = await this.env.PRESENTATIONS_BUCKET.get(key);
    if (!object) throw new Error('Slide not found');

    return new Response(object.body, {
      headers: { 'Content-Type': object.httpMetadata?.contentType || 'image/jpeg' }
    });
  }
}

KV (Key-Value Store) ⚡

Ultra-fast, eventually-consistent storage for sessions and cache.

// Session management
export class SessionService {
  async createSession(userId: string, token: string): Promise<void> {
    await this.env.SESSIONS.put(
      `session:${userId}`, 
      token, 
      { expirationTtl: 60 * 60 * 24 * 30 } // 30 days
    );
  }
}

Why this three-tier approach?

D1 for queries and relations (user → presentations → slides)
R2 for binary data (images, future: PDFs)
KV for hot data (sessions, active connections)

Layer 4: Real-Time Sync (WebSockets + Durable Objects) 🔌

This is where the magic happens. When a presenter advances a slide:

Presenter's browser sends WebSocket message → Durable Object
Durable Object updates state → broadcasts to all remotes
Remote phones receive update → UI updates instantly

Latency breakdown:

Browser → Edge: ~10-30ms (local network)
Edge → Durable Object: <5ms (same data center)
Durable Object → Remotes: ~10-30ms (parallel broadcast)

Total: 25-65ms - faster than human reaction time!

The Architecture: Four Layers Working in Harmony 🏗️

Compare this to traditional WebSocket servers:

Browser → Server: 50-200ms (geographic distance)
Server processing: 10-50ms
Server → Clients: 50-200ms per client (sequential)

Total: 110-450ms - noticeable lag.

The Security Layer 🔒

Authentication is JWT-based with bcrypt password hashing:

// Signup
export async function signup(email: string, password: string, name: string) {
  const passwordHash = await bcrypt.hash(password, 10);
  const userId = generateId();

  await db.run(
    'INSERT INTO users (id, email, password_hash, name) VALUES (?, ?, ?, ?)',
    [userId, email, passwordHash, name]
  );

  const token = await new jose.SignJWT({ userId, email })
    .setProtectedHeader({ alg: 'HS256' })
    .setExpirationTime('30d')
    .sign(new TextEncoder().encode(JWT_SECRET));

  return { token, user: { id: userId, email, name } };
}

// Auth middleware
export const authMiddleware = async (c, next) => {
  const token = c.req.header('Authorization')?.replace('Bearer ', '');
  if (!token) return c.json({ error: 'Unauthorized' }, 401);

  try {
    const { payload } = await jose.jwtVerify(
      token, 
      new TextEncoder().encode(c.env.JWT_SECRET)
    );
    c.set('userId', payload.userId);
    await next();
  } catch {
    return c.json({ error: 'Invalid token' }, 401);
  }
};

Security features:

bcrypt hashing (10 rounds)
JWT with 30-day expiry
CORS validation
SQL injection prevention (prepared statements)
File type validation
PIN uniqueness checks

The Challenges I Overcame 💪

Challenge 1: WebSocket State Management 🎯

Problem: Durable Objects can migrate between requests. How do you maintain connection state?

Solution: Store connections in memory within the Durable Object. When messages arrive, route them through the object's state machine. Cloudflare handles persistence.

Challenge 2: Image Upload Optimization 🖼️

Problem: Large images would timeout or consume too much memory.

Solution:

Validate file size on client (max 10MB)
Use streaming uploads to R2
Generate thumbnails on the edge (future: Workers AI)
Return immediately, process async

// Streaming upload
const formData = await request.formData();
const file = formData.get('file') as File;

const arrayBuffer = await file.arrayBuffer();
const key = `${presentationId}/${generateId()}.jpg`;

await env.PRESENTATIONS_BUCKET.put(key, arrayBuffer, {
  httpMetadata: { contentType: file.type }
});

Challenge 3: Cross-Region Consistency 🌐

Problem: D1 replicates globally, but writes happen in one region. How do you ensure reads see latest data?

Solution:

Accept eventual consistency for non-critical reads (presentation lists)
Use KV for session data (fast, eventually consistent)
Rely on Durable Objects for real-time state (strongly consistent)

Challenge 4: The Share Feature 🔗

Recently, I added a share feature where presenters can:

Enable public sharing with a toggle
Add custom notes for viewers
Upload additional files (PDFs, documents)
Generate a short URL: touchslides.com/p/{PIN}

The challenge: How to update the database schema without breaking production?

The solution: Cloudflare D1 supports ALTER TABLE with zero downtime:

# Add columns to remote database
npx wrangler d1 execute touchslides-db-dev --env dev --remote \
  --command "ALTER TABLE presentations ADD COLUMN share_enabled INTEGER DEFAULT 0;"

npx wrangler d1 execute touchslides-db-dev --env dev --remote \
  --command "ALTER TABLE presentations ADD COLUMN share_notes TEXT;"

npx wrangler d1 execute touchslides-db-dev --env dev --remote \
  --command "ALTER TABLE presentations ADD COLUMN share_files TEXT;"

# Deploy updated code
npx wrangler deploy --env dev

Zero downtime. Existing rows got default values, new rows got the new schema.

The Performance Numbers 📊

After deploying to production, here are the metrics:

Metric	Value	Comparison
Slide change latency	25-65ms	Zoom: 150-300ms
Cold start time	<5ms	AWS Lambda: 100-500ms
Database query time	10-30ms	PostgreSQL: 50-200ms
Image load time	50-150ms	CDN: 100-300ms
Monthly cost (1000 users)	~$5	Traditional: $50-200

Why so fast?

Workers start instantly (V8 isolates, not containers)
Durable Objects live in-region
R2 serves from global cache
D1 replicates to 300+ locations
No cold starts, no VPC, no NAT

The Developer Experience 👨‍💻

One of my favorite parts about this stack is the local development experience:

# Terminal 1: Start the worker locally
npm run worker:dev
# → http://localhost:8787

# Terminal 2: Start Next.js
npm run dev
# → http://localhost:3000

Everything works offline:

D1 uses local SQLite
R2 uses local filesystem simulation
KV uses local memory
Durable Objects work in Miniflare

No cloud account needed for development!

What I'd Do Differently 🤔

Looking back, here's what I'd change:

Start with Durable Objects immediately - I initially tried polling, then server-sent events. WebSockets via Durable Objects was always the right answer.
Add proper error boundaries earlier - The frontend needed better error handling from day one.
Use Cloudflare Images - I'm manually handling thumbnails. Cloudflare Images would've saved time.
Implement rate limiting - Easy to add with Workers, should've been there from the start.
Better TypeScript types - The Worker <-> Frontend contract could be more type-safe.

The Future Roadmap 🗺️

I'm actively working on:

PDF upload & conversion - Using Cloudflare Workers AI
Slide annotations - Draw on slides in real-time
Presenter mode timer - Built-in countdown
QR code final slide - Auto-generated share slide
Analytics dashboard - Engagement tracking
Team collaboration - Multiple presenters

Lessons Learned 📚

1. Edge-first architecture is the future 🌟

Traditional client-server architecture adds 100-500ms of latency. Edge computing brings that down to 10-50ms. For real-time apps, this is game-changing.

2. Durable Objects are underrated 💎

They solve the stateful-at-the-edge problem elegantly. No Redis, no coordination, no locks. Just pure, distributed state.

3. Cloudflare's free tier is incredible 🆓

For indie hackers and small projects:

100,000 requests/day on Workers
1GB storage on R2 (zero egress!)
Unlimited reads on KV
D1 included with 5GB storage

This entire app runs on the free tier for hobby projects.

4. TypeScript is non-negotiable ✅

The Worker codebase is 100% TypeScript. Catching errors at compile time saved me hours of debugging.

5. Keep it simple first 🎯

I started with basic features: upload slides, show them, control remotely. Only after that worked did I add animations, transitions, and advanced features.

The Tech Stack Summary 🛠️

Frontend:

Next.js 14 (App Router, React Server Components)
Tailwind CSS (custom design system)
Framer Motion (animations)
Lucide React (icons)

Backend:

Cloudflare Workers (global compute)
Hono 4.6 (routing framework)
TypeScript (type safety)
Zod (validation)

Storage:

D1 (SQLite database)
R2 (object storage)
KV (key-value store)

Real-Time:

Durable Objects (WebSocket state)
WebSocket API (bidirectional communication)

Security:

bcrypt (password hashing)
jose (JWT tokens)
CORS middleware
Prepared statements

Development:

Wrangler (Cloudflare CLI)
Miniflare (local simulation)
TypeScript compiler
ESLint (linting)

How to Get Started 🚀

Want to build something similar? Here's my advice:

Start with Wrangler:

   npm create cloudflare@latest my-app
   cd my-app
   npm install hono

Add a Durable Object:

   export class MyObject {
     async fetch(request: Request) {
       return new Response('Hello from the edge!');
     }
   }

Connect from the frontend:

   const ws = new WebSocket('wss://my-app.workers.dev/ws');
   ws.onmessage = (event) => console.log(event.data);

Deploy:

   npx wrangler deploy

Seriously, it's that simple.

Open Source & Links 🔗

TouchSlides is open source! Check out:

Code: github.com/vegetablecode/touchslides
Live Demo: touchslides.com
Architecture Docs: BACKEND_SETUP.md

I'd love to hear your feedback, questions, or suggestions. Feel free to open issues or contribute!

Final Thoughts 💭

Building TouchSlides taught me that the edge is ready for production. Cloudflare Workers aren't just for static sites or simple APIs - they can handle complex, stateful, real-time applications with ease.

The combination of Workers + Durable Objects + D1 + R2 is incredibly powerful. You get:

Global distribution by default
Sub-100ms latency worldwide
Infinite scale (auto-scaling)
Minimal cost (pay-per-use)
Great DX (local development)

If you're building anything real-time - chat apps, collaborative editors, live dashboards, multiplayer games - consider the edge first. Your users will thank you for the speed.

Questions? Comments? Drop them below! I'm happy to dive deeper into any part of the architecture.

Want to try TouchSlides? Visit touchslides.com and experience sub-100ms presentation control for yourself.

Happy building! 🚀

Kamil Uhryn

Full-Stack Developer | Edge Computing Enthusiast

GitHub | Twitter | Website

I Waited 5 Years for AI to Be Good Enough to Build This: A Fully Automatic Logo Designer

Kamil Uhryn — Sun, 02 Nov 2025 18:08:52 +0000

TL;DR

Built GoodLogoAI - an AI logo maker that outputs production-ready vector SVG + transparent PNG files. $9.99 one-time payment. Had the vision in 2019, but had to wait for AI models to mature. Now it's finally viable.

The 5-Year Wait

Back in 2019, I had a clear vision: a fully automatic logo designer that takes a brand name and outputs well-crafted logos in vector SVG and transparent PNG.

No templates. No manual design work. Just intelligent AI that understands design principles.

The problem? In 2019, AI couldn't do this. Not even close.

I tested:

GPT-2 (couldn't understand visual design)
Early GAN image generators (rasterized garbage)
Vector generation models (didn't exist yet)
Template-based systems (not "true" AI)

Every single one failed the litmus test: "Could a real business use this logo?"

Answer: No.

So I waited. And watched. And tested every new model that dropped.

The Catalyst

In 2022, I was preparing for my biggest investor pitch. I needed a logo. Fast.

Called 5 designers:

"That'll be $500, I can have concepts in 2-3 weeks"
"My minimum is $800, 3-week turnaround"
"I'm booked for the next month"

I had 3 days.

Tried to DIY it in Canva. Spent 8 hours. It looked like a 12-year-old designed it.

That frustration crystalized the vision: This should be automated. This should be instant. This should cost $10, not $500.

But the AI still wasn't ready.

2025: The Technology Finally Caught Up

Three things converged in 2025 that made this finally possible:

1. Better Generative Models

Modern diffusion models + GPT-4 class language models could finally understand:

Design principles (balance, hierarchy, negative space)
Color theory and psychology
Typography rules
Brand positioning

2. Vector Generation Breakthrough

The ability to generate clean vector paths (not just rasterized images) became viable. This was the game-changer.

SVG output isn't just "nice to have" - it's essential for:

Infinite scalability
Print production
Professional use
File size efficiency

3. Natural Language Editing

Being able to refine with prompts like "make it more modern" or "use blue tones" without regenerating from scratch = crucial UX improvement.

How It Works (Technical Overview)

The Pipeline

User Input (brand name, industry, style)
    ↓
AI Analysis Layer
    ↓
Logo Concept Generation (30 seconds)
    ↓
Vector Path Construction
    ↓
Output: SVG + PNG (4096x4096)
    ↓
User Refinement (natural language)
    ↓
Iterative Improvement Loop

Key Technical Challenges Solved

Challenge 1: Vector Generation

Rasterized AI outputs don't scale
Had to ensure clean, production-ready SVG paths
Solution: recraft-vectorize

Challenge 2: Consistency Across Edits

Users need to refine, not start over
Had to maintain design identity through iterations
Solution: Contextual editing that remembers the design system

Challenge 3: Design Quality

AI can generate "something" - but is it GOOD?
Had to encode design principles into the system
Solution: crystal-upscaler

Challenge 4: Speed

Users expect instant results
Had to optimize inference time without sacrificing quality
Solution: ~30 second generation time

The Stack

Frontend:

Next.js 14 (App Router)
Tailwind CSS for styling
Framer Motion for animations
Zustand for state management

Backend:

Firebase
Stripe for payments
PostHog for tracking users
Cloudflare Analytics

AI/ML:

Google nano-banana for initial concept and editing
Vector generation pipeline
Natural language processing for edits

Infrastructure:

Vercel for frontend
CDN for asset delivery
Firebase Storage for logo designs

Lessons from Building This

1. Sometimes You Have to Wait for the Technology

I wanted to build this in 2019. But the AI models weren't ready. If I had forced it then, it would've been another mediocre tool.

Lesson: Not every idea's time is NOW. Sometimes the best move is to watch the space and wait for the enabling technology.

2. Pricing is a Product Decision

I could've priced this at $29, $49, or $99. I went with $9.99.

Why? Because when I got ghosted by that designer, I would've paid $10 without thinking twice. I would've hesitated at $50.

The goal isn't to maximize per-sale revenue. It's to make this accessible to every founder who's getting quoted $500+ by designers.

3. SEO from Day 1 (Learned This the Hard Way)

My first app hit $40K revenue. But I didn't start SEO until month 4. Huge mistake.

This time:

Proper meta tags from day 1
Content strategy planned out
Keywords researched before launch
Internal linking structure designed

Result: Google indexed me in 3 days instead of 3 weeks.

4. Don't Buy Backlinks on Fiverr

Yeah, I made this mistake with app #1. Paid $200 for "high DA backlinks."

Google penalized me in 2 weeks. Took 3 months to recover.

Build links naturally or don't build them at all.

5. Track Everything from Launch

I added PostHog on day 1 this time. With app #1, I waited 3 months.

Being able to see exactly where users drop off in the funnel = invaluable.

I found out 40% were leaving because the "Try Free" button wasn't clear enough. Changed it. Conversion jumped 2x.

Tool recommendation: PostHog is fantastic for this. Open source, easy to set up, and the free tier is generous.

6. Production Hunt is Overrated for Traffic

Everyone says "launch on Product Hunt!" I did. Got 50 users.

Know what got me 5,000+ users? SEO.

Don't get me wrong - PH is great for:

Initial validation
Getting a backlink (DA 90+)
Social proof ("Featured on Product Hunt")

But don't expect it to solve distribution. It won't.

Current State

Launched: October 30, 2025
Users: 100+ logos created
Revenue: Starting from $0 (first app did $40K, but this is fresh)
Stack: Fully automated, no manual intervention needed
Pricing: $9.99 one-time payment

What's working:

AI quality is solid (98% satisfaction rate)
Conversion rate is good (~5%)
Word of mouth is picking up
SEO is starting to compound

What's not:

Traffic is still early stage
Haven't cracked paid acquisition yet (testing)
Need more content marketing

The Hardest Part

You know what the hardest part of building this was?

The waiting.

Sitting on a vision for 5 years while the technology slowly caught up. Watching other people launch "AI logo makers" with template systems and rasterized outputs. Wondering if my vision was even possible.

But also knowing that if I launched too early, it would be just another mediocre tool.

Sometimes the best thing you can do as a builder is wait for the enabling technology to be ready.

Try It Out

If you're curious what 5 years of waiting and current AI tech can produce:

GoodLogoAI

Try free (2 edits, no credit card)
Download vector SVG + transparent PNG
$9.99 one-time payment
No subscription, you own it forever

I'd genuinely love feedback from this community. Technical feedback especially welcome.

Questions I'm Happy to Answer

Technical implementation details (within reason - some is proprietary)
Challenges in building AI products
Going from first app ($40K) to second app ($0)
SEO strategy for SaaS
Building in public experiences
Anything about the 5-year journey

Drop your questions below. 👇

Discussion Topics

For the dev.to community:

Have you ever had to wait years for technology to catch up to your vision?
What AI projects are you working on?
Vector generation - anyone else tackling this problem?
Thoughts on AI + design automation?
Should I open-source parts of this? (Considering it)

Let's discuss! 💬