DEV Community

Cover image for I Got Tired of Bad Invoicing Tools So I Built My Own. Here's What Happened.
Ihthi Fahim
Ihthi Fahim

Posted on

I Got Tired of Bad Invoicing Tools So I Built My Own. Here's What Happened.

Every freelance developer I know has two things in common.
They can build almost anything. And they absolutely hate doing their invoicing.

I was no different. Four years into freelancing as a web developer, I had built e-commerce platforms, custom CMS systems, complex APIs for clients. But ask me to send an invoice without it turning into a 30-minute ordeal and I'd fall apart.

The tools were the problem. They were either too complicated, too expensive, or both. I tried Wave. I tried Zoho. I even went through a phase of tracking everything in a spreadsheet like some kind of financial archaeologist digging through my own transactions at year end.

None of it worked the way my brain worked.
So I did what any developer does when they can't find the right tool.

I built it myself.

Why Existing Tools Didn't Work For Me

Before I get into the build, I want to be specific about what frustrated me because I think a lot of freelance developers will relate.

Wave kept moving features behind a paywall. Every few months something I relied on would disappear from the free plan. Receipt scanning gone. Payment reminders gone. Bank feeds gone. It felt like the floor was slowly being pulled out from under me.

Zoho Invoice had the opposite problem. Too many features. I am a freelancer, not a finance department. I do not need a tool with seventeen menu options and a learning curve that requires me to watch tutorial videos just to send a basic invoice. Every time I logged in I felt like I was filing a tax return.

What I actually wanted was simple. I wanted to know who owed me money. I wanted to send clean professional invoices in multiple currencies because half my clients are not in Canada. I wanted to snap a photo of a receipt instead of manually typing in expenses. I wanted the tool to follow up on late invoices so I did not have to.
That was it. That was the whole list.

No tool did all of that cleanly without charging too much or overwhelming me with features I would never touch. So in the evenings after client work, I started building.

The Build

The stack was straightforward. Next.js for the frontend, because it is what I know and it is what made sense for a web app that needed to be fast and SEO-friendly. I will not go deep into the full architecture here but the core of it was not complicated the hard parts had nothing to do with the code.

The first working version took about three to four months of evenings and weekends. That sounds like a long time but honestly a lot of it was not writing code. It was making decisions.

What do I actually include? The temptation as a developer is to build everything. I had to fight constantly against scope creep. Every time I thought "oh it would be cool to add X" I had to ask myself whether I actually needed X as a freelancer or whether I just thought it would be fun to build. Most of the time it was the latter. I cut a lot of features that seemed interesting but would have made the product more complicated without making it more useful.

**Multi-currency **was harder than I expected. Sounds simple. It is not. Handling currency conversion, making sure the books stay clean regardless of what currency a payment comes in as, displaying the right amounts in the right places there were a lot of edge cases. I rebuilt that part of the system twice.

The PDF invoice generator broke constantly at first. Getting invoices to look genuinely professional across different PDF renderers, with proper formatting for different currencies and line items, took way longer than I budgeted for. There is nothing quite as humbling as a PDF that looks perfect in Chrome and completely wrong everywhere else.

Email infrastructure for payment reminders was its own project. Setting up automated reminders that actually land in inboxes reliably, handling the scheduling logic, making sure reminders stop going out when an invoice gets paid — I underestimated this badly. A few weeks of debugging later it worked properly.
The first time I used the finished version to send a real invoice to a real client, the whole thing took about four minutes. That was the moment I knew it was worth it.

The Part I Did Not Expect

I shared a early version with a few other freelancers I knew. Not developers — a designer, a copywriter, a photographer. Just to get honest feedback from people who would tell me if it was confusing.
The feedback was almost identical across all of them.
"This is so much simpler than what I was using."

That surprised me. I built it for myself, for the way a developer thinks about financial tools. No accounting jargon. No double-entry bookkeeping UI. Just clean, obvious screens that tell you what you need to know. Apparently that resonated beyond just developers.
A few of them asked if they could keep using it. I said yes. Then a few more. Then people I did not know started signing up through word of mouth.

That is when Zapledger went from a personal tool to an actual product.

Where It Is Now

Zapledger is live at zapledger.com. It has a free plan that includes five invoices a month and unlimited clients, no credit card required. The Pro plan is $15 a month and includes everything — unlimited invoices, automated payment reminders, AI receipt scanning, multi-currency invoicing, financial reporting, the works.

There is also a launch offer running right now. Pro for $1 a month for the first three months with code LAUNCH1. If you are a freelancer reading this and you have been putting off sorting out your invoicing, that is probably the lowest friction entry point you will ever get.

I built this because I was frustrated with what existed. I wanted accounting software that thought like a developer and worked for people who do not have an accounting degree. I think we got there.

What I Learned From Building It

A few things stuck with me from this whole process that I think are worth sharing for anyone building a SaaS tool on the side.

Your own frustration is a valid north star. The clearest product decisions I made were the ones where I asked "would this have annoyed me when I was using Wave?" If yes, fix it. If not, it probably does not matter as much as you think.

Simple is genuinely hard to build. Removing complexity from a user interface is more work than adding features. Every screen in Zapledger went through multiple versions trying to get to the simplest possible way to present the information. That process never really ends.

Build for one person first. I built this for me. A freelance developer who hates accounting admin and wants to get invoicing done fast. That specificity is what made it feel right to other people in similar situations. If I had tried to build for everyone from day one it would have become another Zoho.

If you are a freelance developer dealing with the same invoicing headaches I was, I would genuinely love for you to try it. And if you have built something similar or thought about it, I would love to hear what your experience was in the comments.
The repo is not public (yet) but happy to talk architecture if anyone is curious.

Zapledger is at zapledger.com. Free plan available, no credit card needed. Pro for $1/month for 3 months with code LAUNCH1.

Top comments (0)