StatementPro converts PDF bank statements into clean CSV files. It supports 28 US banks, handles statements going back years, and today has paying customers who use it to import bank data into QuickBooks, Xero, Excel, and a dozen other tools.
It’s also the product that taught us most of what we now know about building focused SaaS. Here’s the full story.
The Problem We Noticed
The problem wasn’t abstract. One of our early consulting clients — a bookkeeping firm — had a staff member spending two to three hours per week manually re-entering transaction data from PDF bank statements into their accounting software. The bank’s portal didn’t offer CSV exports. The accounting software had no PDF import. The gap between those two systems was being bridged by a human copying numbers from one screen into another.
We looked for existing tools. There were a few — DocuClipper, Docparser, some enterprise document processing platforms — but they were either expensive, clunky, or required technical setup that a small bookkeeping firm couldn’t manage. The market had a gap at the “simple, affordable, just works” end.
That observation became the hypothesis: small accounting firms and individual bookkeepers will pay for a simple, reliable tool that converts PDF bank statements to CSV, if it’s priced reasonably and handles the major US banks.
Validating Before Building
Before writing any code, we built a landing page describing the product as if it already existed. Headline: “Convert PDF Bank Statements to CSV in Seconds.” A short feature list. A pricing table: $19/month for individuals, $49/month for firms. A waitlist form.
We then ran a small Google Ads campaign targeting “bank statement to CSV,” “convert bank statement to excel,” and variations. Total spend: $180 over two weeks.
Results: 23 signups, 3 of whom emailed asking when it would be ready. That was enough. The signal wasn’t overwhelming, but it was real — people were searching for this, landing on a page with a price, and signing up.
We also called four bookkeepers and asked them about their workflow. All four confirmed the pain. Two said they’d tried existing tools and abandoned them because the output was messy. That told us the bar to clear wasn’t high: reliable output from a clean interface would be better than what existed.
Scoping the MVP
The MVP hypothesis was narrow on purpose: one user type (individual bookkeeper or accountant), one core workflow (upload PDF → get CSV), one bank (Chase, since it had the most consistent PDF format).
Things we explicitly cut from the MVP:
- Multi-bank support beyond Chase
- A transaction history view
- Team/firm accounts
- API access
- Bulk upload
- Mobile optimization
The only questions the MVP needed to answer were: Can we reliably parse Chase PDFs? Will people pay $19/month for that? Everything else could wait.
We set a rule: nothing gets added to the MVP unless a real user explicitly asks for it and says they won’t use the product without it.
Technical Choices
StatementPro’s core technical challenge is PDF parsing — specifically, extracting structured transaction data from PDFs that were generated by bank statement systems, not designed for machine reading. Bank PDFs are inconsistent: different formatting, different column structures, different date formats, different ways of representing credits and debits.
Our approach:
Parser-per-bank, not a generic parser. Generic PDF-to-table extraction tools exist, but they produce inconsistent output that requires heavy post-processing. We built a dedicated parser for each bank, tuned to that bank’s specific PDF structure. More upfront work, but dramatically better output quality and easier to debug.
Python + Django backend. We reached for what we know. The PDF processing ecosystem in Python (pdfplumber, PyMuPDF) is mature and well-documented. Django gave us authentication, admin, and ORM with minimal setup.
Stripe for billing from day one. Not a PayPal “donate” button, not an invoicing system — Stripe subscriptions from the first paying customer. This forced us to build real subscription management early, which was the right call.
Simple deployment. Railway for hosting, Postgres for the database, S3 for statement storage. No Kubernetes, no microservices, no container orchestration. A boring stack that three people can maintain.
Launch and Early Growth
We launched with Chase support and emailed our 23 waitlist signups. Within a week, we had 7 paying customers. Within the first month, 12.
The most valuable thing that happened in month one wasn’t the revenue — it was the inbound requests. Within two weeks of launching, we had customers asking for Bank of America, Wells Fargo, and Citibank support. Each request was a vote for which parser to build next.
We added banks in order of request frequency. By month three, we supported eight banks. By month six, eighteen. Every new bank added meant existing customers referred it to colleagues at firms using that bank.
The referral loop was the most important growth mechanism: accountants talk to each other. One user at a large firm would become five users as they told colleagues. We didn’t invest heavily in paid acquisition until we understood this — when we did invest in ads, we targeted at the firm level (accounting firms with multiple bookkeepers) rather than individuals.
What We’d Do Differently
Launch with two banks, not one. Chase-only was genuinely limiting — several waitlist signups churned immediately because their clients used Bank of America. Two banks at launch would have retained more of those early customers. The extra two weeks to add Bank of America was worth it.
Add team accounts earlier. We waited until month four to build firm-level accounts (multiple users under one subscription). In hindsight, this was the feature that unlocked the referral loop we described above. Teams don’t want five separate subscriptions — they want one firm account. We left revenue on the table by waiting.
Charge more. $19/month for individuals was too low. Bookkeepers who were saving two hours a week would have paid $39 or $49 without hesitation. We raised prices after the first year and saw almost no churn. The lesson: price to the value you’re delivering, not to what feels “affordable.”
What It Taught Us
StatementPro confirmed a few things we now apply to every product we build:
Narrow is good. “Bank statement converter” is more defensible than “financial document processor.” The more specific your product’s job description, the easier it is to rank for the right keywords, convert the right customers, and build exactly what they need.
Validation before code is non-negotiable. Twenty-three waitlist signups and four phone calls saved us from building something nobody wanted. The time investment was four days. The risk it eliminated was months.
Boring infrastructure is a feature. StatementPro has never had a major outage. It has never needed an emergency architectural overhaul. The boring stack we chose in week one is still running in production. That stability is worth more than any technical cleverness.
We apply everything we learned building StatementPro — and the five products we’ve built since — to the client work we do at Webward. If you’re building a SaaS product and want a team that’s been through this process for real, let’s talk.