PayRadar: a late-payment radar for freelancers that never uploads an invoice

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle What I Built Freelancers rarely go broke from a lack of work. They go broke in week 7, when three invoices that were "Net 30" are still unpaid and rent is due. PayRadar is a local-first tool that tells a freelancer three things: Which open invoices will probably be paid late, and by how many days. Whether the next 8 weeks of expected cash-in cover their monthly costs, with gap weeks flagged. What to write to each client. It drafts a reminder whose tone matches the risk: a friendly nudge, a clear and polite note, or a firm one. The freelancer reviews it and copies it. Nothing is ever sent automatically. You drop in invoice PDFs or photos. A local vision model reads them, a tabular foundation model learns each client's payment habits from the freelancer's own history, and everything stays in a SQLite file on the laptop. Who would pay for it? The target is a solo freelancer or a tiny agency billing a handful of clients, especially one whose contracts or NDAs make uploading client invoices to a cloud SaaS uncomfortable. I think $19 to $29 a month is plausible, but that is a hypothesis. I have not tested it with a paying customer, so I am not claiming demand. The demo on the synthetic data below shows the product works. It does not show anyone wants to buy it yet. Demo payradar-640a.onrender.com The hosted copy runs in a lightweight demo mode with synthetic data and precomputed results. The free server has no GPU and no room for PyTorch, so it cannot run Gemma or TabPFN live. The real app runs entirely on your own machine. The first load can take about a minute because the free tier sleeps. Code dibyendu-coder / PayRadar PayRadar 📡 Local-first late-payment radar for freelancers. Drop in invoices, and it tells you which ones will be paid late, whether you will have a cash gap in the next 8 weeks, and drafts the right chaser email for each one. Built Oct 12-18, 2026 during Hacktoberfest Week 2 (Side Hustle Challenge). 🏆 Hackathon Window Note Event: Hacktoberfest Open-Source AI Challenge Week 2 (Side Hustle) Challenge Window: October 12 – October 18, 2026 Window Statement: This repository was created and completely built within the challenge window (Oct 12-18, 2026). Post-Deadline Commits None. (Any commit made after October 18, 2026 23:59 UTC will be documented here with justification). Note SYNTHETIC DATA NOTICE: All benchmark tables, model evaluation figures, demo documents, and client histories in this repository and application are 100% synthetically generated for demonstration and benchmarking purposes. No real personal, business, or financial customer data was… View on GitHub How I Built It Open pieces doing the real work Gemma 4 (gemma4:e2b) through Ollama reads invoice images and returns JSON constrained to a schema (client, amount, issue date, due date, terms). The same model drafts the chaser emails. TabPFN-3.5, run locally with the tabpfn package, predicts two things per open invoice: the probability of being paid more than 7 days late, and the expected days late. scikit-learn supplies the baselines I measured against. Streamlit + SQLite + PyMuPDF for the app, the store, and PDF-to-image conversion. The pipeline PDF or image goes to an image of at most 1024px. Gemma extracts the fields. The user reviews and edits them in a form, then confirms. Features are built per invoice: log amount, payment terms, issue month and weekday, client, project type, and the client's history (how many earlier invoices, their mean lateness, and how this amount compares to their median). TabPFN scores every open invoice. Scores are cached in SQLite so the UI never waits on the model. Expected pay date is the due date plus predicted days late. I sum expected cash-in per week for 8 weeks and compare it to monthly costs. The hardware constraint shaped the design. I built this on a laptop with an RTX 2050 (4 GB of VRAM) and 15.6 GB of RAM. So Gemma never runs inside a page request. Extraction and drafting are explicit button presses with a timeout and a template fallback, and results are saved. The default model is the small e2b, switchable with one environment variable. Measured results (all on synthetic data) The demo data is generated from a seed: about 400 invoices across 25 clients with deliberately different habits (always late, pays at month end, big invoices slower, one very reliable client). I split by time, not randomly, and client-history features only ever see invoices issued earlier. A test fails if a feature for invoice N can see invoice N or anything later. Extraction on 20 rendered invoices with known answers, using gemma4:e2b: all four fields (client, amount, issue date, due date) correct on 20 of 20, at about 19 seconds per document. These are clean synthetic documents. Real scans will do worse. Prediction, averaged over 3 expanding time windows (mean ± std): Model ROC-AUC Brier Delay MAE (days) Per-client mean 0.855 ± 0.035 0.128 ± 0.025 8.02 ± 0.32 HistGradientBoosting 0.863 ± 0.062 0.144 ± 0.058 8.66 ± 1.20 TabPFN-3.5-Fast 0.854 ± 0.055 0.122 ± 0.027 7.36 ± 0.97 TabPFN-3.5 0.844 ± 0.020 0.124 ± 0.025 7.28 ± 0.92 I want to be straight about what this says. TabPFN had the lowest delay error and a slightly better Brier score, and it needed no tuning. But the gaps are inside one standard deviation, and its ROC-AUC was the lowest of the four. On this data, where each client has a strong habit, a simple per-client average is a tough baseline. So the honest claim is "comparable accuracy with no feature tuning, and a modest edge on predicting how many days late", not "TabPFN wins". Full tables are in results/benchmark.md. Two bugs I am glad I caught : My first forecast put an overdue, still-unpaid invoice's expected pay date in the past, which made cash arrive before today. I clamped expected pay dates to today and marked those invoices "overdue, expected any day". My first chaser drafts told the client they had a "high-risk profile". That is exactly what you must never say to a customer. The prompt now bans any mention of risk, scores, or prediction, and a test fails if a draft contains those words. Why Does Open Innovation Matter? The product's whole pitch is that invoices are confidential. A client list with amounts and due dates is exactly what an NDA tells you not to upload. A closed vision API would have meant sending every invoice to someone else's server. With an open-weight model on Ollama, the document never leaves the laptop, and the privacy claim is something I can show in the code (the only network call in the extraction path is to localhost). Cost works the same way. There is no per-document price. At about 19 seconds per invoice on a 4 GB GPU laptop, a freelancer with a few dozen invoices a month pays nothing per page, so a low monthly price can still leave a margin. Open also meant I could adapt it to the hardware I actually had: swapping e2b for e4b is one variable, and if the TabPFN weights are unavailable the app falls back to scikit-learn instead of failing. A caveat I would rather say out loud: the TabPFN-3.5 weights are released for research and evaluation. Selling PayRadar as a commercial product would need a commercial license from Prior Labs. That is why the app has a fully permissive fallback path (gradient boosting and per-client averages) that works commercially. So the open story is strong for Gemma and for the architecture, and more conditional for TabPFN. A closed API would have been better at one thing: extraction from messy, low-quality photos. I have not tested that against real scans, so I do not claim a win there. My Agent Session My First User Prize Categories Best Use of Gemma: Gemma 4 (e2b) runs locally through Ollama for vision extraction and email drafting. Best Use of TabPFN: TabPFN-3.5, run locally, predicts late-payment risk and days late inside a cash-flow forecasting pipeline, benchmarked against baselines on time-split data. Best Use of Render: the hosted demo runs on Render in a lightweight mode.