The problem
The client ran the whole applicant process on paper and in Excel. As the organization grew, that stopped scaling, and every step depended on him doing it by hand.
He did not want to learn a new kind of interface. So I started with him: how he thinks, which tools he already trusts, and how long each task takes him. The real problem was the structure of the workflow.
The system had to adapt to him.
Before
- Paper forms
- An Excel file
- Every step by hand
After
- Applicants with a full status history
- Match lists
- Email templates and a send log
- Admin and volunteer roles
- An activity log
- Dutch and English
What I decided
The system exists so the client can run the whole applicant process without paper and Excel, and so it can grow with the organization. Every decision below starts from how the client already worked.
Tables that work like his spreadsheet
He already trusted his Excel file and did not want to learn a new kind of interface. So every list is an Excel-style table, and the main screen looked familiar on the first day.
A filter on every table
Matching people means narrowing a long list by status, city, interests and age. Search, filters and column choice sit on every table, so finding one applicant among a hundred takes seconds.
Built to grow: volunteers and English
Volunteer accounts were built alongside the admin’s, for when the organization grows. Each role is scoped: volunteers work with applicants, match lists and emails, while only admins manage accounts and read the activity log. The English version is part of the same plan, so the whole interface switches between Dutch and English.
He still writes every email
Automation could have sent the emails. He wanted to write each one himself to keep it personal, so templates give him a starting point and a send log keeps track of what went out.
Every action confirms itself
A short notification follows nearly every save, send and change, so he never has to wonder whether it worked.
Under the hood
- 3.1Privacy and data integrity are in the schema from day one, because they are very hard to add later.
- 3.2A slow page turned out to be an N+1 query problem. Eager loading fixed it.
- 3.3Pagination instead of endless lists, for server cost and for what the client expects to see.
- 3.4Forms are protected against SQL injection and CSRF, and file uploads are validated.
- 3.5Realistic test data across every status and ten years of dates surfaced problems a small dataset hides.
- 3.6The data model was designed from scratch, with role-based access for admins and volunteers.
How we worked
I don’t speak Dutch, so every client meeting was the two of us from the team: me and a Dutch-speaking teammate who translated. Meetings were kept small and short, on a fixed rhythm. When the client withdrew several earlier requests halfway through, I checked with our tutor and kept building the parts we had agreed on.
What I learned
- 5.1I never spoke Dutch with the client. My part was turning his expectations, translated by a teammate, into what the team built.
- 5.2Broad plans kept the team calm when the client changed his mind.
- 5.3AI-written code I did not understand only looked like progress. I moved to explicit instructions, tests and human-written sources.
- 5.4Trial and error taught me that version control is necessary.
