Why We Don't Have a Template Builder (And Never Will)

The question we get most

“Where's the template builder?”

Every e-signing platform — DocuSign, HelloSign, PandaDoc, SignWell — has some version of a visual editor where you upload a PDF, drag signature fields, text fields, and date fields onto the page, and save it as a template. Then your API references the template by ID.

Signbee doesn't have this. We never will. And here's why.

Template builders are designed for humans

A drag-and-drop editor assumes a person with a mouse and a screen is setting things up. That person opens a web UI, uploads a PDF, clicks where the signature goes, clicks where the date goes, saves the template, and copies a template ID.

That workflow works. It's been working for fifteen years. But it has a fundamental problem: it can't be done by software.

An AI agent can't open a web UI. It can't drag fields onto a PDF. It can't click “Save Template”. It can't even process a visual layout — it has no concept of “200 pixels from the left, 400 pixels from the top”.

If your primary user is software, your document format needs to be software-friendly.

Markdown is the answer

Every AI model in existence can write markdown. It's the native output format of large language models — structured, readable, and trivially parseable. An agent can draft an entire NDA in markdown in under a second.

With Signbee, the document creation and sending happen in a single API call. The agent writes the markdown, passes it to the API, and Signbee converts it to a formatted PDF, handles the signing ceremony, and delivers the certified copy. One step. No pre-configuration.

The template builder has five steps. Signbee has two. And in the second approach, the AI can do both steps without human help.

But what if I already have a PDF?

Use it. Signbee accepts a pdf_url parameter — pass any publicly accessible URL to your existing PDF and Signbee handles only the signing ceremony. Your design, your layout, your brand — exactly as-is. We don't touch the content.

This is the best of both worlds: design your documents however you want (Figma, InDesign, LaTeX, Google Docs, Word), export to PDF, host it anywhere, and let Signbee handle the rest.

No field positioning. No drag-and-drop. No template IDs. Just a URL.

The complexity trap

Template builders create a dependency chain. Once you build templates, you need template management — versioning, archiving, sharing, permissions. Then you need field mapping — connecting template fields to your data model. Then you need conditional logic — showing different fields based on context.

Before you know it, you're maintaining a document management system on top of a signing platform. That complexity is justified for enterprise legal teams managing thousands of contract variants. It's not justified for a developer who needs to send an NDA.

We chose to stay simple. One endpoint. Markdown in, signed PDF out. The entire API fits in a single text file.

The audience question

Every product decision comes down to: who is your user?

If your user is a legal operations manager at a Fortune 500 company, build a template builder. They need it. They have complex workflows, compliance requirements, and approval chains that demand visual configuration.

If your user is a developer who wants to add signing to their app, or an AI agent that needs to send contracts autonomously — a template builder is harmful. It adds friction to a workflow that should be frictionless. It requires setup before the first document can be sent. It assumes a human is in the loop.

We built Signbee for the second group. The choice not to build a template builder is the choice to serve our users well — even when it looks like a missing feature to everyone else.

What we believe

The document is the content, not the container. When you separate the document (markdown) from the signing ceremony (Signbee's API), you get maximum flexibility with minimum configuration. The AI can write any document it wants — an NDA, a SOW, a freelance contract, an invoice — and send it through the same endpoint.

No templates to create. No fields to position. No IDs to manage. Just content and an API call.

That's the product we're building. And it's working.