DEV Community: Dharmendra Jagodana

I made this cover image with one URL. Here's everything Imejis.io can do

Dharmendra Jagodana — Fri, 23 Oct 2026 09:19:02 +0000

The cover image on this post was not made in Figma.

It's an Imejis.io design: a few layers, with some of them marked dynamic. If I change the JSON, I get a different image. Same design, two API calls:

The headline, subtitle, KPI, star rating, and bar chart all changed. I didn't open an editor.

That's the idea behind Imejis: you design an image once, and it becomes an API. Below is everything it can do.

🧠 The core idea: dynamic fields

Every layer in a design has a key, like headline, avatar, or price. Set dynamic: true on a layer, and you can override any of its fields at render time with dot-paths:

headline.text      → "Hello DEV 👋"
headline.color     → "#ff0055"
avatar.image       → "https://…/me.png"
revenue.value      → 92400
weekly_chart.data  → [12, 19, 15, 27]

The rule to remember: you always target a field, never the bare layer. ?headline=Hi does nothing. ?headline.text=Hi works. Imejis returns a warnings array when you get this wrong, so the mistake doesn't go unnoticed.

⚡ Rendering: GET or POST

GET is good for <img> tags, emails, and anywhere else that only accepts a URL:

<img src="https://YOUR_RENDER_URL?headline.text=Hello%20DEV&format=webp" />

POST is better for long text, many fields, or values you don't want showing up in logs:

curl -X POST "$IMEJIS_RENDER_URL?format=png" \
  -H "dma-api-key: $IMEJIS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "headline":     { "text": "Your weekly report, {{rendered live}}" },
    "revenue.value": 92400,
    "revenue.delta": -4,
    "weekly_chart.data": [48, 44, 39, 41, 36, 33, 30]
  }' \
  --output report.png

Nested ({ "headline": { "text": … } }) and dot-path ("headline.text") forms do the same thing. Your API key can go in a header, a query param, or the POST body.

Four output formats

Format	Use it for
`png`	Lossless, transparency
`jpeg`	Smallest photos, `?quality=1-100`
`webp`	Modern web, transparency, tiny files
`pdf`	Vector pages for print, certificates, invoices

Three delivery modes

Bytes (the default): the image comes back in the response.
?delivery=hosted: you get a permanent public URL, which suits Slack blocks, webhooks, and CMSs.
?delivery=signed&expiresIn=60: you get a private link that expires, up to 7 days.

🧩 27 components (it does far more than text on a rectangle)

This is the part that surprised me most. On top of the basics, Imejis renders real data visualizations into images.

Basics: text · image · rect · circle · line · shape (any SVG path)

Codes: qr (URLs, coupons, Wi-Fi) · barcode (Code 128, EAN-13, UPC-A, ITF-14, GS1-128, and more)

Scores and KPIs: rating (stars, hearts, or a custom emoji, with half fills) · progress (bar, ring, or gauge) · metric (a KPI tile with an up/down delta and a sparkline)

Charts: chart (bar, line, area, waterfall, lollipop, step, slope, and combo with a second axis) · pie/donut · waffle · funnel · bullet · dumbbell · radar · scatter (with a trend line) · candlestick (OHLC) · treemap (market heatmap) · calendar (GitHub-style contribution grid) · sankey · chord · gantt · table

Maps: map, which draws choropleth or bubble maps of the world, US states, or provinces and states of Canada, Germany, Australia, Brazil, and India. You key the data by ISO code:

{ "sales_map.data": [{ "id": "US", "value": 420 }, { "id": "IN", "value": 310 }] }

Each of these is dynamic. Push new .data with each render, and a daily dashboard screenshot becomes a single API call.

✍️ Typography goes deep

500+ fonts built in, and you can upload your own.
autoResize with min and max font sizes, so long titles don't overflow.
Inline patterns: write Save {{40%}} today and only the {{…}} part gets its own color, pill background, or size.
Gradient text fills, stacked outlines in the "sticker" style, text shadows.
Curved text on an arched baseline, which is great for personalized book covers.
RTL support, letter spacing, text transforms, and highlight backgrounds.

📐 One design, every size

A design can carry variations: a 1080×1080 master, plus a 1080×1920 Story, a 1200×630 OG image, a 1280×720 YouTube thumbnail, and so on.

Variations are linked to the master. Each size stores only what's different at that size, and when you add a size, Imejis automatically reflows the layout onto it. Then you render the size you want:

