PixelMuse is a text-to-image generation platform I built around type-safe model calls, authentication, credits, and polished image workflows for real users. The architecture matters because AI image products fail quickly when generation APIs, payments, user state, and error handling are treated as separate afterthoughts.

Key facts

What problem was PixelMuse solving?

PixelMuse was designed as more than a prompt box. The product needed account state, model selection, credit accounting, a browsable gallery, and clear failure states because image generation can be slow, expensive, and inconsistent. That pushed the architecture toward explicit boundaries between UI, generation routes, payments, auth, and persistence.

Artist Gallery Pages

Generating 3d Objects .GBL files

Generated on PixelMuse using the Trelis AI model. This is first-party product evidence from the PixelMuse generation workflow.

How does the application architecture work?

Here's a high-level overview of how the different components interact:

How are image generation calls made type-safe?

The integration with Replicate's API is handled through a type-safe client generated from API metadata, then wrapped by application-level model configuration. Replicate exposes prediction and model prediction endpoints that map cleanly to this boundary.

/account
/collections
/collections/{collection_slug}
/deployments
/deployments/{deployment_owner}/{deployment_name}
/deployments/{deployment_owner}/{deployment_name}/predictions
/hardware
/models
/models/{model_owner}/{model_name}
/models/{model_owner}/{model_name}/predictions
/models/{model_owner}/{model_name}/versions
/models/{model_owner}/{model_name}/versions/{version_id}
/models/{model_owner}/{model_name}/versions/{version_id}/trainings
/predictions
/predictions/{prediction_id}
/predictions/{prediction_id}/cancel
/trainings
/trainings/{training_id}
/trainings/{training_id}/cancel
/webhooks/default/secret

Project Structure

The application follows a clean, modular structure:

src/
├── app/
│   ├── page.tsx                    # Home/generation page
│   ├── layout.tsx                  # Root layout
│   ├── pricing/
│   │   └── page.tsx               # Pricing page
│   └── api/
│       ├── auth/
│       │   └── webhook/route.ts   # Clerk webhook handler
│       ├── credits/
│       │   ├── check/route.ts     # Check credit balance
│       │   ├── consume/route.ts   # Consume credits
│       │   └── refresh/route.ts   # Refresh daily credits
│       ├── generate/
│       │   └── [model]/route.ts   # Image generation endpoints
│       └── payments/
│           └── webhook/route.ts   # Stripe webhook handler
├── components/
│   ├── ui/                        # shadcn/ui components
│   ├── layout/
│   │   ├── header.tsx            # Main nav with credits/auth
│   │   └── footer.tsx            # Site footer
│   ├── auth/
│   │   ├── auth-button.tsx       # Sign in/out button
│   │   └── user-profile.tsx      # User profile dropdown
│   ├── credits/
│   │   ├── credit-display.tsx    # Credit balance + buy button
│   │   └── credit-history.tsx    # Transaction history
│   ├── generation/
│   │   ├── prompt-form.tsx       # Text input + generate button
│   │   ├── model-select.tsx      # Model dropdown with Pro tags
│   │   └── result-display.tsx    # Generated image display
│   └── pricing/
│       ├── package-card.tsx      # Credit package display
│       └── pricing-grid.tsx      # Grid of packages
├── lib/
│   ├── db/
│   │   ├── schema.ts             # Drizzle schema
│   │   └── index.ts              # Database utilities
│   ├── replicate/
│   │   ├── client.ts             # Replicate API client
│   │   ├── models.ts             # Model configurations
│   │   └── types.ts              # Replicate API types
│   ├── auth/
│   │   └── clerk-utils.ts        # Clerk helpers
│   └── utils/
│       ├── error-handling.ts     # Error utilities
│       └── toast.ts              # Toast notifications
├── config/
│   ├── site.ts                   # Site configuration
│   ├── credits.ts                # Credit system config
│   └── models.ts                 # AI model config
└── styles/
    └── globals.css               # Global styles

The Foundation: Next.js 14 and TypeScript

I chose Next.js 14 as the foundation for PixelMuse, using the App Router, React Server Components, and server-side route handlers where they simplified the product boundary. The entire application is built with TypeScript, keeping type safety visible from database schema to API endpoints. Next.js documents the App Router as its file-system routing model for layouts, pages, and server/client composition.

