81 lines
4.1 KiB
Markdown
81 lines
4.1 KiB
Markdown
# Concrete API Product Proposals — v2 (2026-02-14)
|
|
|
|
## Proposal 1: **Webhook Relay & Transform API** ("hookpipe" or similar)
|
|
|
|
**What:** API that receives webhooks, transforms/filters payloads via user-defined rules (JSONPath, templates, conditions), and forwards to one or more destinations. Think Zapier's webhook step, but as a standalone API.
|
|
|
|
**Who pays:** Developers integrating services that don't talk to each other natively. SaaS builders connecting third-party webhooks to their apps. DevOps teams routing alerts.
|
|
|
|
**Competitors:**
|
|
- Zapier/Make — overkill & expensive ($20+/mo) for just webhook routing
|
|
- Pipedream — developer-focused but complex, requires writing code
|
|
- Hookdeck — closest competitor, $25/mo for 100K events
|
|
- Svix — webhook sending (not receiving/transforming)
|
|
|
|
**Differentiation:** Dead simple. No code, no workflows, no visual builder. Just: receive → transform (JSONPath template) → forward. Config via API/dashboard. Free tier generous enough to hook devs, paid when volume grows.
|
|
|
|
**Pricing:** Free 1K events/mo → $9/mo 10K → $29/mo 100K → $79/mo 1M
|
|
**Build cost:** €0 (Go service, deploy on fly.io free tier or Hetzner €4/mo)
|
|
**Time to MVP:** 1-2 weeks
|
|
**Revenue potential:** $500-2K/mo at scale (long tail of small users)
|
|
**Risk:** Medium. Hookdeck is well-funded but expensive. Our angle is simplicity + price.
|
|
|
|
---
|
|
|
|
## Proposal 2: **Markdown/HTML to PDF API** ("pdfpipe" or similar)
|
|
|
|
**What:** Send Markdown or HTML+CSS, get back a pixel-perfect PDF. Focused on documents: invoices, reports, receipts, contracts. Not a general PDF toolkit — just rendering.
|
|
|
|
**Who pays:** SaaS apps generating invoices/reports. Devs who hate wkhtmltopdf. Agencies automating document generation.
|
|
|
|
**Competitors:**
|
|
- wkhtmltopdf — open source but abandoned, buggy
|
|
- Puppeteer/Playwright — self-hosted headache
|
|
- DocRaptor — $15/mo (125 docs), Prince-based, excellent but expensive
|
|
- PDFShift — $9/mo (250 docs)
|
|
- Gotenberg — open source (Chromium-based), no hosted offering with good DX
|
|
|
|
**Differentiation:**
|
|
1. Markdown-first (competitors are HTML-only)
|
|
2. Built-in invoice/report templates (send JSON, get PDF)
|
|
3. Cheaper than DocRaptor, better DX than self-hosting Gotenberg
|
|
4. Template library for common use cases
|
|
|
|
**Pricing:** Free 50/mo → $7/mo 500 → $19/mo 2K → $49/mo 10K
|
|
**Build cost:** €0-4/mo (Chromium on small VPS or fly.io)
|
|
**Time to MVP:** 1 week
|
|
**Revenue potential:** $300-1.5K/mo
|
|
**Risk:** Low. Well-understood problem, many bad solutions, room for good DX.
|
|
|
|
---
|
|
|
|
## Proposal 3: **JSON Schema Validation API + Registry** ("schemacheck" or similar)
|
|
|
|
**What:** API to validate JSON payloads against schemas, store/version schemas, generate documentation. Webhook validation as a service.
|
|
|
|
**Who pays:** Teams building APIs who need payload validation. Webhook providers who want to validate outgoing payloads. Companies standardizing data contracts across microservices.
|
|
|
|
**Competitors:**
|
|
- ajv (library, not a service)
|
|
- JSON Schema Store (free, community, no API)
|
|
- Stoplight/Optic — API design tools (different category)
|
|
|
|
**Differentiation:** No direct SaaS competitor for "schema validation as a service." It's a gap because most people use libraries. But an API makes sense for: webhook validation, cross-language teams, CI/CD pipelines, no-code tools.
|
|
|
|
**Pricing:** Free 1K validations/mo → $9/mo 50K → $29/mo 500K
|
|
**Build cost:** €0 (pure Go, no browser needed, tiny resource footprint)
|
|
**Time to MVP:** 3-5 days
|
|
**Revenue potential:** $200-800/mo (niche)
|
|
**Risk:** High. Market might be too small — people just use libraries.
|
|
|
|
---
|
|
|
|
## Recommendation: **Proposal 1 (Webhook Relay)** or **Proposal 2 (PDF API)**
|
|
|
|
**Webhook Relay** has the best market dynamics: clear pain point, expensive competitors, sticky product (once integrated, hard to switch). But harder to get first customers.
|
|
|
|
**PDF API** is easier to ship and easier to get first users (developers searching "html to pdf api" is a proven search query with volume). Lower ceiling but faster to revenue.
|
|
|
|
I'd start with **PDF API** — ship in a week, validate demand, then potentially add webhook features later as a "developer tools" brand.
|
|
|
|
**Awaiting human decision.**
|