When we sat down to design the capstone cadence at Kalvium, we had three constraints in the room.
We wanted students to graduate with the ability to actually build software. We wanted them to make mistakes early enough that the mistakes were useful. And we wanted a credible signal to companies that the student had done the work themselves.
Only one design satisfied all three. It looked nothing like the standard model.
What the standard model gets wrong
The default in Indian engineering programmes is to put the capstone in Year 4. Three months. One project. A final-semester demonstration that the student can pull a thing together before they walk into a placement interview.
Watch what happens in practice. The student gets to Year 4 with three years of theory and almost no shipping experience. They have three months to design, build, and present something that’s meant to convince a recruiter they’re ready. There isn’t time to fail and recover. There isn’t time to learn from the build. So they scramble for an idea online. Some copy from GitHub. Some pay someone to build it.
The project gets submitted. The marks get assigned. The learning doesn’t happen.
This isn’t the students’ failing. The design forced it. Three months of build time, against four years of habit pointing the other way, is not enough.
The constraint that broke the standard design
The constraint we kept coming back to was time-on-task.
How many hours of actual project work does it take to produce an engineer who can confidently ship software? Different studies put the number in different places. None of them put it under a thousand hours. Many put it closer to four thousand.
You cannot generate that many hours inside a final-year capstone. Even if a student does nothing else, the calendar doesn’t allow it.
The only way the math works is if the build starts in Year 1 and adds up across the next three. Which is what we designed.
The options we considered
Three alternatives were on the table.
One. Keep the final-year capstone but expand it. Make it a full year, not a semester. This is what some progressive programmes have done. It improves the design but doesn’t fix it. A one-year capstone is still a one-shot, and the three years before it are still mostly theory.
Two. Add a project requirement per semester, decoupled from the syllabus. Eight projects, one per semester, distinct from coursework. This generates the volume but loses the depth. Students treat them as assignments. Nothing compounds.
Three. Start a single capstone in Semester 2, treat every subsequent semester as continuation, and let the project evolve as the student learns more. One project, lived with for three and a half years. Every new skill the student picks up has an immediate home.
We picked option three. The build-up across years is the entire point.
What the protocol actually looks like
The Semester 2 capstone has a specific design.
Every student picks a real-world problem they care about, with a mentor’s help. Not an impressive-sounding problem. Not a problem someone else has already solved on GitHub. A problem the student can articulate, a solution they can defend, and a user they can name.
From day one, they use a real software development lifecycle. Planning. Design. Build. Test. Deploy. The same one a company would use, scaled down for a first-semester student.
GitHub for version control, from project commit one. Peer reviews on the code, from the second week. Daily progress tracking. Mentor checkpoints scheduled, not improvised. A standing rule that any code the student can’t explain, line by line, doesn’t count as theirs.
That last rule is the hardest one to enforce, and the most important. Plagiarism in a final-year project is hard to catch. Plagiarism in a project the student has been building for three years is much harder to fake. The continuous track record is the credibility signal.
What this changes about Years 2, 3, 4
The downstream effect is the part most people miss when they hear “capstone starts in Semester 2.”
In a standard programme, every new concept in Year 2 lives in a textbook until Year 4. The student has nowhere to put it. By the time the capstone arrives, half of what they learned in Year 2 has decayed.
In ours, every new concept gets a place to land the same semester. Learn about databases in Year 2? The capstone needs one. Learn about authentication in Year 3? The capstone needs that, too. Learn about cloud deployment? Deploy the capstone. The classroom and the build talk to each other every week.
The projects get harder as the students get better. Year 1 might ship a working task manager. Year 3 might ship a multi-tenant application with a real user base. Year 4 might ship something a company genuinely uses. The build doesn’t restart. It evolves.
By the time these students sit in a placement interview, they have a portfolio with three years of commit history on it. They can talk about specific design choices they made, specific bugs they fixed, specific things that broke in production. There is no scrambling for an idea, because the idea has been theirs since Semester 2.
What we’d change with hindsight
The first version of this protocol was looser than it should have been. We assumed students would naturally use version control, write decent commit messages, and document their design decisions. They didn’t, not at first.
In Cohort 2, we made the protocol explicit. A weekly commit cadence. A short design-decision log per sprint. A peer review rubric the student fills out for two classmates each fortnight. The signal jumped. The mentor sessions got sharper because the artifacts were there to talk about.
We’re still adjusting the mentor allocation. A first-year student needs more frequent, shorter check-ins. A third-year student needs longer, less frequent, deeper ones. The first version of the system didn’t differentiate. The current version does.
And we underestimated, in the first cohort, how much weight the company-facing portfolio carries. A continuous GitHub history with real reviews is a different artifact than a finished Year-4 capstone. Companies that hire from us notice. We’ve made the portfolio export a first-class output of the programme.
What this means if you’re choosing a programme
If you’re a 12th-grader (or a parent of one) trying to evaluate an engineering programme, capstone timing is a useful diagnostic question.
Ask when students start their first real project. Ask how long they work on it. Ask whether the same project continues across semesters, or whether each semester has a fresh one. Ask whether mentors are involved daily or only at the end.
The answers tell you whether the programme is designed around building, or designed around teaching with a build at the end.
Neither is wrong, exactly. The first will produce graduates who can build. The second will produce graduates who can pass exams.
At Kalvium, we picked the first. Semester 2 is when the build starts. The rest of the programme exists around it.