?variation=instagram-story
?variation=og-image

The dynamic data is shared across sizes, so one payload fills a whole social media kit.

📦 Bulk export and carousels

You can render up to 25 images in one call, and each one comes back as a stored URL:

the same design in every size
the same design with 25 different data rows (personalized cards, A/B copy)
several different designs together
a carousel, because the results keep their order and the array is the slide sequence. Make each item a PDF and you get a PDF carousel.

If one item fails, the others still render, and you're only billed for the successful ones.

🕰️ Versioning that protects what's public

This is where Imejis acts like a developer tool and not a design toy:

Every publish creates a numbered, labeled version, and you can roll back to any of them.
Share links (a public page, no account needed) and templates are pinned to a specific version. Editing the design doesn't change what the public sees until you sync.
If a bad edit went live, you can point the public page at an older version immediately and fix the design afterwards.

🎨 Templates and gallery

The public gallery has 200+ templates: LinkedIn carousels, quote cards, wellness slides, business covers, and more.
You can turn any of your designs into a workspace template so your team starts from on-brand layouts.
You can submit a template to the public gallery, where an admin reviews it.

🤖 It works with AI agents too

Imejis has an MCP server, so assistants like Claude can create, edit, preview, and export designs directly. The cover of this post was made that way: the agent read the component guide, built the layers, previewed the result, and exported all three variants above in one bulk call.

💡 What I'd build with it

Auto OG images for every blog post, generated at build time from the frontmatter
Certificates with the name, course, date, and a QR code, exported as vector PDFs
Weekly KPI cards posted to Slack with real charts
E-commerce banners with the price, rating, and barcode
GitHub-style streak cards with the calendar component
Event tickets with a seat number and a scannable code
Localized ads: one design, with the copy swapped for each language

A quick OG image in Node

// build-og.js
const res = await fetch(`${process.env.IMEJIS_RENDER_URL}?format=png&delivery=hosted`, {
  method: "POST",
  headers: {
    "dma-api-key": process.env.IMEJIS_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "title.text": post.title,
    "author.text": post.author,
    "avatar.image": post.authorAvatar,
  }),
});
const { url } = await res.json();
// drop `url` into <meta property="og:image">

🧾 TL;DR


🖼️ Design once	Visual editor plus 200+ templates
🔌 Render anywhere	GET/POST, one URL per image
📊 Real data	27 components, including charts, maps, QR codes, and barcodes
📐 Every size	Linked variations with auto-reflow
📦 At scale	25 images per bulk call, ordered carousels
🔒 Safe to ship	Versions, rollback, pinned share links
🤖 Agent-ready	MCP server for AI assistants

If you've ever opened Figma just to change one line of text on an image, try imejis.io.

What would you automate first? Let me know in the comments 👇

I rebuilt the same SaaS backend five times. So I turned it into one SDK.

Dharmendra Jagodana — Thu, 09 Jul 2026 14:20:32 +0000

I build SaaS products with my brother. After shipping five of them, I realized I'd rebuilt the exact same backend (auth, Stripe, multi-tenancy, workflows, email, webhooks) five separate times. So I extracted it into one SDK for React/Next.js. It now runs all five products in production. This is the honest version, including what it still can't do.

The fifth time I sat down to write sign-up and login, I stopped.

It wasn't hard. That was the problem. I'd done it four times already, and I could see the next three weeks laid out in front of me like a checklist I'd memorized: auth, then Stripe, then workspaces, then roles and permissions, then usage limits, then transactional emails, then webhooks. Weeks of plumbing before I could touch the one feature that was the actual reason I started the project.

I build software with my brother. Five of our products are live right now:

Imejis - a template-based image-generation API
AgentCenter - mission control for AI agents
PlugNode - a visual AI workflow builder
RemoteWait - a virtual queue system
LinkTracer - creator analytics

Five completely different products. Every single one needed the exact same backend before it could do anything interesting.

The backend tax

There's a tax you pay on every SaaS product before you write a single line of the thing that makes it special.

Users, so you build auth - and not just email/password, but social login, magic links, sessions, resets. Revenue, so you wire up Stripe, including a whole metering layer if you're doing anything usage-based. Teams, so you build workspaces, roles, invitations. Then email. Then feature flags. Then webhooks.

None of it is novel. All of it is necessary. And all of it stands between you and the actual idea.

