Pritset

Pritset is an API for generating PDFs from DOCX templates. Developers send JSON data through an API, and Pritset returns a generated PDF.

The goal is simple: help companies avoid rebuilding document layouts in code every time they need to change an invoice, report, contract, receipt, booking confirmation, or other business document.

I recently got my first customer, which changed the way I look at the product.

Before the first customer, the main question was:

“Does anyone actually need this?”

Now the question is different:

“Can I find enough companies with the same pain to turn this into a real business?”

For me, $5,000 MRR is the next serious milestone.

Not because it is a huge number, but because it would prove a few important things:

1. The problem is real enough that companies will pay for it repeatedly.

2. Pritset can create value beyond one early customer.

3. The positioning is clear enough to attract the right users.

4. The product can support real business workflows.

5. I can start thinking less like a developer with a project and more like a founder building a company.

The current pricing is usage-based: the first 5,000 requests are free, then $0.003 per successfully generated document.

That means $5,000 MRR will probably not come from one type of customer only.

It could come from startups generating documents for their users, ERP/CRM systems, Odoo partners, travel platforms, healthcare software, finance tools, HR platforms, or companies with high-volume document workflows.

Right now I am still learning which segment has the strongest pull.

Some possible directions I am testing:

• Travel and booking platforms that generate confirmations, vouchers, invoices, or itineraries

• Odoo partners that customize invoices, quotations, delivery notes, and reports

• HR/CV tools that generate resumes, contracts, or certificates

• Finance and billing tools that generate invoices, statements, and reports

• Healthcare systems that generate patient-facing or internal documents

The hard part is not only building the product.

The hard part is finding where document generation is painful enough that companies actively want a better workflow.

My current plan is simple:

1. Keep talking to document-heavy companies.

2. Improve onboarding based on real user confusion.

3. Add examples for the most common use cases.

4. Make the value proposition clearer.

5. Focus on segments where PDF/document generation is not just a feature, but part of the business workflow.

I know $5,000 MRR is still far away from where Pritset is today.

But now I have a real first customer, real feedback, and a clearer direction than before.

So this is the next target.

I will try to share the journey honestly: what works, what does not, which segments respond, and what I learn while trying to reach it.

For other founders here: when did you set your first serious MRR target, and how did you decide what number made sense?

I got my first customer for Pritset.

For some people this may sound small, but for me it feels like a very important milestone.

Pritset is an API for generating PDFs from DOCX templates. The idea is simple: instead of building custom PDF layouts in code, developers can use Microsoft Word templates, pass JSON data through an API, and get a generated PDF back.

When I started building it, the biggest question was not technical.

The real question was:

Does anyone actually need this?

As developers, we can spend a lot of time building something that feels useful to us. But until someone outside your own head tries to use it, you do not really know.

My first customer is a travel startup. Their case is very close to what I had in mind when building Pritset: document generation from business data, where templates may change and the company does not want to spend developer time rebuilding PDF layouts again and again.

What I learned from this first customer experience:

1. The first customer is not only about money

Of course, revenue matters. But the bigger value is learning.

A first customer shows you where your onboarding is confusing, what your documentation is missing, what is obvious to you but not obvious to others, and what parts of the product actually matter.

1. The product needs to be explained much simpler

I used to think mostly in terms of API, DOCX templates, JSON, webhooks, conversion, and infrastructure.

But customers usually think in terms of:

“I need to generate an invoice.”
“I need to create a report.”
“I need to send a document to my client.”
“I do not want to manually edit this every time.”

That is a big difference.

1. Founder-led sales is uncomfortable but necessary

Before this, I spent most of my time building. Writing code is comfortable. Talking to customers is much less comfortable.

But after doing outreach and conversations, I understand that the product direction becomes much clearer only after real conversations.

Even replies like “not now” or “we do this another way” are useful signals.

1. Small startups are a good place to start

Big companies may have complex buying processes, security requirements, and long decision cycles.

A small startup can move faster, give direct feedback, and help you understand the real use case much earlier.

1. The first customer changes your mindset

Before the first customer, it feels like you are trying to prove that the product should exist.

After the first customer, the question changes.

Now it becomes:

Who else has the same problem?
How do I find them?
How do I make onboarding easier?
How do I turn this into repeatable sales?

I still have a lot to improve in Pritset: onboarding, examples, documentation, positioning, and probably many product details I have not discovered yet.

But now I have something real to build from.

The product is no longer just an idea or a technical project.

It has a real customer using it.

For me, that is a big step.

I’m building Pritset — an API that generates PDFs from DOCX templates.

The idea came from a problem that looks simple at first:

“We just need to generate a PDF.”

But then the product grows.

You need invoices, reports, contracts, receipts, booking confirmations, certificates, statements, or other customer-facing documents.

At some point, developers start maintaining HTML templates, PDF rendering logic, styling issues, layout bugs, async generation, file storage, retries, and customer-specific document changes.

I’m trying a different approach:

Let teams design documents in Microsoft Word, then generate PDFs from those DOCX templates through an API using JSON data.

The goal is simple:

• developers keep the integration simple

• non-technical people can edit document layouts

• companies do not need to rebuild document generation from scratch

Right now, I’m doing customer discovery and trying to understand where document generation is actually painful.

I’d love to hear from other founders and developers:

Do you generate PDFs in your product?

If yes:

• What do you use today?

• Is template editing painful?

• Who owns document changes — developers or business users?

• Would DOCX-based templates be useful for your workflow?

I also created example integrations for Node.js, .NET, Java, and Python:
https://github.com/daviatorstorm/pritset-examples

Happy to hear honest feedback.