Abhishek Roka
Abhishek Roka

Building a Placement Portal: The Real Challenge Isn't Coding, It's Solving Domain Problems

When I started building my Placement Portal, the product looked deceptively simple.

The initial idea was straightforward:

It sounds like a few database tables, some APIs, and a couple of frontend pages.

And technically, that's where it starts.

But after spending weeks actually building the product, I've realized something much more important:

The difficult part isn't always writing the code.

The difficult part is discovering what the system actually needs to solve.

Every time I implement a feature, I encounter another question.

What happens when a student deletes a resume after applying?

How should different users access the same platform?

What information should be preserved when an application is submitted?

How should users know that something important happened?

How much should the university be able to configure?

These aren't simply coding questions.

They're domain problems.

And those problems are starting to shape the architecture of my Placement Portal.

Here are the five core areas I'm focusing on as the product evolves.

1. User Management Is More Than Login

Initially, I thought about authentication as:

Login → Use Application → Logout

But real applications need much more than that.

A placement platform can have multiple types of users, each with different responsibilities and permissions.

User management therefore needs to consider things such as:

For example, if a user has multiple active sessions, invalidating one compromised session shouldn't necessarily require terminating every other session.

These requirements turn authentication into something much larger:

identity, security, and trust.

That's a very different problem from simply implementing a login endpoint.

2. Resume Parsing Is a Domain Problem

Resume parsing is another area where the complexity isn't immediately obvious.

At first, the requirement sounds simple:

Upload a PDF and extract the candidate's information.

But resumes don't follow one universal structure.

Different students use different:

Some resumes contain tables or multiple columns.

Others are extremely minimal.

Some emphasize projects.

Others focus on education or work experience.

This means resume parsing isn't simply a PDF-reading problem.

It's a document-understanding problem.

My current approach is intentionally simpler: extract the text first and allow the student to review and edit the result.

Longer term, I can imagine the system evolving toward:

One idea I'm particularly interested in is an ATS friendliness score.

It wouldn't replace recruiter judgment.

Instead, it could give students feedback about how their resume is structured before they submit an application.

3. Resume Management Is More Than File Storage

Another lesson I've learned is that resume management isn't simply:

Upload PDF → Store PDF.

The moment resumes become part of job applications, their lifecycle becomes important.

Consider a simple scenario.

A student uploads a resume and applies for a job.

Later, the student reaches the maximum number of allowed resumes and decides to delete the old one.

Should the previously submitted application lose access to that resume?

Obviously not.

This is one of the reasons I started thinking about snapshots for application data.

The application should preserve the relevant information from the point in time when the student applied rather than depending entirely on the student's current state.

Resume management also needs to answer questions such as:

These are domain rules.

They shouldn't simply be buried inside random pieces of application code.

4. Applications Need Context

An application record might initially look like a simple relationship:

Student → Job

But a real recruitment workflow needs much more context.

A recruiter may want to understand:

A typical workflow could contain states such as:

Applied
   ↓
Under Review
   ↓
Shortlisted
   ↓
Interview Scheduled
   ↓
Selected / Rejected

The exact workflow can evolve.

The important point is that an application isn't just a database row.

It's part of a recruitment process.

The system needs to represent that process clearly enough that both recruiters and students understand what is happening.

5. Notifications Make the Platform Proactive

Imagine having to open the Placement Portal every few hours just to find out whether something changed.

That's not a great user experience.

A useful platform should be able to communicate important events proactively.

For example:

This is also where the email architecture I've been working on starts becoming more important.

Email shouldn't remain a collection of unrelated functions scattered throughout the application.

As the number of communication scenarios grows, it starts looking more like a dedicated notification subsystem.

And eventually, that subsystem could support multiple communication channels.

The Interesting Part Is How These Systems Connect

The five areas aren't independent.

They influence each other.

For example:

User Management
       │
       ▼
    Student
       │
       ├──────► Resume Management
       │              │
       │              ▼
       │        Resume Parsing
       │              │
       ▼              ▼
    Application ◄──── Resume Data
       │
       ▼
   Notifications

A student has an account.

The student manages resumes.

A resume can be parsed.

The student uses a resume while applying for a job.

The application preserves important information.

Changes in the application trigger notifications.

Suddenly, what initially looked like five independent features starts looking like one connected system.

That's where software architecture becomes interesting.

I'm Not Just Building Pages Anymore

When I started this project, I was thinking in terms of:

Now I'm increasingly thinking in terms of:

That's a significant shift in how I approach the project.

I'm not just asking:

"How do I implement this feature?"

I'm starting to ask:

"What problem is this feature actually solving?"

And then:

"What other parts of the system does this problem affect?"

That second question is often where the interesting engineering decisions begin.

The Next Phase Is About Systems, Not Just Features

The next phase of my Placement Portal isn't simply about adding more pages.

It's about strengthening the systems underneath those pages.

The major areas I'm thinking about include:

Some of these are already implemented at a basic level.

Others are still being designed or planned.

And that's intentional.

I'm learning that a real product doesn't emerge from one giant architecture diagram created on day one.

It evolves as you discover the problems that actually matter.

Final Thoughts

The biggest lesson I've learned while building this Placement Portal is surprisingly simple:

Real-world software is rarely just CRUD.

CRUD is the starting point.

The real complexity comes from questions like:

Those questions are where domain problems appear.

And those domain problems are what ultimately shape the architecture.

So, I'm no longer measuring progress only by the number of features I've implemented.

I'm also measuring it by how many real-world problems I've discovered and how thoughtfully I'm solving them.

Because building software isn't just about writing code.

It's about understanding the world your software is supposed to operate in.

— Abhishek Roka