How I Built imagemochi: A Solo Dev's Journey

imagemochi started as a single HTML page with a JPEG compressor. I needed to compress a passport photo under 100KB for a visa application, couldn't find a tool that didn't upload my photo to a server, and figured: how hard could it be to build this in the browser?

Pretty hard, as it turns out. But also addictive.

The First Version (December 2024)

The first compressor was ugly. A plain HTML page with a file input, a quality slider, and a download button. It used the Canvas API to re-encode the image as JPEG at whatever quality you selected. Technically, it worked. Aesthetically, it looked like a homework project.

But it solved my problem. And when I shared it on a few forums, other people found it useful too. The "no upload" angle resonated. People were genuinely surprised that image processing could happen entirely in the browser.

The Expansion Phase (January-March 2025)

I started adding tools. Resize. Crop. Convert. Each one was a separate HTML page with its own JavaScript. The code was a mess — lots of copy-pasting between pages, no shared components, no consistent UI.

This is where I made my first big mistake: I didn't build a component system early enough. By the time I had 15 tools, every bug fix required editing 15 files. Every UI change was a nightmare.

The second mistake was worse: I didn't think about SEO from the start. I had great tools but nobody could find them because I hadn't put any thought into page titles, descriptions, or URL structure.

The Rebuild (April-May 2025)

I stopped adding features and rebuilt everything. Python generator scripts that produce all the HTML from templates. Shared CSS. Shared JavaScript modules. A consistent URL pattern. Proper meta tags.

This is the architecture that imagemochi still runs on. It's not a React app or a Next.js site. It's static HTML generated by Python scripts. Every tool page is a pre-built HTML file served directly by the web server. No JavaScript framework, no build step, no hydration.

Some people think this is old-fashioned. I think it's the right choice for this project. Static HTML loads instantly. It works without JavaScript (for the basic layout). It's trivially cacheable. And I can generate 550 pages in about 3 seconds.

The Technical Stack

Here's what powers imagemochi:

• Server: Python (FastAPI) serving static files. That's it. No database queries for tool pages.
• Image processing: Canvas API for basic operations, WebAssembly for JPEG (MozJPEG), WebP (libwebp), and HEIC (libheif) handling.
• Page generation: Python scripts that generate HTML from data dictionaries. One script per tool category.
• Styling: Vanilla CSS with custom properties for theming. No Tailwind, no Sass.
• JavaScript: Vanilla JS with a few shared modules. No React, no Vue, no bundler.
• Hosting: A single VPS. Nginx reverse proxy to FastAPI.

The total server cost is about $20/month. For a site that handles all image processing client-side, server requirements are minimal.

What Surprised Me About Users

I built imagemochi thinking people would come for the advanced tools — the fine-tuned compression controls, the batch processing, the format-specific options. Instead, the most popular interaction pattern is: drop file, click one button, done.

People don't want options. They want the right default with minimal decisions. The HEIC to JPG converter doesn't even have a quality slider on the main page. It converts at quality 92 and that's it. It's our most popular tool.

The users who do want control — photographers, designers, developers — are maybe 10% of the traffic. But they're the ones who come back regularly. The casual users come from Google, solve their one problem, and leave. The power users bookmark the site.

The Mistakes I'd Avoid Next Time

Build the component system first. Before a single tool page. Get the shared layout, shared JS modules, and generation pipeline working before building any actual tools.

Think about SEO on day one. I lost months of potential organic traffic by not having proper URLs, titles, and descriptions from the start.

Invest in batch processing early. It was an afterthought and it's now one of the most-requested features. Should have been there from version 1.

Don't build 550 pages. I could achieve the same SEO coverage with 50 well-optimized pages rather than 550 thin pages. Quality over quantity applies to SEO too — I'm slowly learning this.

Where It's Going

I'm still working on imagemochi. It's still a one-person project. I have a list of features longer than this blog post, and I ship updates a few times a week.

The core principle hasn't changed since day one: process everything in the browser, respect privacy, and make the interface so simple that you don't need instructions.

If you've made it this far, thanks for reading. And if you have feature requests, the contact page actually goes to my inbox — I read everything.