On March 12, 2026, we launched UnWeb — an API that converts messy HTML pages into clean, token-efficient Markdown. It’s built for developers working with LLMs who need web content in a format that doesn’t waste context window tokens.

This is the story of how we went from “this should exist” to a production SaaS with Stripe payments in about three months.

The problem

If you’ve built anything with LLMs that needs to process web content, you’ve hit this wall: web pages are full of navigation, ads, scripts, and layout markup that burns through your context window without adding value. You need the content, not the Chrome DevTools output.

Existing solutions were either too basic (simple HTML stripping that loses structure) or too heavy (full browser rendering pipelines). We wanted something in between: an API call that returns clean Markdown, preserving the semantic structure while stripping everything else.

Architecture decisions

We went with a straightforward stack:

  • .NET 8 backend — our team’s strongest language, and the performance characteristics are excellent for this workload
  • Azure App Service for hosting — simple deployment, good scaling story, integrated monitoring
  • Stripe for payments — free tier with API key, paid tiers for higher volume
  • Terraform for infrastructure — everything reproducible, nothing configured by hand

The core conversion pipeline handles the hard cases: nested tables, code blocks with syntax highlighting, images with alt text, and the dozen ways sites structure their navigation that you want to strip out.

Launch day

We shipped with four URLs live, Stripe payments active, and a test suite we trusted. The first 24 hours were uneventful in the best way — the system handled traffic without issues.

Then the feedback started coming in.

55 commits in 9 days

Post-launch, we shipped 55 commits in 9 days. Not because things were broken, but because real usage revealed edge cases we hadn’t anticipated:

  • Character encoding variations across international sites
  • Paywall detection that needed to fail gracefully instead of returning partial content
  • Rate limiting tuning based on actual usage patterns vs. our estimates
  • CLI release pipeline — users wanted a command-line tool, so we built one

This is the part of building software that’s hardest to plan for. You can test extensively, but production traffic from real users finds the corners your test suite missed.

What we’d do differently

Ship the CLI from day one. Developer tools need a CLI. We knew this but deprioritized it for launch. It became the most-requested feature within 48 hours.

Set up Application Insights before launch, not after. We launched without production monitoring. For a few days, we were essentially flying blind. Errors were invisible unless a user reported them. This is now our number one post-launch priority.

Start with more generous rate limits. Our initial limits were conservative. Loosening them post-launch was easy, but it meant some early users hit walls that didn’t need to exist.

What’s next

We’re focused on three things:

  1. Production observability — Application Insights deployment is the immediate priority
  2. Browser extensions — Chrome and Firefox extensions are built and tested, pending store review
  3. Content on this blog — Tutorials for common UnWeb use cases, API tips, and integration patterns

If you’re working with LLMs and need clean web content, give UnWeb a try. The free tier doesn’t require a credit card.