100PrintsWithMe

When I started building 100PrintsWithMe, I copied the architecture almost everyone uses for document generation.

Your app sends data to an API ---> the server renders the document ---> returns a PDF or PNG ---> you pay per render.

I even had pricing ideas for API credits before I had enough users to worry about API traffic. 😅

Then one night I stopped and asked myself:

Why am I rendering this on my server at all?

Most of the time, developers aren't generating thousands of documents at once.

They're just trying to add document generation to their own app.

A course platform wants students to download certificates.

An event website needs badges.

A membership portal needs ID cards like these Reasons .

The browser is already running the application, so why send all that data to another server just to render an image?

So I built a Browser SDK instead.

Developers design the template visually, install one npm package , pass your application data in to SDK, and render the document directly in the user's browser.

That means:

• No upload to my rendering server

• Sensitive user data stays on the user's device

• No browser-rendering API credits

• Just render and let the user download

I still kept the REST API because server-side rendering absolutely makes sense for scheduled jobs and large-scale automation.

I just don't think it should be the only option.

I'm building this solo, so most of these architecture decisions come from arguing with myself at 1 AM. 😂

I'm curious what other developers think.

If you needed to add certificates, badges, ID cards, tickets, or other printable documents to your web app...

Would you rather install a Browser SDK, or just send everything to an API?

I'd genuinely love to hear the trade-offs you see.
Github Repo of the sdk (Controcode/100printswithme-browser-sdk: browser-sdk )

Okay, so this one needs a bit of backstory.

Me and a few friends were trying to build an event management platform for our college fest. You know how it goes — registrations on Google Forms, payments via some random QR code, updates on a WhatsApp group that nobody mutes, and certificates that somehow always end up being printed the night before at 2am.

We thought we'd fix all of that. Classic college student energy.

I was handling the backend stuff. At some point I realized we needed a way to generate ID cards, certificates, badges, and passes — all from dynamic data. A team leader's ID card should look different from a participant's. A security pass needs a QR code. A certificate should automatically have the right name and event details without someone manually editing 300 copies in Canva.

So I looked for existing tools. Most were either too expensive for a broke college student, too generic for our use case, or had API docs that genuinely made me close the tab.

So obviously I did the reasonable thing and built my own rendering engine instead. While the actual deadline was happening. No regrets.

The original platform eventually died. Turns out building an entire event system with three college students juggling exams is harder than we thought at 11pm on a Tuesday.

But I kept building the document part.

I don't fully know why. It just felt useful.

Slowly it became its own thing. New features kept getting added: a canvas editor, bulk generation from CSV, APIs, QR verification, and conditional layouts. At some point it stopped being a side feature and became the actual project.

That's 100PrintsWithMe now.

It's the tool I wish existed when I was scrambling to generate hundreds of certificates for a fest. If you've ever been the person manually editing a Word template 200 times, this is for you.

It's still a work in progress. Still evolving. Still built by a college founder who became obsessed with making document generation simple, flexible, and programmable.

And honestly, I'm proud of how far it's come.