DEV Community

Dragutin Spasenović
Dragutin Spasenović

Posted on

I Built a Invoice Generator That Collects Zero Data — Here's the Tech Stack

#productivity #frontend #softwaredevelopment #javascript

No accounts. No tracking. No backend. Just PDFs.

After spending way too long watching freelancer friends wrestle with bloated invoicing SaaS tools that require sign-ups, lock features behind paywalls, and quietly harvest business data, I decided to build something better.

Meet InvoiNova — a free, browser-based invoice generator that generates professional PDFs instantly, without ever touching a server.

We just launched on Product Hunt — if you find this useful, an upvote goes a long way for an indie project 🙏

The Core Constraint: No Backend

The most interesting engineering challenge wasn't building features — it was building everything without a backend. This single constraint shaped every technical decision.

Why no backend?

Most "free" invoice tools are freemium traps. They need your email to start the funnel. They store your client names and financial data to create lock-in. They sell that data or use it for targeting.

I wanted to make that architecturally impossible. If there's no server receiving data, there's nothing to leak, sell, or breach.

The Stack 

React 19 + Vite 7
Tailwind CSS 4
jsPDF
i18next (7 languages)
Cloudflare Pages (hosting)
PostHog Analytics (privacy-preserving)
Enter fullscreen mode Exit fullscreen mode

Why jsPDF over react-pdf?

This was a deliberate trade-off. react-pdf is more declarative and React-idiomatic, but it ships a significantly heavier bundle and the rendering pipeline involves more async complexity.

jsPDF generates PDFs synchronously in-browser, is battle-tested, and the bundle impact is manageable — especially with lazy loading:

// PDF generation is lazy-loaded on first use
const generatePDF = async (formData) => {
  const { jsPDF } = await import('jspdf')
  // ... generation logic
}
Enter fullscreen mode Exit fullscreen mode

This keeps the initial bundle lean and only loads the library when the user actually wants a PDF.

Shared Design Tokens for PDF/Preview Consistency

One problem with client-side PDF generation: your PDF looks different from your on-screen preview. I solved this with a shared styles utility:

// src/utils/pdf/styles.js
export const PDF_STYLES = {
  colors: {
    primary: '#1a1a2e',
    accent: '#6c63ff',
    textSecondary: '#4b5563',
    border: '#e5e7eb',
  },
  fonts: {
    display: 'helvetica', // jsPDF built-in closest to Plus Jakarta Sans
    body: 'helvetica',
  },
  spacing: {
    margin: 20,
    lineHeight: 7,
  }
}
Enter fullscreen mode Exit fullscreen mode

Both the live preview component and the PDF generator import from this file. When you tweak a color, it updates in both places.

LocalStorage as the "Database"

Everything that needs persistence lives in localStorage. Invoice history, templates (coming in the next phase), clients, language preferences — all of it.

The schema is simple:

// Invoice history index
// key: inv_history_index
[
  { id, clientName, invoiceNo, total, currency, date }
]

// Individual invoice
// key: inv_{timestamp}
{ from: {...}, to: {...}, items: [...], ... }
Enter fullscreen mode Exit fullscreen mode

A few things I learned the hard way:

FIFO matters. I cap history at 20 invoices. When the limit is hit, the oldest entry is evicted. Without this, power users would eventually hit the 5MB localStorage quota.

Index separately from data. Storing a lightweight metadata index separately from the full invoice JSON means rendering the history drawer is fast — you only load full invoice data when the user actually clicks "Load."

Don't store derived data. Totals, subtotals, tax amounts — all recalculated on load. Only store the source of truth (items with qty/price/taxRate), never the computed outputs.

Internationalisation Without a Backend

Supporting 7 languages (EN, DE, ES, PT, SR, BS, HR) with i18next on a fully static site required some thought.

All locale files are bundled at build time. Language detection uses the i18next-browser-languagedetector plugin, which checks localStorage → navigator.language → fallback to en.

The interesting part is the niche landing pages. Each regional page (e.g. /germany, /spain, /brazil) auto-switches the UI language on mount:

// NichePage.jsx
useEffect(() => {
  if (preset.lang && i18n.language !== preset.lang) {
    i18n.changeLanguage(preset.lang)
  }
}, [preset.lang])
Enter fullscreen mode Exit fullscreen mode

Combined with hreflang tags, this means /germany serves German UI and signals to Google that it's the canonical German-language version of the tool.

Currency Handling: The Ambiguous $ Problem

We support 33 currencies. Several Latin American currencies (ARS, COP, CLP, UYU) share the $ symbol with USD.

A naive implementation would display $ 5,000 on a Colombian Peso invoice, which looks identical to USD. A client receiving that invoice might genuinely not notice the currency discrepancy.

The fix:

const AMBIGUOUS_SYMBOLS = ['ARS', 'COP', 'CLP', 'UYU', 'MXN']

export function getCurrencyDisplay(code, amount) {
  const symbol = AMBIGUOUS_SYMBOLS.includes(code)
    ? `${code} $`  // e.g. "ARS $"
    : getCurrencySymbol(code)

  return `${symbol}${formatAmount(amount)}`
}
Enter fullscreen mode Exit fullscreen mode

This renders "ARS $ 5,000" instead of "$ 5,000" — unambiguous for international clients.

The Validation Philosophy

Form validation blocks PDF download but never blocks preview. The reasoning: you might want to preview a half-finished invoice to check the layout. You should never be able to download and accidentally send an invoice missing the client name or invoice number.

// Preview button: always works
<button onClick={openPreview}>Preview</button>

// Download button: validates first
<button onClick={handleDownload}>Download PDF</button>

async function handleDownload() {
  const { isValid, errors } = validateInvoiceForm(formData)
  if (!isValid) {
    setValidationErrors(errors)
    scrollToFirstError(errors)
    return
  }
  await generateAndDownloadPDF(formData)
}
Enter fullscreen mode Exit fullscreen mode

One edge case worth calling out: partially filled line items vs empty line items.

An empty row (all fields zero/empty) is silently ignored — no validation error. A partially filled row (has a description but no price) is an error and blocks download. This distinction matters because the form always renders with some empty rows as placeholders.

Deployment: Cloudflare Pages

Hosting a React SPA on Cloudflare Pages has one non-obvious requirement: client-side routing.

React Router handles navigation in-browser, but if someone navigates directly to invoinova.com/germany, Cloudflare tries to find a germany.html file, fails, and returns a 404.

The fix is a single file:

// public/_redirects
/* /index.html 200
Enter fullscreen mode Exit fullscreen mode

This tells Cloudflare Pages to serve index.html for any path, letting React Router take over. Simple, but easy to forget when you're focused on code.

Try It

invoinova.com — no sign-up, works immediately.

If you're launching on Product Hunt or want to give feedback, you can find the launch here: Product Hunt — InvoiNova

Questions about the tech decisions, the jsPDF implementation, or the localStorage architecture? Happy to dig into any of it in the comments.

Built solo. Stack: React + jsPDF + Cloudflare Pages. Honest about what it is.

Top comments (0)