DEV Community: Sabrina Brown

Building a Resilient B2B Invoice Parser API: Swapping Brittle Regex for Structured LLM Outputs

Sabrina Brown — Wed, 21 Oct 2026 22:42:01 +0000

As a solo developer managing a complex tech stack spanning native mobile apps, SaaS platforms, and automated B2B financial pipelines, I despise manual data entry. It is the ultimate bottleneck in any business workflow.

Recently, I was looking into automated invoice parsing. The traditional approach to extracting data from raw PDFs or JPEGs usually involves legacy OCR (Optical Character Recognition) layered with complex Regular Expressions (Regex). The problem? It is incredibly brittle. The moment a vendor changes their invoice layout, moves the “Total Amount” column a few pixels to the left, or introduces a new foreign character, the Regex breaks, the pipeline fails, and a human has to manually intervene.

I needed a solution that was resilient, headless, and capable of being monetized natively for autonomous AI agents and standard B2B SaaS integrations.

Here is how I built the Jazzy Invoice Parser API — a serverless Node.js endpoint leveraging OpenAI’s structured outputs — and deployed it for global discovery.

The Architecture & Tech Stack

**
To keep overhead low and margins high, the infrastructure had to be serverless and auto-scaling. The stack consists of:

Backend Hosting: Firebase Cloud Functions (Node.js / v2)
Intelligence: OpenAI API (gpt-4o-mini)
Monetization & Gateway: Zyla API Hub (Stripe-backed)
Corporate Infrastructure: Hostinger (Jazzy Management LLC portfolio)

Firebase Cloud Functions running on the Blaze (pay-as-you-go) plan provided the perfect foundation. It scales to zero when not in use, meaning I don’t pay for idle server time, yet it instantly spins up to handle concurrent requests when a client’s pipeline executes a batch of end-of-month invoices.

The Secret Sauce: Structured LLM Outputs

The core flaw of using standard LLMs for data extraction is the hallucination risk and unpredictable formatting. If an API returns a string one day and a nested array the next, the consuming application will crash.

To solve this, I bypassed standard prompting and utilized OpenAI’s Structured Outputs capability. By strictly defining a JSON schema in the backend codebase, the LLM is forced to return data that matches the exact expected types.

The API accepts a simple POST request containing a public file URL (JPG, PNG, or PDF). The backend logic processes the file through the gpt-4o-mini vision model, instructed to extract four specific data points:

vendorName (String)
totalAmount (Number)
dueDate (String)
lineItems (Array of objects containing description and amount)

Stress Testing with Global Data

**
To ensure the API was production-ready, I stress-tested it using a complex Swiss-German receipt. Traditional OCR struggles with international layouts, varied currency symbols, and UTF-8 characters like umlauts.

The API flawlessly processed the image on the first pass, extracting the vendor “Berghotel Grosse Scheidegg” and perfectly mapping the array of line items — including localized items like “Chasspatzli” — into a clean, consumable JSON payload. No Regex adjustments required. The vision model understands context, not just coordinates.

Bypassing Legacy Hubs for MCP-Readiness

**
With the logic deployed and tested via curl, the next step was monetization. Initially, developers default to massive marketplaces like RapidAPI. However, after encountering rate-limiting errors and Cloudflare 1200 blocks just trying to load their dashboard, I pivoted. A B2B automation pipeline requires absolute stability; you cannot build a business on an infrastructure that drops traffic.

I deployed the endpoint to Zyla API Hub. Zyla offers a critical advantage for modern API development: native MCP (Model Context Protocol) readiness.

This means that autonomous AI agents (like Claude or Cursor) can natively discover, subscribe to, and execute the Jazzy Invoice Parser API without human intervention. By configuring the endpoint on Zyla, I established a secure gateway that handles Stripe billing, API key issuance, and rate limiting, while retaining 80% of the subscription revenue.

The Economics of a Headless Solo Enterprise

