InvoiceNudge is a small full-stack MVP built to help freelancers track unpaid invoices and see which payments are pending, overdue, or due soon.

The project was built as a rapid live-build prototype, using a Flask backend and a React frontend. The backend exposes a simple REST API for listing invoices, creating invoices, and marking invoices as paid. The frontend provides the user interface for adding invoices, viewing invoice status, and seeing reminder-style alerts when payments are due soon or overdue.

The app supports a simple invoice workflow: enter a client name, amount, and due date, then view the invoice inside a dashboard-style list. The frontend calculates whether an invoice is paid, pending, or overdue, and displays colour-coded badges so the status is easy to understand at a glance.

The reminder banner is one of the key pieces of the MVP. It checks the invoice list and shows how many invoices are overdue or due within the next three days. This gives the user a quick view of what needs attention, even though actual email or SMS reminders are not implemented yet.

This is not a production invoicing system. The backend currently stores invoices in memory, so data is lost when the server restarts. There is no authentication, no database, no payment integration, no invoice PDF generation, and no real reminder sending. The value of this project is as a focused full-stack prototype that proves the basic workflow quickly.

I built the Flask backend with endpoints for listing invoices, creating invoices, and marking invoices as paid.

I built the React frontend with separate components for the invoice form, invoice list, and reminder banner.

I implemented the client-side status logic for paid, pending, overdue, and due-soon invoices, along with the Tailwind-based interface and colour-coded status badges.

One of the main challenges was keeping the scope small enough for a rapid MVP. The goal was not to build a full accounting system, but to prove the core flow: create an invoice, view invoice status, detect overdue payments, and mark invoices as paid.

Another challenge was deciding what should be handled on the frontend versus the backend. For speed, the overdue and due-soon logic is calculated client-side in React, while the Flask backend stays minimal with simple invoice storage and status updates.

A major limitation is persistence. The backend uses an in-memory list rather than a database, so invoices disappear when the server restarts. That is fine for a prototype, but it would need SQLite, PostgreSQL, or another storage layer before becoming a usable product.

The product name also implies reminder automation, but the current implementation only shows reminder-style alerts. It does not yet send actual emails, SMS messages, or scheduled reminders.

This project reinforced how quickly a full-stack idea can be prototyped when the scope is clear.

I also learnt that even a small app needs proper boundaries before it becomes useful in real life. A demo can use in-memory storage, open CORS, and hardcoded localhost URLs, but a real product needs persistence, authentication, configuration, validation, and safer deployment settings.

The project also showed that the gap between “tracking reminders” and “sending reminders” is where the real product value begins. The current MVP proves the dashboard and status logic, but the next stage would be email automation, reminder schedules, and delivery logs.