Chapter 02 — Product thinking: pick a real problem, price it, position it

Here is the uncomfortable statistic that shapes this chapter: most software built by developers fails not because the code was bad, but because it was the wrong thing to build. The code is the part you're good at. The part nobody teaches you — deciding what to build, for whom, at what price, standing next to which competitors — is product thinking, and it's learnable. This chapter is the thinking we did before and during FoxyInvoice, with the real decisions and the real numbers, including the ones that humbled us.

We were user zero (the origin, honestly)

FoxyInvoice did not start as a startup idea. It started because SEOlith, the small company behind it, needed its own books managed — invoicing, US sales tax across jurisdictions, exports the accountant would actually accept. The enterprise product you'll see at invoices.seolith.com runs our actual accounting today.

That's the oldest risk-reduction trick in software: scratch your own itch. When you are the first user, you never argue with a specification — you argue with your own annoyance, which is honest, immediate, and free. You know exactly when the thing is good enough, because you use it on Monday. And when we later aimed the same codebase at freelancers and small businesses (foxyinvoice.com), the dogfooding continued: every bug in the editor, we hit first.

There's a second advantage people underrate: a real business is a requirements machine. "Recurring invoices" wasn't a feature idea; it was a bill we sent every month by hand. "Tax by jurisdiction" wasn't a roadmap bullet; it was an amount we got wrong once. Your own operations generate better requirements than any brainstorm.

Why invoicing, though? Reading a mature market

"Competition means the market is proven" is the sentence to internalize. A market with zero competitors usually means zero demand. Invoicing has wave after wave of competitors for one reason: everyone with a side-hustle, trade, or consultancy must send an invoice to get paid. The need is universal, recurring, and — critically — sits directly on money, where people pay for reliability.

The downsides are equally real, and we wrote them down before writing code:

• It's a mature market — you won't out-feature QuickBooks in a quarter, and you shouldn't try.
• Switching costs are emotional: people fear changing the tool that touches their income.
• "Free" competitors already exist, so the floor is set.

You enter a market like this with a wedge — one sharp difference that matters to a specific group — never with "like X but better." Ours, in one line from the strategy document:

Free-forever invoicing that gets you paid — from template to PDF to payment in minutes, with sales-tax depth no free tool matches.

Every clause is a commitment. We'll unpack each.

The competitor map is free education

Before writing code, we made a map. Not to find an empty quadrant (there isn't one), but because every competitor is a paid research report on what users value and what they resent. Here's what each taught us:

flowchart TB
    subgraph Market["The invoicing market — what each player teaches"]
        subgraph Suites["Suites: broad, priced"]
            QB["QuickBooks
the accountant's incumbent"]
            FB["FreshBooks / Bonsai
consultant workflows"]
            ZOHO["Zoho Invoice
free tier inside a 45-app suite"]
        end
        subgraph FreeTier["Free with a catch"]
            WAVE["Wave
'free' that got repriced"]
            NINJA["Invoice Ninja
free if YOU host it"]
        end
        GAP["THE GAP WE AIM AT
genuinely free core · payment links built in
· correct sales tax · zero signup to start"]
        US["FoxyInvoice
Free forever → Pro $9 → Business $29"]
        QB -->|"accountants live here:
speak IIF/CSV/Tally, don't replace them"| EXPORT["Exports as the bridge
(never fight the accountant)"]
        FB -->|"time tracking is THEIR moat,
we deliberately skipped v1"| GAP
        ZOHO -->|"suite sprawl loses focus"| GAP
        WAVE -->|"broken 'free' promises
poison trust for everyone"| GAP
        NINJA -->|"self-hosters exist but
want it managed"| GAP
        GAP --> US
    end

• Wave taught the trust lesson. Their "free accounting" got repriced and tier-narrowed over the years — and every freelancer who got squeezed remembers. That's why our free tier isn't marketing copy: it's 10 invoice actions a month, free for 10 years from account creation, written into the terms with a version number the user acknowledges. A free promise that's contractual is a moat made of other companies' broken promises.
• Zoho Invoice taught focus. A free tier inside a forty-five-app suite is a fine product and a confusing first-run. Our counter is a five-item simple navigation with everything else behind "Advanced tools" (you met that in Chapter 01 as progressive disclosure).
• Invoice Ninja taught that the self-host audience is real but small, and mostly wishes someone else would run it. They also validate open-core pricing patience.
• FreshBooks and Bonsai taught adjacency. Their moat for consultants is time-tracking → invoice in one flow. We looked at that, wrote "time capture" on the roadmap, and deliberately did not build it for v1 — adjacency is how products bloat to death in their second year. Revisit when users demand it (they haven't yet).
• QuickBooks taught humility about the real buyer. For micro- businesses, the accountant is the system of record. You don't beat the accountant; you export to the accountant — CSV, QuickBooks IIF, Tally XML for India. Our export formats are a feature list written by accountants, effectively.

Pricing is a promise, not a formula

Three tiers, decided before launch and unchanged since:

Two design rules we hold ourselves to:

1. The free tier is a real product, not a demo. No watermark ransom, no "export locked." If a freelancer never pays us, they still got paid themselves — that's the reputation the funnel runs on.
2. Generosity compounds. Founding codes give 6 months of Pro free — 100 seeded for early adopters, unlimited generated for testers. The founder console makes issuing them a ten-second task. Every code redeemed is a user who experienced the paid product and tells the truth about it afterward.

And the honest footnote the strategy doc keeps pinned: at the time of this writing, paid revenue is approximately zero, users number in the dozens, and one power user's bug reports have shaped the product more than any roadmap session. The machine is the story — this series documents the machine while it's small enough to see all of it.

What we refused to build

The list matters more than the feature list:

• Full accounting — double-entry ledger, chart of accounts, bank feeds. That's a different company's decade. Exports bridge us to the ones who already did it.
• Time and expense capture (v1) — the FreshBooks lesson in reverse: build your core wedge first; adjacent workflows when pulled.
• Inventory/manufacturing — different domain, different buyer.
• AP/AR automation for mid-market — sales-driven category, solo-dev poison.

The roadmap sequencing that falls out of this is one sentence: activation → getting paid → open segments → compliance moat → integrations. Every feature we've shipped since maps onto that order, and Chapter 12 shows how it played out in practice.

One codebase, two products

The structure that makes the economics work: the enterprise tax manager (our books) and FoxyInvoice (the freemium product) are the same codebase, deployed twice with different branding and config. The twin pays rent three ways — it's a real business validating the platform daily, it's the harshest test environment (our own money), and it means every improvement lands for both audiences at once. Architecture-wise it's one decision: multi-tenant from day one, with branding resolved per deployment. Chapter 03 shows the moving parts.

Recap. Pick a problem you genuinely have. Read competitors as free research, and find the wedge their resentments leave open. Price so the free tier is a promise you can keep — then keep it contractually. Refuse adjacency until users pull it. And if you can arrange to be your own most demanding customer, do; nothing keeps product thinking honest like sending your own invoices through your own software.

Next: Chapter 03 — Architecture: one codebase, two products — the boring-on-purpose stack, the domain model, and why Money is a value object that refuses to add dollars to euros.