Leading a Team of Interns From ERD to Deployment: Lessons From PNPKI Tracker

A few months ago, I was handed a challenge I hadn't done before — lead three interns from Cor Jesus College through the full development lifecycle of a real, production-bound system. No shortcuts, no hand-holding past what was necessary. From planning the ERD to deploying the app on a live server, we did it together. Today, PNPKI Tracker is up, running, and actively being used.

This is the story of how we built it — and what I learned about leading a team, teaching Git to people who've never used it, and shipping software as a group for the first time.

Starting With Structure

Before a single line of code was written, I made sure the team understood the problem we were solving. PNPKI Tracker is a Laravel-based tracking system built for the provincial government — specifically designed to monitor the status of PKI certificate applications, from initial submission all the way through to approval. It needed to be reliable, well-structured, and maintainable by people who weren't necessarily going to be around forever.

ERD and System Design First

I gathered the team and we whiteboarded the entire data model together. I didn't just hand them a finished ERD — I walked them through the thinking process:

• What are the core entities?
• What are the relationships between them?
• Where do we expect the data to grow?

It was slow at first. But making them reason through the design meant they understood why the database looked the way it did — not just how to use it.

Defining the Scope Together

We mapped out the system's modules as a team before assigning tasks. This gave everyone a mental picture of the whole app, even if they'd only be building one part of it. That context matters when you're debugging someone else's code at 10pm.

Agile With Interns

I introduced Agile not as a buzzword but as a practical way to avoid chaos. For a small team building a real government system on a deadline, structure is everything.

Sprints and Planning Sessions

We ran short sprints — typically one to two weeks — with a planning session at the start of each one. I kept it simple:

1. Review what was done last sprint
2. Identify blockers
3. Assign tasks for the next sprint based on priority

The interns adapted quickly. Having a clear sprint goal gave them something concrete to work toward instead of an overwhelming backlog.

Daily Standups (Sort Of)

We didn't do formal daily standups — but I made it a habit to check in with each intern at least once a day. A quick message or a short call: what are you working on, what's blocking you? That alone caught a lot of issues before they turned into wasted days.

Teaching Git Like It Matters

Most interns come in knowing Git exists. Very few know how to use it properly on a real project. This was one of the most important things I taught them — and one of the most rewarding.

Branching Strategy

I introduced a simple branching model:

• main — production-ready code only
• develop — integration branch for ongoing work
• Feature branches — one branch per feature or fix, named clearly (e.g., feature/application-tracker, fix/submission-status)

No one pushed directly to main. Ever.

Pull Requests and Code Review

Every feature went through a pull request. I reviewed each one — not just for bugs, but as a teaching tool. Comments on PRs became mini lessons:

"Why did you use a raw query here instead of Eloquent?"

"This logic belongs in a service class, not the controller."

"Good job keeping this method small — that's exactly right."

It slowed things down slightly, but the quality of their code improved sprint over sprint.

Issues as Tasks

We tracked all work through GitHub Issues. Every task, bug, and feature request lived there. It taught them to think in discrete, describable units of work — a skill that will serve them long after this internship.

Building With Laravel

Choosing Laravel for this project was a no-brainer. Its built-in tools — Eloquent ORM, migrations, form requests, and blade templating — let the interns focus on learning application logic instead of fighting boilerplate.

I structured the codebase the way I'd want to inherit it:

• Models for every entity, with relationships clearly defined
• Form Requests for all input validation
• Service classes for business logic, keeping controllers thin
• Migrations versioned alongside the codebase so database changes were always tracked

For interns touching a real codebase for the first time, Laravel's conventions gave them guardrails without being restrictive.

From Local to Live

Getting the app running locally is one thing. Shipping it to a real server that real government users depend on is another.

Server Deployment

I handled the initial server setup and walked them through it — explaining each step as I went. We covered:

• SSH access and server navigation
• Environment configuration (.env, secrets management)
• Setting up the web server and database on the VPS
• Running migrations in production (carefully)

By the end, they understood that deployment isn't magic — it's just a series of deliberate, ordered steps.

Release Tags on Git

I introduced Git release tags as a way to mark stable versions of the app. Every time we pushed a production-ready build, we tagged it — v1.0.0, v1.1.0, and so on. It gave the team a sense of milestone and made it easy to roll back if something went wrong.

Tagging releases also made the interns feel the weight of shipping. It's not just a commit — it's a version of the product that real users will depend on.

The Moment It Went Live

The day PNPKI Tracker went live was quieter than I expected. No big celebration — just a final deployment, a quick smoke test, and then users started logging in. But for the interns, I could tell it meant something. They built a real system. It was being used by real people inside a provincial government office.

That's not something you get from a university project.

What I Learned About Leading

Leading interns taught me things about my own craft that I hadn't noticed before.

• You don't fully understand something until you teach it. Explaining Git branching to someone who's never used it forced me to articulate things I had always done on autopilot.
• Patience is a technical skill. Watching someone struggle with a concept you find obvious is hard. But jumping in too fast robs them of the learning.
• Code review is culture-setting. How you review code sets the standard for how the team thinks about quality.
• Ownership matters. The interns cared more about features they designed themselves. Giving them real responsibility — not just ticket work — made a difference.

What the Interns Walked Away With

By the time the project wrapped, the three interns from Cor Jesus College had hands-on experience with:

• Database design and ERD modeling
• Agile sprint workflows
• Git branching, pull requests, and code review
• Full-stack Laravel development on a real production codebase
• Server deployment and release management

That's a resume-worthy stack of experience — and I'm genuinely proud of what they shipped.

Closing Thoughts

PNPKI Tracker didn't just get built — it got built the right way, by a small team that learned together. If you're ever in a position to lead junior developers or interns, take it seriously. The system you ship matters, but the developers you help grow matter just as much.