Case study · Club management
Members, sports and management, in six connected services.
From May to October 2026 we built a social and sports club's website, member area, chat, sports competitions, dashboards and tournament site. When the old sports portal moved into the new website, its links, QR codes and the club TV kept working.
- Client
- A Brazilian social and sports clubSports and leisure · Name withheld
- Period
- Since May 2026
- Status
- LiveHosted and run by us
- Result
- 35redirect rules that send each old sports-portal address to its new pageMeasuredServer configuration · October 31, 2026
A standalone portal, with addresses already in use.
Members book courts and picnic pavilions, pay invoices and show a card at the gate. The sports department runs competitions with referees and team managers, and management tracks delinquency, cash flow and gate access. Members, invoices, bookings and access records live in the club system, a third-party product with its own API.
The first pieces each had their own address, and the sports portal stood alone. When the new club website was ready, the portal's addresses were already in links, in QR codes and on the club TV, which shows the week's games. Switching the portal off would have broken all of them.
Connected services, and a move done page by page.
We built the club's new website, with a member area on the club system's API. Members book courts, fields and picnic pavilions, open the member card with a code for the gate and see their invoices, classes and pool medical clearance. A self-service chat sits on every page, and the same member service answers on WhatsApp through the platform's API. One hour before a court booking, a WhatsApp message or an email asks the member to confirm it.
On October 4, the sports pages moved into the new website: 35 redirect rules send each old address to its equivalent page. The old portal's engine still runs internally, writing the competition data and emailing the referees' schedules.
We also run it all: each service isolated with read-only code, automatic blocking after repeated failed logins, a health check after every server restart and a monthly check of versions against known vulnerabilities.
Built in stages, May to October 2026.
Each service went live on its own date, and the old addresses kept working after the move.
- 01
May 2026
Tournament site
Registration, games, standings, documents and news for the club's regional futsal tournament, with a back office for the organizers.
- 02
June 2026
Sports portal and dashboard
A portal for the club's internal competitions, with a referee area, and a dashboard for management, behind a login.
- 03
August 2026
Self-service chat
Members sign in with their club password, which is never stored, and get their card and invoice details; staff take over when needed.
- 04
September 2026
New club website
Website and member area on the club system's API: a temporary address on September 2, the official one on September 29.
- 05
October 4, 2026
Old portal folded in
The sports pages moved into the new website, with page-by-page redirects, and the old engine kept running internally.
Stack
- Next.js
- FastAPI
- Flask
- PostgreSQL
- SQLite
- Club system API
- WhatsApp Cloud API
- nginx
- systemd
- fail2ban
Read from the server configuration.
Every number below was read from the server configuration on October 31, 2026. They describe how the platform runs: what is in production, how often data is refreshed and how long backups are kept.
From the server configuration
35
redirect rules that send each old sports-portal address to its new page
MeasuredServer configuration · October 31, 2026
6
services in production: website, API, sports engine, chat, dashboard and tournament site
MeasuredServer configuration · October 31, 2026
30 min
between dashboard refreshes of delinquency and cash flow; access data refreshes every hour and member data every night
MeasuredServer configuration · October 31, 2026
14 days
of daily backups kept, plus the one from the 1st of each month for 6 months
MeasuredServer configuration · October 31, 2026
No usage figures here: members, bookings and games are the club's numbers, not ours to publish.
What we kept running, and what we do not control.
Limits
Members, invoices and bookings come from the club system, a third-party product. The platform can only show what its API provides, and member data is copied from it once a night, at 12:15 AM Brasília time.
We did not rewrite the old sports engine. It still runs internally, behind the new pages, so the platform carries two generations of code, and both need maintenance.
What we learned
The pages can move without rewriting the engine. Instead of redoing everything at once, the sports pages moved into the new website while the engine that already worked kept running behind them, and each old address got a redirect to its new page.
A dashboard does not have to ask the source every time. Management's pages read a local copy, refreshed every 30 minutes or every hour, so they open quickly without querying the club system on each view.
Other projects we built.
2 h 42 min
for 300 invoices, about 32 seconds each
MeasuredExecution logs · May 8, 2026Read the case studyMay to June 2026 · Invoice automation
300 invoices posted into the ERP in 2 h 42 min
A system migration left a backlog of outgoing invoices. Robots attached to the team's logged-in browser posted each one and checked it against its total.
21 of 22
weeks with the report delivered, June to October 2026
MeasuredExecution logs · June to October 2026Read the case studySince May 29, 2026 · Scheduled reports
A weekly report of contracts about to expire
Every Monday, a robot runs on its own: it signs in to the ERP, finds the supplier contracts ending within 15 days and emails the report.
156-274 s
per contract with 2 to 6 items, in validation
MeasuredValidation logs · July 9 to 14, 2026Read the case studyJuly 2026 onward · ERP integration
A contract robot, and an orchestrator so robots can share one login
A robot posts each new contract from the client's internal platform into the ERP. An orchestrator gives the shared ERP login to one robot at a time.
8
modules live, from sales to financial BI
MeasuredClient portal · October 31, 2026Read the case studySince June 2026 · Manufacturing operations
An eight-module operations suite for a food manufacturer
Sales, accounting, finance, production, maintenance, fleet, HR and financial BI modules, built from June to October 2026. Each module has its own database, and payables are read from the ERP the company already uses.
30 days
of nightly backups kept, each one verified automatically after it runs
MeasuredServer configuration · October 31, 2026Read the case studySince October 4, 2026 · Financial control
Financial control for a notary office, where nothing is deleted
Every payable and receivable goes in as a provision, an entry made before it is due, and is then settled in full or in part. Corrections and cancellations are logged with a reason, every change records who made it and when, and the database is backed up and verified every night.
Free 30-minute assessment
Tell us what the systemhas to do.
In 30 minutes we map what the software has to do and tell you what it would cost to build.