Nyuk.in Invoice Generator — a project by Ahsan Mahmood
Invoice generation and management application with modern UI
An invoice is a document, not a screen.
That sentence decides most of what this tool is. A screen can reflow, adapt to a phone and be regenerated whenever somebody opens it. A document gets emailed, printed, filed, and opened a year later by an accountant who was not there when it was made, and by then the application that produced it is irrelevant.
So the PDF is the product.
Everything else exists to make the document correct before it leaves. Line items have to break across pages in a way a reader follows rather than wherever the renderer ran out of room. Totals have to land where somebody's eye expects them. The text has to stay selectable, so a number can be copied rather than retyped, which is the difference between a real PDF and a picture of a web page saved with the wrong extension.
Around the document sit the parts that make it a tool rather than a template.
Clients are managed, and payments are tracked against what was sent. That pairing is the actual job. Generating paperwork is the easy half, and the half that takes the time is knowing which invoice went to whom and whether the money ever arrived.
The build is React on the front with Laravel behind it and MySQL underneath.
That split follows the same reasoning as the document. Invoices, clients and payments have hard relationships between them: a payment belongs to an invoice, an invoice belongs to a client, and a total is a fact derived from line items rather than a number stored beside them. A relational database enforces those, so a bad write fails instead of being recorded and discovered at reconciliation.
The record describes this as a second version, built to a supplied design.
That is a different job from a first attempt and it is worth naming as one. The layout was decided before the work started, so the work was making somebody else's decisions real, including the ones that only become difficult when an invoice with fourteen line items and a long client address has to fit inside a layout drawn with three.
There is a caveat about the address, and it belongs on the page.
The registered address is https://nyuk.in and the apex answered three of five checks from this machine. The www form answered every time. That is not the same as a site being down and it is not the same as a site being fine, so the link quoted here is the www one and the measurement is recorded rather than smoothed away. A reader who follows a link and gets nothing concludes the product is dead, and being specific costs one sentence.
There is a quieter reason a billing tool is worth building carefully.
An invoice is the document a business is judged by before anyone has met it. It arrives in an inbox, it carries a number somebody has to agree with, and if it looks careless the conversation that follows is about the invoice rather than about the work. Software that produces that document is doing reputational work whether or not it was designed to.
What it cost is scope.
This is a focused tool rather than an accounting package. It does not do books, tax, or the rest of what a business eventually needs, and the tools that do are large, expensive and staffed. Being the thing that makes a correct invoice and remembers who owes what is a smaller claim, and it is one this can actually make.
What it does, and what that costs to build
- Invoice generation
- PDF export
- Client management
- Payment tracking
Built with
- React
- Laravel
- TypeScript
- MySQL
Worth knowing
- invoice
- billing
- business
- finance
Who built the Nyuk.in invoice generator?
Ahsan Mahmood built it, and it is at www.nyuk.in. One person wrote the React interface, the Laravel application behind it and the PDF generation in between. The record describes a second version built to a supplied design rather than a first attempt, which is a different job: the layout was decided elsewhere and the work was making it real, including the parts of a design that only reveal their difficulty once a real invoice has to fit inside them.
Why is a PDF the hard part of an invoice tool?
Because an invoice is a document rather than a screen. It has to survive being emailed, printed, filed and read a year later by somebody's accountant, which means the output cannot be a picture of a web page. Line items have to break across pages sensibly, totals have to land where a reader expects them, and the text has to stay selectable so the numbers can be copied. Getting that right is most of the work.
What does it track besides generating the document?
Clients and payments. An invoice on its own is a file; what makes the tool useful is knowing which client it went to and whether the money arrived, because chasing an unpaid invoice is the actual job and generating the paperwork is the easy half. The record lists client management and payment tracking beside the generation and the export, and those four together are what separates this from a template with a form on it.
Is the address reliable?
Use the www form. The apex answered three of five checks from this machine and the www subdomain answered every time, which is a difference worth knowing before somebody follows a link and concludes the product is gone. That measurement is recorded rather than smoothed over, because a link that works most of the time is a specific kind of problem and describing it as working would be inaccurate in a way a reader finds out for themselves.
Does it work on iPhone?
It opens in any browser, an iPhone's included, because it is a web application and there is nothing to install. There is no iOS release: no Apple Developer account exists here and nothing I build has shipped to the App Store. For a tool whose output is a PDF that gets emailed, a browser is the right shape anyway, since the document matters more than the application that produced it.
https://aoneahsan.com/projects/com.aoneahsan.invoiceapp