**
The beauty of this architecture is the profit margin. Fulfilling an API call via gpt-4o-mini costs fractions of a penny. By structuring the Zyla listing into tiered B2B subscriptions — ranging from a $29/month Pro plan for standard workflows up to a $999/month Ultimate plan for enterprise SaaS platforms — the API generates high-margin, recurring MRR.

Furthermore, leveraging API Discoverability tools allowed me to generate multiple SEO-optimized storefronts (e.g., “Swiss Receipt Reader,” “Business Expense Tracking API,” “PDF Data Extraction”). All of these niche listings route back to my single Firebase endpoint, capturing long-tail search traffic with zero additional code maintenance.

Final Thoughts

**
The Jazzy Invoice Parser is now officially live and sitting in the Jazzy Management LLC software portfolio. By combining serverless Firebase functions with structured LLM outputs, I replaced a historically fragile process with an adaptable, AI-driven endpoint.

Whether it is integrated into a custom Proposal-to-Invoice financial pipeline or consumed directly by an autonomous agent, the infrastructure is built to scale automatically, securely, and profitably.

— -

* UPDATE: Live Upgrades Implemented *

Thank you to everyone who commented with suggestions and feedback. Based on your input, the Invoice Parser API has been officially upgraded and is now live in production.

Key improvements include: **
• **Native PDF & Image Support: The extraction engine was rebuilt to seamlessly process both direct PDF documents and image-based invoices (JPG/PNG).
• Strict Math Validation: The extraction schema now deterministically cross-checks all financial fields (line items sum to subtotal; subtotal + taxes + fees — discounts = total). If the math does not align, the API forces a recalculation to ensure your automated B2B pipelines receive flawless data.
• Infrastructure Upgrade: Migrated the Firebase backend to a modern Node 22 runtime for faster, more reliable server processing.

The endpoint is fully operational and ready to be wired into your automated workflows to completely eliminate manual data entry.

What manual data entry task is currently bottlenecking your business? Drop a comment below or email me directly at info@jazzymgmt.com. I might build a custom API endpoint for it!

P.S. To ensure you don’t miss my next technical breakdown on how I package these APIs into high-margin recurring subscriptions, add info@jazzymgmt.com to your contacts and subscribe to the developer newsletter at https://jazzymgmt.com/

From Broad SaaS to Micro-Niches: Architecting 8 Custom Landing Pages at Scale

Sabrina Brown — Thu, 15 Oct 2026 01:08:21 +0000

Building a robust SaaS application is only 20% of the battle. The other 80% is distribution.

**
When I engineered JazzySend — a B2B web application designed for secure, automated email campaigns utilizing Firebase and the Resend API—the core functionality was universally applicable. Every modern business needs isolated, secure email routing and dynamic template scheduling.

But there is a massive marketing problem with "universal" software: if you are selling to everyone, you are selling to no one. A generic "Secure Email Automation" page does not convert a law firm terrified of an IOLTA compliance audit, nor does it convert a real estate investor trying to calculate their max allowable offer while managing a wholesale buyer list.

To solve this distribution bottleneck, I shifted our frontend architecture from a single, broad funnel into a highly segmented micro-niche strategy. Here is a technical and strategic teardown of how I architected, built, and deployed 8 custom, industry-specific landing pages at scale without fracturing our core backend codebase.

The CAC Trap of Broad Software

**
For independent developers and boutique software agencies, competing on broad search terms is a fast track to burning through your marketing budget. If you try to rank for or buy ads against the keyword "email automation," you are entering a bidding war with billion-dollar enterprise giants. Your Customer Acquisition Cost (CAC) will instantly exceed your Customer Lifetime Value (LTV).

However, the competition for long-tail, industry-specific queries is remarkably low. An accountant isn't searching for "email automation"—they are searching for "automated secure client tax document reminders."

By creating dedicated entry points for Accountants, Law Firms, Property Managers, Real Estate Investors, Event Planners, Independent Creators, SaaS Founders, and Serial Entrepreneurs, we bypass the generic software bloodbath and speak directly to highly qualified, high-intent traffic.