Key architectural decisions included:

• Using pnpm for faster, more efficient package management
• Leveraging server components by default for optimal performance
• Strict TypeScript configuration throughout the codebase

Authentication and User Management

For user authentication, I integrated Clerk, which provides Next.js components, hooks, and server helpers for authentication. User records are synced into Supabase through a webhook so the product can connect identity to credits, generation history, and billing state.

Database and Type Safety

The database layer is built on Supabase with Drizzle ORM. Supabase provides the hosted Postgres database, while Drizzle keeps SQL access typed in application code.

• Type-safe database queries and schema management
• Real-time credit balance updates
• Efficient user data synchronization

Credit System Implementation

One of the core features is the credit system. Users can purchase credits in packages, and the system automatically deducts credits from their balance when an image is generated. I used Drizzle, Clerk, and Stripe to implement this.

Decision record: what I learned building PixelMuse

Treat the model as one dependency, not the product. The hard parts were around the model call: authentication, credit checks, idempotent payment state, webhook handling, image persistence, loading states, and recoverable errors.

Keep model configuration explicit. A product with multiple image and 3D generation models needs clear model metadata, supported inputs, cost assumptions, and UI affordances. Hiding that inside generic request handlers makes the product harder to price and debug.

Make billing observable from day one. Credits are revenue infrastructure, not just UI state. Stripe, Clerk, and the database need shared identifiers so revenue events can be traced back to a real user and generation workload.

Use type safety at boundaries. The highest-leverage typing was not complex generics. It was validating incoming webhook payloads, generation request bodies, model names, and database writes before they crossed system boundaries.

Source references for the platform choices: Next.js App Router, Clerk Next.js SDK, Replicate HTTP API, Supabase database docs, Drizzle ORM overview, and Stripe webhooks.

Looking Forward

Building PixelMuse has been an exciting journey in creating a type-safe, modern web application. The architecture decisions I made have resulted in a robust platform that's easy to maintain and extend.

Some key learnings:

• The importance of proper type definitions throughout the stack
• Value of proper error handling and user feedback

The platform continues to evolve, and I'm excited to add more features while maintaining the high standards of type safety and user experience that have been established.

MermaidEditor.io is a free Mermaid diagram editor I built to make text-based diagrams faster to write, debug, and export. The product matters because Mermaid is widely used in developer documentation, but GitHub's native Mermaid rendering gives limited feedback when syntax breaks.

Key facts

The editor solves this with live preview, inline error highlighting, 21 diagram types, theme presets, and export to PNG, SVG, and PDF — no login required. Mermaid itself is a text-based diagramming tool for documentation, and GitHub supports Mermaid diagrams directly in Markdown through fenced code blocks.

In its first full month (March 2026), MermaidEditor hit 2,922 monthly active users, 25,361 pageviews, and 1,166 diagram exports. But the most surprising metric was where the traffic came from: 25% of all visits were referred by ChatGPT.

This post covers the technical architecture, the hardest engineering problem I solved (the export pipeline), how I integrated AI features, the monetization experiments I ran, and what I learned about building for AI-driven discovery.

Why does Mermaid syntax fail silently in GitHub workflows?

If you've ever written a Mermaid diagram in a GitHub README, you know the pain. You push a commit, navigate to the rendered Markdown, and see... a gray box. No error message. No line number. No hint at what went wrong.