The first time, it's fun, you're learning. By the third time, you're copy-pasting from your last repo and quietly resenting it. By the fifth, you're maintaining five slightly different versions of the same bugs.

The first rebuild feels like progress. The fifth one feels like a warning.

From copy-paste to a platform

After the third product, I stopped copy-pasting and started extracting - pulling the shared pieces into their own package with a hard boundary between what was truly generic and what was product-specific.

After the fourth, the package had opinions. It knew how billing should attach to a workspace. It knew each org should get its own physically isolated database. It had a workflow engine, because I was tired of gluing cron jobs and automation tools together just to send a welcome sequence.

After the fifth, it wasn't a package anymore. It was a platform, running all five products in production every day.

That's BuildBase.

What it is

The whole SaaS backend for React and Next.js, in one SDK.

npm install @buildbase/sdk

Not just auth. Nineteen integrated modules that actually talk to each other, because they were built together for real products rather than stitched together from a marketplace of disconnected services:

Auth - email/password, magic link, passkeys (WebAuthn), Google, GitHub, Microsoft, LinkedIn, plus a full OAuth 2.0 authorization server so your app can become an identity provider
Billing - Stripe with your own account, usage-based metering, quota enforcement, credits, seats, multi-currency
Multi-tenancy - an isolated workspace and isolated database per org, with RBAC
Workflows - a real event-driven engine (triggers, actions, conditions), queue-backed
Communication - email through your own sender (SMTP, Google, Microsoft, Mailgun) plus event-driven Slack alerts
Growth - feature flags, audience/CRM, short links, webhooks, analytics
Global - i18n across 8 locales and 22 currencies
Headless - an API layer, so you can use any of it without our UI

The point isn't the length of the list. It's that these pieces work as one system. Billing knows about your workspaces. Workflows can read your audience. Feature flags can target a plan. That coherence is the part you can't copy-paste from five different vendors.

How it actually runs

Under the hood it's MongoDB + Redis + Docker. The defining architectural choice is a physically isolated database per organization - not a shared table with a tenant_id column, but real per-org isolation. That's the single biggest cost driver, which is also why the pricing is per-app rather than per-seat (more on that below).

Being honest about the tradeoff: per-org isolation is great for data separation and terrible if you pretend it scales infinitely. It doesn't yet. There's a known connection-pool ceiling I'm not going to hand-wave past, so I'm not making big scale claims.

The three decisions I care most about

A feature list tells you what a product does. These tell you what it believes.

1. Bring your own Stripe, and I take 0% of it. Your customers pay you, directly, into your own Stripe account. I never sit in the middle of your revenue. The norm in this space is that your bill climbs as you grow. I built the opposite on purpose, because I've been the founder watching that line item climb.

2. You own your data, three ways to run it. Shared (isolated DB per app on our infra), Dedicated (dedicated infra per app), or Self-hosted (run our Docker images on your own servers with your own MongoDB and Redis). No lock-in by design.

3. Per-app pricing. One app = one org = one isolated database. You pay for what you actually run, not per-seat and not per-MAU. Three plans: Launch, Grow, Scale.

Let me be straight about where it stands

This is the part I'd want to read first, so here it is.

React and Next.js only, today. No Vue, Svelte, or native mobile SDK yet.

Not open source. I know this matters most to this crowd, so I'm not going to bury it. Self-hosting means running our compiled Docker images on your own infrastructure - you don't get the source code. What you get instead is no vendor lock-in: your infra, your database, your Stripe. I'm not going to dress up "self-hostable" as "open source," because it isn't, and you'd catch it in five minutes anyway.

Early and bootstrapped. It's me and my brother. The SDK is young (0.x). But it isn't a landing page with a waitlist - five real products depend on it in production every day. When something breaks, it breaks for me first.

Who it's for

Solo founders, indie hackers, and small teams building SaaS on React or Next.js who are sick of wiring the same backend together for the tenth time and want those weeks back for the product that actually matters.

Try it, or tear it apart

Website: https://www.buildbase.app
Live demo: https://demo.buildbase.app/
Docs: https://docs.buildbase.app/introduction
Self-host starter: https://github.com/buildbase-app/self-hosted-starter

The feedback I most want, especially from this audience: what would make you trust a backend SDK enough to build your next SaaS on it? And what's the one thing missing for your stack?

Reach me anytime at dharmendra@buildbase.app.

I built this because I got tired of paying the backend tax. If it saves you even one of those rebuilds, it did its job.