[In production] Freelance project: ERP for a graduation events company

Context

The company has been organizing graduation events for over fifteen years, but the entire operation was spread across two WhatsApp numbers, Google Drive, spreadsheets and a lot of paper. Each event brings together dozens of students who pay their monthly fees over several months, with no fixed amount per installment. They sent receipts by WhatsApp and someone had to check and enter each one in the spreadsheet afterward.

That flow had several weak points: old receipts nobody could find, fake receipts slipping through, and the occasional forgetting to enter the value in the spreadsheet. I built a platform to bring the whole routine into a single place, reliably.

What the system does

At first, the focus was organizing the essentials: registration of events, students and classes, financial control for each event (what comes in and goes out), an entry screen shaped and used like a spreadsheet (the same way as before, but now inside the system), and access control per area. That alone changed the team's day to day, because it took important information out of scattered chats and out of spreadsheets only one person understood, and centralized everything in one place.

Over time, we added a storage module, which allowed attaching a receipt to every payment entry and organizing documents and photos per event. Every folder is generated inside the system, linked to the event and the graduation class, and can be shared through a secure and configurable link: you can control whether the recipient can create folders, upload files, or download the content as a ZIP.

Another weak point in the operation was the payment of extras, like graduation albums and photo access links. In most cases, someone had to travel to the student (or the other way around) just to use a card terminal. I built our own checkout page on a public link, which solved both sides: it gave the client more credibility and saved time and travel for the company.

The biggest change: automated payments

Before, the student paid on their own, sent the receipt with their name and class on WhatsApp, and someone checked it and marked it off in the spreadsheet. Today, for every collective event, the system generates a public link to a kind of student portal. The student accesses it, finds their own name, enters a private access code, and pays through Pix, following the company rule of "paying whatever amount per month". The system records the payment on its own, updates the remaining balance, and sends the receipt by email automatically.

The portal also has an event info tab, with the day of the invitation photoshoot and instructions, party and gathering dates, and the attached contract for quick reference, among other things. That already cuts down a good part of the questions that came through WhatsApp, and keeps the same information available to every student at the same time.

The payment itself is done through Pix, with the code generated by the system and automatic confirmation through the Sicredi API.

In practice, all of this removed almost all of the manual work that took up an employee's time, and solved two long-standing problems. With the Pix API integrated directly with the bank, only actually confirmed payments enter the system. No more fake receipts, no bad intent slipping through, no receipts getting lost later.

An important decision was to not require signup or login on the public side. The intent was that the student could pay without creating an account and without remembering a password, just with a name and a code. Less friction and more ease, plus a privacy gain that did not exist before: the full spreadsheet used to circulate in the class group chat, and everyone could see how much each person had paid. Now each student only sees their own balance.

The work that does not show on screen

The payments side was where I had to be most careful. When a system starts dealing with money, it cannot get it wrong: it cannot lose a payment or record it twice, even when the bank takes a while to confirm or when two actions happen at the same time. A good part of the effort went into those invisible details: making sure every charge had a well-defined state, that a repeated confirmation did not create a duplicate entry, and that the system checked in with the bank periodically to reconcile itself when a notification got lost along the way.

I also spent time reviewing security carefully: who has access to which area, how to protect each student's data and the files, what gets recorded in logs. It is not the flashiest part of the project, but on something that is live and moves money, it is what gives peace of mind to keep working and improving it.

Shipping and keeping it running

The system is in production today. One full class is already paying through this more automated model, and two more are coming in now. Feedback so far has been positive, praising the transparency and ease, which was exactly what we were aiming for.

I am the one keeping the system up, and that brought a kind of learning that only shows up after the launch. I have already had to solve real production situations, like swapping the bank integration certificate without interrupting the service. Shipping is only the beginning. Keeping a system stable, especially one dealing with payments, is a continuous responsibility, different in nature from the work of building it.

What I learned

Digitalizing a small business only works if people actually use the system day to day. Every time the tool forced the user to step out and do something elsewhere, they ended up going back to the spreadsheet. That is why what made the biggest difference was keeping everything in one place, simple enough to become the default of the routine.

Shipping is only the beginning. The real improvements came after the first uses, once new ideas showed up seeing the system running in the real world.