flowchart TD
    A[Write Mermaid in README] --> B{Push to GitHub}
    B --> C[See blank gray box]
    C --> D[No error message]
    D --> E[Guess what's wrong]
    E --> A

Every Mermaid user has this workflow burned into muscle memory. The edit-commit-check loop is brutal when you're debugging syntax. I wanted a tool where you paste your code and immediately see what's wrong — with the actual error underlined, not hidden behind a silent render failure.

How is MermaidEditor.io architected?

The stack is intentionally modern but pragmatic:

• Framework: Next.js 16 (App Router) with React 19 and TypeScript
• Editor: Monaco Editor with custom Mermaid language support via monaco-mermaid
• Rendering: Mermaid.js 11.x running client-side in the browser
• Styling: Tailwind CSS 4 with shadcn/ui components
• Export: Canvas API (PNG), native SVG serialization, jsPDF (PDF)
• AI: Vercel AI SDK with Anthropic Claude and Google Gemini providers
• Database: Turso (libSQL) via Drizzle ORM for cloud diagram storage
• Auth: Clerk for optional user accounts
• Payments: Stripe for Pro subscriptions
• Analytics: PostHog (server + client) and Vercel Analytics
• Deployment: Vercel with automatic preview deployments

The key architectural decision was making the editor fully functional without authentication. Users can open the site and start diagramming immediately — no signup wall, no "create an account to save" interstitial. Diagrams auto-save to local storage. Accounts are optional and unlock cloud sync.

This stack list is first-party implementation evidence from the MermaidEditor codebase and production deployment. Public source references for the core platform choices include Mermaid's project documentation, GitHub's Mermaid Markdown support, PostHog product analytics, and Vercel deployments.

Why is Mermaid export harder than preview?

Exporting a Mermaid diagram to a high-quality PNG, SVG, or PDF sounds straightforward. It isn't.

The core challenge is converting a Mermaid-rendered SVG into a raster image. The pipeline is: SVG → <img> element → <canvas> → file download. The critical step is loading the SVG string into an <img> tag so it can be drawn onto a canvas.

The Approach That Won: Percent-Encoded Data URLs

After testing multiple strategies, I settled on percent-encoded data URLs:

const dataUrl = `data:image/svg+xml;charset=utf-8,${encodeURIComponent(svgString)}`

This handles all Unicode characters (emoji, CJK, mathematical symbols), always fires onload/onerror callbacks, and has no practical size limits. Two other approaches were tested and rejected:

Base64 data URLs failed on non-Latin1 characters — btoa() throws on emoji and CJK text, which is common in diagrams. They also hit browser URL length limits (~2MB) on large diagrams.

Blob URLs (URL.createObjectURL) were worse: they can silently fail in Chrome and Safari. Neither onload nor onerror fires, leaving the export Promise hanging forever. The canvas also gets tainted due to CORS origin mismatch, making toDataURL() throw.

htmlLabels: The Subtle Killer

One of the trickiest bugs was that Mermaid renders node labels as <foreignObject> HTML by default (the htmlLabels: true setting). This looks great in the browser DOM but is invisible when the SVG is loaded into an <img> element — <foreignObject> content doesn't render in that context.

The fix: force htmlLabels: false during export, which tells Mermaid to use native SVG <text> elements instead. The preview still uses HTML labels for better styling, but exports get pure SVG text.

Export Safeguards

Every export includes a 30-second timeout on image loading, error tracking via PostHog (export_failed events with format, diagram type, and error details), and retry logic for transient failures.

The entire export pipeline is covered by Playwright tests that run against a real browser:

• PNG, SVG, and PDF export for 4 diagram sizes
• File validity checks (PNG pixel analysis, SVG structure, PDF header)
• Blankness detection — catching the "export succeeded but produced a white image" failure mode
• Console error monitoring

pnpm test:exports  # runs on every PR touching export code

Why did AI repair matter more than AI generation?

I integrated AI in two ways: AI Generate (create a diagram from a natural language prompt) and AI Repair (fix syntax errors in existing code).

The surprising finding from production data: AI Repair is used 5.7x more than AI Generate. In March, users triggered 362 repair requests vs. 63 generation requests. The completion rate for repair was 74%, while generation hit 98%.

Those usage numbers are first-party PostHog event evidence from the MermaidEditor production analytics dashboard.

This makes intuitive sense once you think about it. Most users arrive with existing Mermaid code that's broken — they pasted it from a ChatGPT response, copied it from documentation, or tweaked syntax that was working before. They don't need AI to create a diagram from scratch; they need AI to tell them why their bracket is in the wrong place.

The AI features use Vercel AI SDK with streaming responses. Repair sends the broken Mermaid code plus the exact error message to Claude, which returns corrected code with an explanation. It's essentially a specialized debugger.

March 2026 AI Usage:
├── AI Repair:    362 requests (74.3% completion)
├── AI Fix All:   133 requests (56.4% completion)
└── AI Generate:   63 requests (98.4% completion)

First Month Metrics

Here's what the PostHog dashboard showed after the first full month of operation:

User Growth

Feature Usage

Export Format Breakdown

PNG leads at 48%, followed closely by PDF at 43% — which surprised me. I expected PNG to dominate. The high PDF share suggests a significant portion of users are exporting diagrams for documentation, reports, and presentations rather than embedding in web content.

Conversion Funnel

• Editor Loaded: 2,268 users
• Export Completed: 126 users (5.56% conversion)
• Median Time to Export: 1 min 36 sec
• Average Time to Export: 14 min 2 sec

The bifurcation between median and average tells an interesting story. Half the users know exactly what they need — paste code, export, done in 90 seconds. The other half spends significant time crafting and iterating on their diagrams.

The ChatGPT Traffic Story

The most remarkable finding was the traffic source breakdown:

A quarter of all traffic came from ChatGPT. When you combine all AI sources (ChatGPT, Perplexity, Gemini, Claude), AI chatbots account for roughly 26% of referrals.

This wasn't accidental. I invested in what's now called GEO (Generative Engine Optimization) from day one:

1. llms.txt — A structured text file at /llms.txt that tells AI crawlers exactly what the tool does, what diagram types it supports, and how to use it
2. robots.txt allows all AI crawlers — No blocking of GPTBot, ClaudeBot, or other AI user agents
3. SEO landing pages per diagram type — 21 pages targeting queries like "mermaid flowchart editor", "mermaid sequence diagram online", each with examples and syntax guides
4. Fact-dense, structured content — Instead of marketing prose, the landing pages use concrete claims: "21 diagram types", "PNG/SVG/PDF export", "no login required"

The theory is that LLMs extract and recommend tools based on structured, authoritative content. When someone asks ChatGPT "how do I make a Mermaid flowchart", it recommends tools it has seen described clearly and specifically. Marketing fluff doesn't help — concrete capabilities do.

I wrote about this approach more broadly in the context of GEO optimization for personal sites.

Monetization: A/B Testing the Upgrade Path

MermaidEditor uses a freemium model: the core editor is free forever, and Pro ($7/month or $39 lifetime) removes watermarks, unlocks high-resolution exports (up to 8x / 768 DPI), and adds 200 AI generations per month.

The conversion challenge with developer tools is that the free tier has to be genuinely useful — otherwise nobody sticks around to convert. I ran several A/B tests on the upgrade flow:

Post-Export Modal Variants

The post-export modal appears after every free export with the watermark visible on the diagram. I tested two layouts:

• Split Panel (Default): Shows the exported diagram preview alongside the upgrade pitch. Users can see their watermarked diagram and the value prop side by side.
• Receipt Variant: Treats the export like a receipt — shows format, resolution, watermark status, and a clear comparison of free vs. Pro capabilities.

Upgrade Modal Layouts

I tested three distinct upgrade modal designs:

• Compact Single Card: Focused on a single decision — pick monthly or annual, then checkout. Minimal friction, best for impulse conversions.
• Side-by-Side Comparison: Shows Free vs. Pro feature-by-feature. More information helps justify the price but can feel heavy as a modal.
• Contextual Upgrade Prompt: Tells the user why they're seeing this (e.g., "Watermark-free exports require Pro"). Changes message based on the trigger context.

Export Upgrade Banner Variants

The export toolbar banner is the most visible upgrade surface — it appears every time a free user exports. Three copy strategies:

• Control (Premium Positioning): "Remove watermark & unlock print DPI" — neutral, feature-focused
• Urgency (Problem-Aware): "This export includes a watermark" — calls out the problem directly
• Benefit-Focused: "Export crisp PNGs at up to 8x resolution" — leads with the outcome

Navigation Layout Testing

I also tested where and how the Pro upgrade button appears in navigation — right side vs. left side, with vs. without the Learn/More dropdowns, and gradient button vs. standard styling. The hypothesis was that moving Pro into the left navigation (near the diagram type selector) would catch users earlier in their workflow.

Early Results

March numbers showed strong experiment exposure but modest conversion:

• Watermark impressions: 813
• Upgrade modal views: 60
• Post-export modal views: 280
• First paying subscriber: 1

One paying customer in month one is a validation signal, not a revenue story. The experiments are still gathering data, and the conversion path needs work — but the product-market signal is clear from the usage metrics.

Global Reach from Day One

The geographic distribution was surprisingly broad:

The US was the top country at 16% of traffic, followed by Brazil (11%), India (7%), Germany (6%), and France (6%). Over 25 countries had significant traffic. Edge browser accounted for 24% of sessions — unusually high and suggestive of enterprise/business users who are diagramming for work.

This distribution aligns with the GEO hypothesis: AI chatbots recommend tools globally without geographic bias. When ChatGPT tells a developer in São Paulo to "try mermaideditor.io", it has the same recommendation weight as for a developer in San Francisco.

Decision record: what I would build the same way again

Monaco Editor over CodeMirror. Monaco's built-in TypeScript tooling, minimap, and multi-cursor support make it feel like VS Code in the browser. The monaco-mermaid package adds syntax highlighting and autocompletion for Mermaid syntax. The editor experience is one of the biggest differentiators.

Client-side rendering for diagrams. Mermaid.js runs entirely in the browser. No server-side rendering, no headless Chrome, no API calls. This keeps latency at zero for preview updates and eliminates server costs for the core editing experience.

PostHog over Mixpanel/Amplitude for analytics. Self-hostable, generous free tier, session replays, feature flags, and the A/B testing framework all in one platform. Being able to watch session recordings of users struggling with the export flow directly informed the UI improvements.

Stripe for payments with a lifetime deal option ($39 one-time). Lifetime deals are controversial in SaaS, but for a tool with near-zero marginal cost per user, they're a strong acquisition lever early on. One-time payments have lower friction than subscriptions for developer tools.

What's Next

The immediate roadmap is focused on the conversion funnel — the product has strong engagement (18,743 chart saves, 3-10 minute sessions) but the editor-to-paying-customer path needs optimization. The A/B tests are still in early innings.

On the product side: team workspaces, version history, and a REST API for programmatic diagram generation are the most-requested features. The AI repair feature has the most growth potential — it's already the most-used AI feature and directly solves a real pain point.

The GEO strategy will continue to be a focus. When 25% of your traffic comes from AI chatbots, optimizing for AI discoverability is just as important as traditional SEO.

MermaidEditor.io is free at mermaideditor.io. The source code is private, but I'm happy to discuss the architecture — reach out on X.

This article explains how I moved from curiosity about radio engineering into real Helium IoT antenna deployments across Arizona. It matters because Helium rewards are not just a crypto mechanic; they expose practical RF trade-offs around height, terrain, antenna pattern, weatherproofing, and measurable wireless coverage.

Key facts

How did I get interested in antennas?

At the time I began exploring antennas and radio engineering for crypto mining, I was in a period of studying meditation. I was watching all the YouTube content I could find from yogis, saddhus, and Buddhist monks to learn about the world of meditation. I was deeply interested and spent all my free time diving in or practicing myself. At the time I was also building a meditation and yoga brand called Zafu, so I was encompassed in meditation from entertainment, to work, to practicing. I then noticed that a lot of renunciant Hindu monks, who spend much of their lives meditating, give away all of their belongings, yet they kept a picture of their guru as one of their few prized possessions. I found this intriguing. It made me think: what should the focus of my meditation be? What do I want to understand more deeply?

At the time, I chose Nikola Tesla. Not to worship, but to focus my study and growth of understanding on. I chose Tesla because similar to the transcendent nature of powerful yogis and meditators, Tesla seemingly broke the paradigm of what we thought was possible scientifically. I printed out a photo of Nikola Tesla and meditated with it. Upon exploring Tesla's work, I became more fascinated with electromagnetics, energy, and physics. I purchased a small tabletop antenna and placed it next to Tesla. This eventually primed my brain to jump into Helium when I learned that a cryptocurrency network was using radio coverage as part of its economic design.

I purchased a Helium miner. On the first few days I set it up in 2021, it was earning a notable amount of USD with the stock antenna. I decided I needed to upgrade my antenna to improve my earnings. So I searched for a radio shop and drove to one of the locations that showed up on Google. I was expecting a Radio Shack; what I found was a CB radio shop for a semi-truck stop deep in the valley of Phoenix, Arizona. I walked in and said I was looking for an antenna for my crypto miner.

In 2021, I wasn't expecting much of a response to this out-of-the-ordinary request. The shop owner was a curious engineer and found it fascinating. He offered to let me set the miner up on his roof, explaining that antenna height was one of the key variables for maximizing signal distance. This became the first of 50+ sessions I spent working with the owner of the CB shop to brainstorm, design, install, manage, upgrade, and fix Helium antennas.

The Helium Network: Decentralized IoT Infrastructure

The Helium Network is a collection of decentralized wireless networks, including IoT and mobile coverage. For IoT, Helium documents a LoRaWAN-based network where hotspot operators provide wireless coverage for devices. By deploying strategically placed antennas, hotspot operators can earn rewards through:

• Proof of Coverage: Demonstrating wireless coverage to nearby hotspots
• Data Credits: Routing IoT device data through the network
• Network participation: Keeping deployed coverage online and useful

Blockchain activity and Helium tooling exposed quantitative feedback about signal strength, witness relationships, and coverage across different connections, which made it possible to measure radio engineering progress instead of guessing.

What antenna configuration worked in Arizona?

Protecting sensitive electronics required custom weatherproof enclosures:

• NEMA-rated enclosures: IP65+ protection against dust and moisture
• Thermal management: thermal paint and passive cooling for Arizona's extreme heat
• Hardware: Custom Built Antennas, Coax Cable, Splitters, Amplifiers, Tower, etc.

We analyzed various antenna configurations to optimize signal propagation across Arizona's diverse terrain. The key factors we considered:

Site Survey and Planning

Each antenna deployment began with comprehensive site surveys:

0. Azimuth and Elevation optimization: Ensuring optimal coverage and witness distances
1. RF propagation modeling: Using terrain data and propagation software
2. Existing hotspot analysis: Identifying practical witness distances from first-party deployment data
3. Interference assessment: Measuring background RF noise levels
4. Line-of-sight verification: Ensuring clear paths to target areas
5. Hardware Quality: Coax cable, antenna, and other hardware efficiency and reliability

Frequency Characteristics

Helium IoT uses LoRaWAN regional frequency plans; in the United States, deployments use the US915 region. That made antenna tuning and cable quality central to the build. We tested multiple antenna types:

• Omnidirectional antennas: 360-degree coverage for urban deployments
• Directional Yagi antennas: Focused beam for long-distance links
• Collinear arrays: Enhanced gain while maintaining omnidirectional pattern

Antenna Gain and Pattern Analysis

Higher gain antennas concentrate RF energy, extending range but reducing vertical coverage. We measured the trade-offs:

Low Gain (3 dBi):  Wider vertical pattern, shorter range
Medium Gain (6 dBi): Balanced coverage for suburban areas
High Gain (9+ dBi): Long-range links, narrow vertical pattern

What I learned from field deployments

Height beat most desk theories. Moving an antenna from an indoor shelf to a roof changed the link budget more than many component swaps. The lesson was not "always buy more gain"; it was "improve the RF path first."

Cable and enclosure work were product work. A high-gain antenna did not matter if the cable run was lossy, the enclosure overheated, or water intrusion took the hotspot offline.

Helium made RF measurable enough to iterate. Witness data, coverage changes, and reward behavior gave us feedback loops. The numbers were noisy, but they were better than installing hardware and hoping.

Local terrain mattered. Arizona rooftops, heat, UV exposure, and open desert paths created different constraints than a generic indoor hotspot guide. The useful decisions came from repeated field work, not one static parts list.

Installation Challenges and Solutions

Rooftop Deployments

Rooftop installations presented unique challenges in Arizona's extreme weather conditions:

• Wind loading: Securing antennas against monsoon winds up to 70+ mph
• Temperature cycling: Managing expansion/contraction from 20°F to 120°F+ swings
• UV degradation: Selecting materials resistant to intense desert sun
• Lightning protection: Implementing proper grounding systems