Last month I built a recruitment portal from scratch learn the 20% of design thinking that actually works — request form, approval flow, candidate filtering with AI, the whole nine yards. Before I wrote a single line of code, I sat through fifteen hours of interviews with HR managers, hiring managers, and candidates who had just been rejected understand requirements the way stakeholders see them.
That is the part most articles about building products skip. They jump straight to the whiteboard sketch or the workshop exercise. Those are the easy parts. The hard part is being willing to throw away your first idea after you have heard the third interview say, “that is not actually how I do my job.”
This is the story of how I actually built that portal — the conversations I had before writing code, the assumptions I had to throw out, and the things that broke in the first week. The portal handles request forms, multi-level approval, job posting, candidate registration, AI-assisted filtering, interview scheduling, psychological tests, salary offers, MCU (medical check-up), and onboarding logistics. I will show what survived and what I deleted.
Listening to three different audiences
Recruitment has three constituencies and they want different things. If you design for one, you build something that annoys the other two.
HR managers I spoke with wanted three things: a single source of truth for open requisitions, an audit trail for every approval decision, and a way to stop being the bottleneck between hiring managers and finance. Their current workflow was a Google Form, a Slack DM, and a spreadsheet that one person maintained on Fridays.
Hiring managers wanted speed and quality. They wanted to see candidates ranked, not just listed. They wanted to schedule interviews without three email roundtrips. Most of all, they wanted AI to surface the candidates worth talking to so they could spend their interview hours on signal, not on triage.
Candidates — the ones I interviewed were people who had been rejected in the last 90 days. Their complaints were specific: no feedback after the interview, no idea why they were rejected, scheduling links that conflicted with their current job. Two of them had been asked to take a psychological test on a Friday evening and never heard back.
The artifact that survived this phase was a single empathy map with the three audiences as columns. It still sits on the wall next to my desk. I have thrown out more empathy maps than I have kept.
The problem I thought I was solving
Most problem statements are too vague. “How do we make recruitment faster?” is not a problem statement, it is a wish.
The problem statement I landed on after the listening phase was:
Hiring managers spend 60% of their interview time on candidates the AI could have filtered out, while strong candidates drop out because the scheduling loop takes two weeks.
That sentence did two things. It quantified the pain (60%, two weeks). It named the specific failure mode (scheduling loop causing drop-off). It did not propose a solution — that comes later.
I had three earlier versions of this statement. They all started with “build a portal that…” — those are solution statements, and I deleted them.
The long list, then the cut
I generated 23 feature ideas across the three audiences. Most of them were bad. The long list is supposed to be bad. The point is to write them down so you can cross them out in front of other people without forgetting them.
The features that made the cut into the MVP:
- Request form for hiring managers (replaces the Google Form + Slack DM combo)
- Multi-level approval workflow (HR manager -> department head -> finance, configurable per cost band)
- Public job posting page with candidate self-registration
- AI-assisted candidate filtering (resume parsing + scoring against the job description)
- Interview scheduling with calendar sync (Google Calendar + Microsoft 365)
- Psychological test integration (we used a third-party API, not built in-house)
- Salary offer workflow with templated letters
- MCU scheduling with a partner clinic network
- Onboarding checklist (laptop, tools, accounts, day-one schedule)
The features I cut from the MVP: a candidate chat bot (the conversations with candidates showed they prefer email), a referral program (legal said no until we have a formal policy), and a mobile app (the web portal tested well on mobile browsers).
The version I built knowing I would throw it away
Most recruitment projects fail at this step. Teams skip it because they think “we already know what an ATS looks like.” You do not know what yours should look like until you have watched three hiring managers try to use it.
I built a clickable Figma prototype in two days. Then I sat next to two hiring managers for ninety minutes each while they tried to approve a job request. The first manager tried to approve a request that was still pending finance sign-off. The second manager could not find the “reject” button because I had put it in a kebab menu.
Both of those bugs never made it to production. That is the prototype phase paying for itself.
The portal architecture that fell out of the prototype:
Request -> Approval Workflow -> Job Posting -> Candidate Registration -> AI Filter -> Recruiter Review -> Interview Scheduling -> Psychological Test -> Salary Offer -> MCU -> Onboarding
Each box is a separate microservice with its own database. They communicate through a message queue, not direct API calls. This was a deliberate choice — when the AI filter needs to be retrained, we do not want to touch the scheduling service.
What broke in the first week
The first week after launch was supposed to be polish. It was not. Three things broke:
The AI filter was overconfident. It scored candidates 0.92 and 0.05 with not much in between. The recruiter was getting a binary “yes/no” list, not a ranked list. I had to retrain with a calibration set and add a third tier (“review manually”). Lesson: binary classification is almost never the right output for a human-in-the-loop system.
The interview scheduling double-booked. Two interviewers were booked for the same slot because I had not enforced a per-recruiter concurrency lock at the database level. The lock had to be at the row level, not the application level, because the application was running on three pods.
The MCU partner clinic had a different holiday calendar. A candidate got scheduled for an MCU on a day the clinic was closed. We caught it because the candidate emailed us. The fix was a shared holiday calendar endpoint that both systems subscribe to.
The artifact that survived this phase was a “what broke” document. It is more useful than the launch announcement. Every team that touches the portal reads it during onboarding.
The five things that actually mattered
If I had to pick the five things from the whole process that actually mattered:
- Conversations with the three audiences before writing code, recorded and transcribed
- A problem statement that names the pain with a number
- A long list of ideas that gets cut in front of other people
- A clickable prototype that real users try before any code ships
- A break-log from the first week that the next team reads
Five things. The rest — the post-it walls, the workshop exercises, the consultant-led brainstorming sessions — I tried them all. They have their place, but they are not what ships a portal.
The takeaway
The whole process is a debugging loop, not a ceremony. It works when you treat it as a forcing function to talk to real users before you build anything, and to admit your assumptions were wrong after you have tested them.
The recruitment portal is now in production. Hiring managers spend about 40% of their interview time on AI-filtered candidates (down from the 60% they spent before). The scheduling loop dropped from two weeks to three days. Candidate drop-off is down, but I do not have a clean number yet — we are still collecting data.
If you are about to build a recruitment system — or any system with three constituencies — the cheapest thing you can do is sit through three conversations with the different users before you open your IDE. Everything else is downstream of those conversations.
Discover more from Susiloharjo
Subscribe to get the latest posts sent to your email.