I just launched 24picture — an all-in-one AI image studio with 9 specialized tools. Built with PHP 8.4, MySQL 8.4, and Nginx.

In this post I'll share the architecture decisions, the nastiest bug I encountered, and what I learned shipping a real AI product.

What I Built

Instead of yet another "text to image" wrapper, I built a platform with 9 tools:

• Text to Image — 3 AI models, up to 4K resolution
• Image to Image — transform existing photos
• AI Upscale — enhance images up to 4K
• AI Model — virtual model photography
• AI Tattoo Design — custom flash sheets in 7 tattoo styles
• AI Sticker Maker — die-cut stickers from text prompts
• Photo to Anime — turn photos into anime art
• AI Photo Notes — stylized photo annotations
• AI Polish — one-click prompt enhancement via DeepSeek API

All tools share the same backend — one create.php to submit jobs, one status.php to poll results. The frontend does prompt template assembly per tool.

Tech Stack

Why PHP with No Framework?

Controversial take: for an API-centric product with ~15 endpoints, a framework adds more complexity than it solves. Raw PHP 8.4 with PDO, strict typing, and a single config.php bootstrap keeps things dead simple. The entire backend is about 2,000 lines of code.

Architecture: One Backend, Nine Tools

The key design decision was making all 9 tools share the same backend pipeline:

Frontend (per-tool UI)
  → assembles prompt from user inputs
  → POST /api/generate/create.php
    → deduct credits
    → call AI API
    → save generation record
  → poll GET /api/generate/status.php
    → check AI API status
    → on success: save result, create thumbnail, send email
    → return result to frontend

Adding a new tool means creating a new HTML page that assembles a different prompt template. Zero backend changes. I went from 3 tools to 9 in a single day using this pattern.

The Nastiest Bug: 4K Thumbnails Crashing PHP

This one took me a while to figure out. Users would generate a 4K image successfully, but the status endpoint would return a 500 error — every single time. The image was ready on the AI provider's side, but our server kept crashing when trying to process it.

The Problem

When a generation completes, status.php creates a thumbnail using PHP's GD library:

$src = imagecreatefromstring($imgData);

For a 4K image (roughly 4096 × 2304 pixels), GD needs to hold the uncompressed bitmap in memory:

4096 × 2304 × 4 bytes (RGBA) × 2.5 (overhead) ≈ 94 MB

PHP's default memory limit is 128MB. With the rest of the script's memory usage, this pushed it over the edge. The fatal memory error killed the script before the database was updated, so the next poll attempt would try the same thing — an infinite crash loop.

The Fix

Three changes:

1. Update the database FIRST, before attempting the thumbnail:

// Mark as success immediately
$stmt = $db->prepare('UPDATE generations SET status = "success", 
    result_url = ?, completed_at = NOW() WHERE task_id = ?');
$stmt->execute([$resultUrl, $taskId]);

// THEN try thumbnail (best-effort)
try {
    $thumbUrl = createThumbnail($resultUrl, $gen['id']);
} catch (\Throwable $e) {
    error_log("Thumbnail failed: " . $e->getMessage());
}

Even if the thumbnail crashes, the next poll returns cached success.

2. Memory estimation before loading the image:

$info = getimagesizefromstring($imgData);
$needed = $info[0] * $info[1] * ($info['channels'] ?? 4) 
          * ($info['bits'] ?? 8) / 8 * 2.5;
if ($needed > 128 * 1024 * 1024) {
    return null; // skip thumbnail for huge images
}
ini_set('memory_limit', '256M');

3. Wrap everything after the DB update in try-catch so no post-processing error can block the response.

Lesson Learned

Always persist your state change before doing expensive side effects. If your script can crash during step N, make sure steps 1 through N-1 are already committed.

This applies to any pipeline: payment processing, webhook handling, email sending — commit the critical state first.

Credit System Design

I chose pay-as-you-go credits instead of subscriptions:

Credits never expire. Free credits on signup. This removes the "am I getting my money's worth?" anxiety that subscriptions create.

For the backend, credit deduction uses a simple SELECT ... FOR UPDATE lock to prevent race conditions:

$db->beginTransaction();
$stmt = $db->prepare('SELECT credits FROM users WHERE id = ? FOR UPDATE');
$stmt->execute([$userId]);
$credits = (int)$stmt->fetchColumn();

if ($credits < $cost) {
    $db->rollBack();
    return error('Insufficient credits');
}

$stmt = $db->prepare('UPDATE users SET credits = credits - ? WHERE id = ?');
$stmt->execute([$cost, $userId]);
$db->commit();

Important: release the lock before calling the external AI API. Don't hold database locks across network calls.

Security Checklist (Things I Almost Forgot)

A quick list for anyone shipping a similar product:

• ✅ Session cookies: HttpOnly, Secure, SameSite=Lax
• ✅ File upload validation: getimagesize() server-side, not just MIME
• ✅ Download proxy: whitelist allowed domains to prevent SSRF
• ✅ Rate limiting on contact forms (IP-based)
• ✅ XSS escaping on all user-generated content in the frontend
• ✅ SQL injection prevention: parameterized queries everywhere
• ✅ Feature whitelist: validate feature parameter against allowed values

What's Next

The product is live at 24picture.com. Currently focused on:

• Growing organic traffic through SEO and content
• Adding more specialized tools (AI Interior Design, AI Product Photo)
• Building a Chrome extension for right-click AI upscale

If you're building something similar, I hope this post saves you from the 4K thumbnail crash and the database lock pitfall. Happy to answer questions in the comments!

If you want to try it out, there are free credits on signup — no card required: 24picture.com