The Component-Driven Frontend Architecture

**
Maintaining 8 completely different website builds is a nightmare for version control. If you update a pricing tier or add a feature, updating it across 8 hardcoded HTML files introduces massive technical debt.

Instead, the solution relies on a component-driven architecture using Hostinger's web builder capabilities. The backend application remains a unified single source of truth, while the frontend dynamically maps specific industry pain points to those universal capabilities.

Our core infrastructure—Firebase Auth, Stripe subscription billing, and our backend webhooks—does not change whether a property manager or a SaaS founder signs up. The architecture simply reroutes the user’s context upon entry.

Each landing page utilizes the exact same structural blocks: a hero section, a three-point feature breakdown, an interactive element, and a conversion CTA. The engineering trick is in the copy injection.

The copy and visual assets are swapped dynamically to match the precise vocabulary of the target sector. For example, JazzySend's "Dynamic Tags" feature is fundamentally just string interpolation in our codebase. But on the frontend:

To [Accountants](https://jazzysend.com/for-accountants), it is marketed as a way to automate "Tax Deadline Reminders."

To [Event Planners](https://jazzysend.com/event-planners), it is framed as automating "Vendor Arrival Schedules."

To [Law Firms](https://jazzysend.com/for-law-firms), it is positioned as "Case Status Updates."

Same code. Completely different perceived value.

Engineering Interactive Speed Bumps

**
Static landing pages have notoriously low conversion rates because they rely entirely on reading comprehension. To make these 8 micro-niches actually perform, I engineered "interactive speed bumps" directly into the page layouts.

Instead of just telling an audience that manual administration is costing them money, I embedded custom financial logic calculators directly into their specific funnels to prove it mathematically.

On the [/for-law-firms](https://jazzysend.com/for-law-firms**)** page, users hit a live IOLTA 3-Way Reconciliation Calculator. Before they even read the software pitch, they are forced to confront the anxiety of a trust accounting audit.

On the /for-accountants page, they interact with a Billable Hour Leakage Calculator, quantifying exactly how much unbilled revenue they lose to manual data entry.

On the /real-estate-investors page, they are presented with a Deal Analysis Toolkit featuring BRRRR and Rental Property Cash Flow calculators.

By embedding these tools directly above the JazzySend product features, the page architecture forces the user to actively quantify their own administrative overhead. Once the calculator proves the financial severity of their problem, the page seamlessly presents the JazzySend subscription as the automated solution.

Phase 2: Planning the Backend Routing on a Bootstrapped Budget

**
As an indie developer, the golden rule is to validate top-of-funnel distribution before over-engineering the backend. Right now, these 8 custom landing pages act as our validation layer. But eventually, the micro-niche strategy shouldn't stop at the frontend. If a real estate investor converts on their specific page but receives a generic "Welcome to JazzySend" onboarding email, the contextual bridge weakens.

The next architectural phase is orchestrating an industry-specific onboarding sequence without breaking the bank or exceeding the free-tier limits of automation tools like Make.com. You don't actually need 8 separate scenarios to handle 8 different niches.

Instead, the architecture is designed so that when a user creates an account, the payload includes a hidden origin tag indicating which of the 8 pages they converted on. A single Make.com webhook catches this payload. From there, a "Router" module evaluates the tag and triggers the appropriate dynamic template via the Resend API. This lean setup will allow JazzySend to scale personalized onboarding—sending rent collection templates to property managers and trust notice templates to lawyers—all within a single, highly efficient automation scenario.

The SEO and Long-Tail Advantage

**
From an infrastructure standpoint, deploying 8 separate pages instantly expands the application's domain footprint. Search engine crawlers can now index [https://jazzysend.com/for-law-firms] specifically for queries like "secure email automation for attorneys" or "IOLTA trust notice templates."

Scaling a SaaS product requires looking past the backend tech stack and engineering the distribution funnel. You don't need to rebuild your software to target a new market; you just need to architect a dedicated door for them to walk through. By combining component-driven landing pages, interactive calculators, and an easily scalable architecture, you can turn a single, broad application into a suite of highly targeted micro-SaaS solutions.

Architecting Financial Logic for the Web: Building an IOLTA 3-Way Reconciliation Tool

Sabrina Brown — Fri, 02 Oct 2026 22:32:12 +0000

When building web applications, developers spend a massive amount of time optimizing state management, reducing render cycles, and perfecting UI components. But when you start building software for the legal and accounting sectors, the priority completely shifts. A dropped frame on an animation is a minor bug; a dropped decimal in a trust account is a disbarment.

Transitioning from a career deeply rooted in corporate finance and transaction processing into software development gave me a unique perspective on how brittle typical web math can be. Recently, while building out the growth tools for Jazzy Management LLC, I decided to engineer a free IOLTA (Interest on Lawyers' Trust Accounts) 3-Way Reconciliation Calculator.

Here is a technical teardown of the financial logic required to build a compliant reconciliation tool, how to handle the data architecture, and how we tied it into a backend automation system to drive our core B2B SaaS, JazzySend.

The Stakes of IOLTA and the 3-Way Match

State Bar associations mandate that attorneys hold client funds (like retainers or settlement payouts) in specialized trust accounts. The compliance standard for these accounts isn't a simple bank-to-book match. It requires a strict 3-way reconciliation:

Adjusted Bank Balance: The ending bank statement balance, plus uncleared deposits, minus outstanding checks.

Book Balance: The total running balance in the firm’s internal accounting journal.

Sum of Individual Client Ledgers: The aggregated total of every individual client's trust sub-account.

For the firm to be compliant, all three of these numbers must match to the exact penny. If Adjusted Bank Balance != Book Balance or Book Balance != Sum of Client Ledgers, the firm is out of compliance and faces immediate audit risk.

The challenge in building this for the web is that you are asking a browser to handle strict financial transaction math—which brings us to the first major architectural hurdle.

Defeating the Floating-Point Problem

If you have spent any time writing JavaScript or Dart, you are likely familiar with the floating-point math issue where 0.1 + 0.2 === 0.30000000000000004. When dealing with hundreds of thousands of dollars in a trust account, relying on standard floating-point numbers for financial logic is catastrophic.

To ensure strict compliance in the calculator, all user inputs must be intercepted, sanitized, and converted into integers before any mathematical operations occur.

Instead of calculating $50,500.55 - $1,500.20, the architecture strips the decimals and calculates everything in cents: 5050055 - 150020.

Input Sanitization: Regex strips currency symbols, commas, and errant spaces from the user's input fields.

Integer Conversion: The sanitized string is parsed into a float, immediately multiplied by 100, and rounded to the nearest whole integer using Math.round() to eliminate trailing decimal artifacts.

Reconciliation Logic: The three-way match is calculated entirely using these integer values.

Presentation Layer: Only after the variance is calculated (e.g., finding a discrepancy of 5000 cents) is the value divided by 100 and formatted back into a localized currency string (e.g., $50.00) for the user interface.

This ensures that the strict zero-tolerance variance required by Bar associations is mathematically guaranteed by the tool's core logic.

State Management for Multi-Step Verification

An IOLTA reconciliation is not a single input-output equation. It requires holding multiple interdependent states. The calculator must manage:

bankStatementBalance

unclearedDeposits

outstandingChecks

bookBalance

clientLedgerSum

I architected the component to utilize a reactive state model. As the user inputs the first three variables, the adjustedBankBalance is dynamically computed in real-time. When the user clicks "Verify Compliance Status," the application evaluates the three core pillars.

If adjustedBankBalance === bookBalance === clientLedgerSum, the state updates to yield a "Compliant" success message. If any of those values diverge, the component calculates the exact variance amount, isolates which of the three pillars failed the match, and dynamically renders an error state warning the user of an audit risk.

Routing the Logic to Backend Automation

A free tool is only useful if it drives the core business forward. The entire purpose of this calculator is to highlight a law firm's administrative pain points and route them directly into JazzySend—our secure B2B email marketing platform.

When a firm finds a variance, the immediate next step is usually notifying clients of trust account replenishment requirements or missing funds. Doing this manually via standard BCC emails is a massive security risk for sensitive legal data.

To bridge this gap, the calculator acts as a contextual primer. While the calculator processes the logic on the client side, the surrounding page architecture is designed to capture the user's intent. Once they realize the complexity of their trust accounting, the page seamlessly introduces JazzySend's isolated-instance architecture.

By utilizing Make.com to handle our backend webhooks and Resend for transactional email delivery, we can automate the exact pain points the calculator brings to light. If a firm needs to request immediate trust replenishment, they don't draft a new email; they use JazzySend's dynamic tags to pull the exact variance data and route a secure, automated template to their client list via Firebase-backed infrastructure.

Building financial tools for the web requires a rigid adherence to mathematical precision, but when executed correctly, it serves as the ultimate proof of competence. You aren't just telling a highly analytical audience that your software is secure and accurate; you are mathematically proving it to them right inside their browser.

By utilizing Make.com to handle our backend webhooks and Resend for transactional email delivery, we can automate the exact pain points the calculator brings to light. If a firm needs to request immediate trust replenishment, they don't draft a new email; they use JazzySend's dynamic tags to pull the exact variance data and route a secure, automated template to their client list via Firebase-backed infrastructure.

How to Wire Up Firebase, Stripe Webhooks, and Resend API in a SaaS Backend

Sabrina Brown — Thu, 20 Aug 2026 23:12:51 +0000

Stop wrestling with backend infrastructure. Learn how to securely integrate Firebase Cloud Functions, Stripe Webhooks, and the Resend API for your next SaaS project.

Building a SaaS application usually follows a painfully predictable cycle: you have a great idea for a core feature, but before you can build it, you have to spend three weeks wrestling with authentication, database security, payment gateways, and transactional emails.
Wiring together Firebase for user management, Stripe for subscription handling, and Resend for email delivery is the gold standard for a modern backend, but the integration points can be incredibly tedious.
Here is a high-level breakdown of how to structure this architecture so your app is secure and scalable from day one.

Firebase Cloud Functions as the Command Center

Instead of exposing your database directly to the frontend, utilize Firebase Cloud Functions. This keeps your business logic entirely server-side. When a user creates an account, a trigger function should automatically generate their profile document in Firestore, establishing their baseline data structure before they even hit your onboarding screen.

Handling Stripe Webhooks Securely

The most common mistake when integrating Stripe is relying on client-side success messages to grant user access. If a user closes the browser too quickly, or if a payment is delayed, their account state breaks.

Instead, use Stripe Webhooks routed directly to a dedicated Firebase Cloud Function.

Your endpoint needs to:

Verify the Stripe signature to ensure the payload is authentic.
Listen specifically for checkout.session.completed and customer.subscription.deleted.
Update the user's active status and tier directly in Firestore based on these secure backend events.

Plugging in the Resend API for Transactional Emails

Deliverability is everything. Instead of using generic SMTP setups, integrate the Resend API directly into your Cloud Functions. You can set up event listeners in Firestore so that when a specific document changes (e.g., a "welcome email" flag is set to true during Stripe checkout), a function automatically fires an HTTP request to Resend, dispatching your beautifully coded welcome templates without any manual intervention.

The Developer Shortcut

Understanding this architecture is one thing; writing, testing, and debugging the hundreds of lines of code required to make Firebase, Stripe, and Resend talk to each other flawlessly is another.

If you are a developer looking to launch your next SaaS project this weekend instead of next month, you don't need to build this from scratch.

I’ve packaged my exact production-ready architecture into a Secure SaaS Backend Boilerplate. It includes the fully configured Firebase Cloud Functions, pre-mapped Stripe Webhook listeners, and the Resend API integration, all ready to deploy.