Turnos Parcelas
Billing and scheduling software running in production for a real business.
- Year
- 2025 — present
- Role
- Sole engineer — product, backend, front end, infrastructure
- Stack
- Python PostgreSQL Neon Railway Vue
Problem
A plot-management business was running shift scheduling and invoicing on spreadsheets and WhatsApp. Invoices were rebuilt by hand every month, numbering drifted, and nobody could answer "what did this client owe us in March?" without an archaeology session.
Approach
I modelled the domain properly first — issuers, clients, concepts, invoice series — and made the invoice number a database-guaranteed sequence rather than an application convention. The stack stays deliberately small: a Postgres database on Neon with a branch per git branch, so every feature gets a throwaway copy of production-shaped data, and a deploy pipeline on Railway that promotes only what passed against that branch.
Outcome
Monthly invoicing went from a full afternoon of manual work to a few clicks. The system has been running unattended in production since 2026, including a multi-email client notification flow and a PDF invoice layout that survives the printer.
Why the boring parts mattered
The interesting engineering in a billing system is not the billing. It is making sure that two people pressing “create invoice” at the same second cannot produce the same invoice number, that a deleted client does not orphan three years of accounting history, and that the PDF still fits on one page when a client has fourteen line items.
Database branching as a safety net
Every git branch gets its own Neon branch seeded from production shape. That turned “I am scared to touch the invoice numbering” into “I ran the migration against a real copy and the numbers came out right”. It is the single change that most improved how fast I could ship.
Replace this section with the specific numbers you are comfortable sharing — invoices issued, clients served, time saved. Concrete beats adjectives.