Designing the MVP Database for My Placement Portal with Django

While building my Placement Portal, I reached a point where I had to stop adding features and answer a more important question:

What is the smallest version of this product that still delivers value?

Instead of trying to build every feature at once, I decided to define a clear Minimum Viable Product (MVP).

The goal is to build a working recruitment workflow before expanding the platform.

Defining the MVP

For the first release, I limited the portal to four essential capabilities:

• Companies can create job postings.
• Students can browse and apply for eligible jobs.
• Companies can review submitted applications.
• Students can upload a resume for each application.

Everything else can be built on top of these core workflows.

Designing the Database

With the MVP finalized, I started designing the relational models in Django.

The first set of models includes:

• Company
• Job Post
• Course
• Batch

These models form the foundation of the recruitment workflow.

Organizing Students by Batch

Every student belongs to a batch.

A batch is linked to a specific course and contains:

• Course
• Start Year
• End Year

For example:

B.Tech Computer Science – 2026–2030

Instead of allowing administrators to manually enter batch names, I generate a unique batch name by combining:

• Course Name
• Start Year
• End Year

This creates consistent and predictable batch identifiers across the system.

Company Profiles

Only users with the Company role can create company profiles.

Each company profile stores recruitment-related information such as:

• Company Website
• HR Email
• HR Contact Number

This separates authentication data from business information while keeping the system modular.

Job Posting Workflow

Once a company profile exists, recruiters can publish job opportunities.

Each job post contains information such as:

• Job Title
• Rich Text Job Description
• Compensation (CTC)
• Eligible Batches

Instead of making every job visible to every student, eligibility is determined by the selected batches.

This keeps the recruitment process relevant for both students and recruiters.

Batch-Based Eligibility

One design decision I particularly liked was using Batch as the bridge between students and job posts.

When a recruiter publishes a job, they simply select the eligible batches.

A student will only see the job if their batch matches one of the eligible batches.

This approach keeps the filtering logic simple while making it easy to support campus-specific hiring requirements.

Choosing Django's on_delete Behavior

Another decision involved selecting the appropriate on_delete strategy for model relationships.

Django provides several options, including:

• CASCADE
• PROTECT
• RESTRICT
• SET_NULL

During the MVP phase, I decided to use CASCADE for most relationships.

The reason is practical rather than architectural.

While the database schema is still evolving, CASCADE makes it easier to modify or rebuild models without manually cleaning dependent records.

As the project matures, I may replace some relationships with stricter deletion rules where preserving historical data becomes more important.

Tracking Record History

Every model also includes:

• created_at
• updated_at

These timestamps help answer simple but important questions:

• When was this record created?
• When was it last modified?

Audit information like this becomes increasingly valuable as the application grows.

Improving the Django Admin

Alongside the models, I also started improving the Django Admin interface.

For the MVP, I focused on:

• Custom admin forms
• Better list displays
• Easier data management

Although these improvements are small, they significantly improve the administrator's experience while testing and managing the application.

What's Next?

With the core database structure in place, the next milestone is implementing:

• Student Profiles
• Job Applications
• Resume Uploads
• Company Dashboard

Every feature from this point forward will build upon the relational models designed during this phase.

Final Thoughts

One lesson I've learned while building this Placement Portal is that a well-designed database is more valuable than quickly adding features.

A strong data model makes future development easier, keeps business logic simple, and allows the application to scale without constant redesign.

I'm documenting every major architectural decision while building this Placement Portal in public.