One-Page Brief: A Developer API for a Job Businesses Repeat Forever
Verdict
As described, the idea is "a developer API tied to a recurring job", with four candidates:
- invoice and business-document PDF generation from templates;
- EU VAT and company-ID validation;
- address validation for one region;
- a niche data feed.
The design rule comes from ScreenshotOne. It reached $32K MRR with 1,000+ customers, then stalled, because it loses 9% of revenue a month to customers whose "project ended". The fix is to pick an API used inside a process that never ends.
The pick is invoice documents, narrowed to legally mandated e-invoices for Germany. DocPress takes invoice data as JSON. It returns:
- a branded ZUGFeRD / Factur-X hybrid PDF with EN 16931 XML inside;
- XRechnung XML;
- a validation report against the official rules.
It also parses incoming e-invoices into JSON.
With the 3 conditions met, the odds at month 24 are:
| MRR | ~15 hrs/week | Full-time | As described (generic PDF API) |
|---|---|---|---|
| $1k | 45% | 60% | 30% |
| $3k | 30% | 45% | 16% |
| $5k | 22% | 35% | 10% |
| $10k | 12% | 22% | 5% |
| $20k | 5% | 11% | 2% |
| $50k | 1% | 3% | <1% |
No verified base rate exists for bootstrapped B2B micro-SaaS. For scale only: 17.3% of new mobile subscription apps reach $1k a month within 2 years, and 4.6% reach $10k (RevenueCat 2026). Not fundable, and it doesn't need to be.
The five things that matter
- Churn decides the ceiling, and use case decides churn. Max MRR = new MRR ÷ churn. ScreenshotOne's project-based buyers cap it at ~$33K. At 2.5% churn, the same ceiling needs only ~$830 of new MRR a month. Pick the buyer who can't stop needing you.
- A plain PDF invoice stops being a legal B2B invoice in Germany. From 1 Jan 2027 (prior-year turnover >€800k) and 1 Jan 2028 (everyone), invoices must be structured EN 16931 e-invoices (XRechnung or ZUGFeRD). ViDA makes structured e-invoices the EU standard for cross-border B2B from 1 July 2030. France went live on 1 Sept 2026, Belgium on 1 Jan 2026. That's a legal duty on every invoice, which is the most recurring job there is.
- Stripe doesn't do it. Stripe's own docs say Invoicing "doesn't generate or transmit legally compliant e-invoice files on its own". Companies that bill from their own code need an API, a library, or a partner app.
- The XML is free. Certainty isn't. Mustangproject (Java), horstoeko/zugferd (PHP) and factur-x (Python) are free and good, and Apify actors sell generation from $10 per 1,000. Your real competitor is a developer's weekend with an open-source library. You win on a hosted API, validation on every document, plain-language errors, German docs, a Stripe connector and inbound parsing. You don't win on the file format.
- The other three candidates lose on the evidence:
- VAT validation: Stripe validates EU VAT IDs automatically, VIES is free, prices start at $9.99, and clones are multiplying.
- Address validation: it needs licensed data (Royal Mail PAF: £7,525 a year for one website), and GetAddress.io was shut down after a database-rights ruling.
- Data feeds: they compete with free sources, and no indie discloses meaningful revenue.
Feature sort (headline)
- Table stakes: HTML-to-PDF rendering, templates, API keys, usage dashboard, webhooks, SDKs, EU hosting and DPA.
- Differentiators: JSON → valid ZUGFeRD / XRechnung in one call, validation on every document with the rule version recorded, plain-language error messages in German and English, inbound e-invoice parsing to JSON, Stripe invoice → e-invoice connector, a free public validator.
- Distractions: drag-and-drop template designer, no-code integrations as the core, screenshots, generic "any document" positioning, many countries at once.
- Liabilities: becoming a Peppol access point or French certified platform yourself, "tax advice" or "guaranteed compliant" claims, sending invoices on customers' behalf, unlicensed address data.
Most likely cause of death
The buyer solves it without you. The German developer uses a free library, or the business moves invoicing into DATEV, lexoffice, sevdesk or Billit. You'd see it early: day-21 calls where people say "we'll just use Mustang", and a validator page with traffic but no signups.
Next 90 days
Do: sign 3 paying design partners by day 21 with a hand-run conversion, ship JSON → ZUGFeRD / XRechnung with validation by week 8, and launch the free validator. Reach 10–15 paying ($500–1k MRR) by day 90. Stop: thinking of this as a PDF API. It's a compliance API that happens to output a PDF.