A Brand Ready Website, And An Invoicing System That Checks Its Own Arithmetic
Purafall came to us for a website that matched the quality of what they sell, and stayed for an internal invoicing system that reads vendor invoices automatically and builds every client invoice from one fixed, branded template.
A water filtration company.
The Challenge
Purafall needed a website that read as a premium brand, not a template with their logo dropped in, the kind of site that makes a first time visitor trust the product before they have read a single line of copy.
Behind the scenes, invoicing ran the way it does at most small and mid sized businesses: a vendor bill typed in by hand, a client invoice built by copying last month's and retyping the parts that changed. Workable, but exactly the kind of repetitive task where a small mistake slips through unnoticed.
What We Built
The website was designed and built around Purafall's own brand, live today at purafall.com.
The invoicing system handles two related but distinct jobs behind one login: reading a vendor invoice (money going out), either from an uploaded file an LLM reads or typed in by hand, checked for arithmetic before anything is trusted, then synced to a Notion database, and building client invoices (money coming in) from one fixed, branded Dragmo Labs style template, generating a real PDF to download or email directly.
Authentication is a deliberately small, hand rolled, database backed session layer rather than a drop in library's token based login, specifically so an admin deactivating a staff account takes effect on that person's very next request, not whenever a token happens to expire.
Every invoice is frozen at the moment it is issued: the exact template state it was built from is snapshotted into the invoice's own record, so a later template edit can never silently rewrite a document a client has already relied on.
Verified, Not Just Claimed
Every fix, found and verified on the live system
A model reading a vendor invoice can misread a digit or a decimal point, and a wrong number that looks plausible is the expensive kind of mistake, not the obvious kind.
Structured extraction from a scanned or photographed invoice is read, not calculated. Nothing about the extraction step itself confirms the line items, tax, and total actually add up to what is printed on the document.
Every extracted invoice is re-verified in code before it is trusted: line totals, tax, and the grand total are recomputed independently and checked against what the model read. A mismatch is flagged for a human to look at rather than silently filed.
Built as a dedicated verification step separate from extraction itself, so the check runs the same way regardless of which model produced the reading.
An admin deactivating a staff account needs to take effect immediately, not whenever that person's login token happens to expire.
The standard drop-in authentication library's credential login is built around signed tokens that stay valid on their own terms once issued, which is a known limitation for exactly this kind of immediate revocation, not a configuration that can be turned off.
A deliberately small session layer was written directly against the database instead: one sessions table, an opaque token hashed at rest, and a short list of functions to create, check, and revoke a session. Deactivating an account now means the very next request from that browser fails.
The scope was kept intentionally narrow, exactly the functions this requirement needs, rather than adopting a general auth framework and fighting its defaults.
A client invoice template can change after an invoice built from it has already been sent, which would silently rewrite a document a client has already relied on.
A live template and a generated invoice are two different things with two different lifespans, and treating an issued invoice as 'still following the current template' means every future template edit reaches backward into documents that should never move again.
The moment an invoice is finalised, the exact template state it was built from is frozen into that invoice's own record, and the PDF is generated from that frozen snapshot, never from whatever the template happens to say today.
Checked by editing the live template after issuing an invoice and confirming the already-sent PDF and its record were unchanged.
“The invoicing system DragmoLabs built has taken the manual work out of our billing, and the website gives us the premium brand presence we wanted too.”