The original description
« I run a sports club. Each member has a record with contact details, a category (junior, adult, family) and the expiry date of their medical certificate. Dues are annual and I need to know at all times who is up to date. I organise events — training sessions, tournaments, the annual general meeting — that members sign up for. I want to see how many members are up to date, how much has been collected this season, and what events are coming. »
The plan validated before generation
Before writing a single line, Blueprint Maker turns this description into a plan you validate. For AssoRegistre, the proposed plan fits on one screen: four entities — Member, Dues payment, Event, Sign-up — and their links: a dues payment belongs to a member, a sign-up ties a member to an event.
The statuses inferred from the text also appear in the plan: a dues payment goes through pending, collected, waived; an event through upcoming, finished, cancelled. The three requested indicators (members up to date, amount collected this season, upcoming events) are spelled out. If something is missing or superfluous, you fix it here — what gets built is what was announced.
- Entities: Member, Dues payment, Event, Sign-up
- Relations: dues payment → member; sign-up → member; sign-up → event
- Statuses: pending / collected / waived; upcoming / finished / cancelled
- Indicators: members up to date, amount collected this season, upcoming events
Navigation: one section per entity
The generated application opens on a clean sidebar: Dashboard, Members, Dues, Events, Sign-ups. Each section leads to a list — not a spreadsheet, a real application list: a search field at the top, columns sortable in one click, pagination, and a counter telling you how many records match the current filter.
The member list shows the name, category, medical certificate expiry and the state of the current year's dues. A status filter and a date-range filter sit alongside the search. Those filters live in the page address: the view showing members whose dues are still pending can be bookmarked, or sent to the treasurer in a message — they open exactly what you were looking at.
The deadline banner: what has to be dealt with this week
This is the single most useful piece for a club, and it is placed automatically as soon as an entity carries a due date. Above the list, the application shows a banner summarising the situation in one line: how many medical certificates have expired, how many fall due today, and how many fall within the next seven days.
Below it, the five nearest deadlines are listed by name, sorted by date, each with a button that opens the record directly. If there are more, the banner says so. A record whose status marks it as settled drops out of the banner on its own: you only see what is left to do.
In practice: opening the application before a committee meeting shows at a glance the certificates to renew and the dues still pending — with nothing sorted, nothing filtered and nothing worked out in your head.
The member record, with its history
Clicking a member opens their record: contact details, category, certificate expiry. Below comes the part that changes everything compared to a spreadsheet: the dues history of THIS member, as a dated table — last season's payment collected in September, this season's still pending — along with the list of their sign-ups to past and upcoming events.
That linkage is not cosmetic: it comes from the generated relational database. Correcting an address corrects it everywhere, and the attendance count shown on an event follows from the sign-ups, nothing is hand-copied.
Events as a calendar rather than a list
Events can be shown as a calendar rather than a list, with day, week and month views. That is the natural reading of a club season: you see the tournament weekend three weeks ahead, and the annual general meeting on its date.
The sign-up form is short because the structure does the work: the member is picked from a dropdown (no name retyped by hand, so no duplicates), the event likewise, the date is pre-filled. On save, the sign-up list, the member record and the dashboard all reflect the entry — every screen reads the same database.
The dashboard: the pitch's numbers, computed on the database
The dashboard carries exactly the indicators requested in the description: how many members are up to date with their dues, the amount collected this season, the upcoming events with their sign-up counts, and a breakdown of members by category.
These numbers are queries on the database, not manual entries: every recorded payment updates them. Every list also exports to CSV — and the export carries exactly the rows on screen, filter included, with the count written on the button itself. Enough to prepare the attendance list for the annual general meeting, or hand a statement to the treasurer.
What the application does not do, and it is better to know beforehand
AssoRegistre keeps the register: who is a member, who is up to date, who is coming to what. It does not collect money: no online payment, no direct debit, no bank reconciliation is generated. The amount of a dues payment is entered once the money has been collected elsewhere.
Nor does it issue donation tax receipts or any statutory document. And it displays deadlines, it does not send them: the banner flags what is late and what is coming whenever the screen is opened, with no automatic email or text message to the member. These are pieces a developer can add — the code exports — but they do not come out of the generation.
Demo data: judging on full screens
AssoRegistre arrives filled: several months of simulated activity, plausibly named members spread across the three categories, dues at every stage, past and upcoming events with their sign-ups — including, deliberately, a few expired certificates and a few pending payments, so you can see the deadline banner at work.
That's a deliberate choice: you don't judge a management tool on empty tables. The demo data is then cleared to make room for the real thing. The application lives at its dedicated URL, and its complete source code exports (ZIP or GitHub push), standard Next.js + Prisma.