I spent weeks building an API credit system… then realized I didn't need one.

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 )