# How I Accidentally Started Building Imejis.io: The Header Builder Story Summary: Header Builder was a small Twitter header scheduler that never took off. That failure is how I accidentally started building Imejis.io on my own. Canonical: https://www.dharmikjagodana.com/blogs/how-i-accidentally-started-building-imejisio-the-indie-hacker-story Updated: 2026-10-22 Author: Dharmik Jagodana Tags: [#Products](https://www.dharmikjagodana.com/blogs/tags/products.md), [#Indie Hacking](https://www.dharmikjagodana.com/blogs/tags/indie-hacking.md) Every product has an origin story. Imejis.io didn’t start with “I want to build a design tool” or “Let’s build a SaaS.” It started with something much smaller… A quirky little idea called **Header Builder**. ## **The Tool That Never Took Off: Header Builder** A year ago, I built a tiny tool for fun — a **Twitter header scheduler**. You could upload a header image, pick a time, and it would automatically update your Twitter profile. The tool was simple. Too simple. People wanted _more_ than just uploading and scheduling. They wanted something dynamic. And so did I. I kept thinking: > “What if the header could change based on real data?” Ideas started coming fast: - Show **latest 3 followers** on your header in real-time - Display your **book’s live sales count** on your header - Auto-generate a **daily inspirational quote banner** - Update a **progress bar** for goals every hour - Show **newsletter subscriber growth** It wasn’t just a header anymore. It needed to be _dynamic images generated from an API_. That tiny idea changed everything. * * * ## **The Realization: I Needed a Design Engine** While trying to build these dynamic headers, I hit a wall. There was no lightweight tool that: - let me visually design the template - supported dynamic variables - generated images via API - was simple, fast, and automation-friendly Everything out there was too heavy, too slow, or too restrictive. So I said: **“Fine, I’ll build it myself.”** And that’s where Imejis.io began. * * * ## **Starting Imejis.io: One Feature at a Time** Imejis.io didn’t come from a sprint or a hackathon. It came from necessity. I needed: - a simple editor - a way to add text, images, shapes - an API to replace variables - an export engine - a stable UI - predictable templates - something fast enough to run automation on So I built the first version. Then rebuilt it. Then fixed it. Then rebuilt again. (The indie hacker loop.) * * * ## **The Slow Grind: 6 Months of Scattered Building** This wasn’t a full-time project. Far from it. For 6 months, I was juggling: - client projects - other product experiments - part-time consulting - inconsistent schedule - exhausting days - late-night coding sessions - debugging on weekends - context switching nonstop Progress was slow. Some weeks I shipped nothing. Some weeks I built an entire feature in two nights. But I kept going — one commit at a time. That’s the reality of indie hacking: **No rush, no deadlines, just steady progress whenever life allows.** * * * ## **When It Finally Started Coming Together** Slowly, the core building blocks appeared: - The editor started feeling fast - Templates became predictable - Shapes, text, and layers behaved correctly - The API started generating images reliably - Public pages made sharing easier - Zapier automations finally worked - Users tested it and gave feedback - The tool felt “real” for the first time That’s when I realized: I wasn’t building a header tool anymore. I was building a **design automation platform**. * * * ## **Looking Back at the Unexpected Journey** It’s funny to think about it now: I didn’t plan to create a design SaaS. I didn’t plan to enter the “image generation” space. I didn’t even plan to build a full editor. I just wanted a way to dynamically update a Twitter header. That tiny idea became a prototype. The prototype became a tool. The tool became a platform. And the platform became Imejis.io. That’s indie hacking — small ideas becoming big projects without you noticing. * * * ## **And I’m Still Building…** Imejis.io is still evolving. Still scrappy. Still improving. Still very much an indie hacker product. But now it’s something people actually use: - to create images faster - to power automations - to run daily workflows - to share editable templates - to generate content at scale And the journey continues. * * * Part 2, on how I built the editor, is coming next. New posts show up on X. [Follow new posts on X](https://x.com/dharmikjagodana) [All posts](https://www.dharmikjagodana.com/blogs.md) ## Related - [I Rebuilt My Editor from Scratch: Fabric.js vs HTML Drag & Drop](https://www.dharmikjagodana.com/blogs/why-i-rebuilt-my-editor-migrating-from-fabricjs-to-an-html-drag-and-drop-builder.md): I rebuilt my entire design editor, migrating from Fabric.js to an HTML drag-and-drop builder. Here’s why Fabric.js hit its limits and what I learned. - [I Was Paying for Servers Nobody Used. So I Moved to Cloudflare.](https://www.dharmikjagodana.com/blogs/cloud-run-vs-cloudflare-workers-cost.md): Cloud Run vs Cloudflare Workers for a small SaaS: a warm instance, a BullMQ worker and Redis add up to about $48 a month idle. Workers Paid starts at $5. - [The Commands I Never Let an AI Agent Run (and How I Sandboxed OpenClaw)](https://www.dharmikjagodana.com/blogs/ai-agent-commands-never-run-openclaw-sandbox.md): An AI agent security checklist for commands I never let an agent run alone: deletes, force pushes, secrets, and anything on the production database.