I keep a catalogue of what students built in their first year. Not a highlights reel. The actual list from the public testimonials page: holiday games, quiz applications, a campus app, an AI travel planner, a music-band web page, a word-guessing game. The range is the part that tells you something a curriculum document can’t.
A curriculum tells you which subjects run in which semester. The project list tells you what students did with the tools they’d been given, when the brief was theirs to set.
Why the product is the evidence
Here’s the frame I keep returning to.
In 1980, Seymour Papert published Mindstorms: Children, Computers, and Powerful Ideas, the book in which he introduced what he called constructionism. His claim was that people build new knowledge particularly well when they’re actively constructing something shareable, something that others can see, use, or interrogate. The argument was precise: you can describe a system without being able to build one, but building a functioning system requires understanding it well enough to make it actually work. The product is evidence of the learning in a way that a description of the same learning isn’t.
That’s the frame I use when I read the project catalogue.
What Semester 1 and Semester 2 set up
Year 1 runs in two semesters of 24 credits each.
Semester 1 covers front-end web development, alongside other subjects. Students write and ship code from the first week. DOJO, the daily coding practice system, starts in Semester 1 and runs throughout the year: six days a week, belt progression across Java, C++, JavaScript, and Python. Six belt levels per language, each earned by writing working code rather than describing how code should work.
Semester 2 adds back-end web development and practical databases. By Semester 2’s end, students have the full web stack. A front end that runs in the browser, a back end that handles application logic, and a real database connected to both. That’s the design. The project list is what it produced.
The games
Several students built games.
Mukilan Palanichamy built Snowbound Strife, a holiday game. Divyam Desai built Tetris. Aaditya Kaushik built QuizDrive, a quiz-driven driving game in which correct answers advance the player’s car. Shaaz Jiwani built Boxes, a combined Sudoku-and-Crossword application.
A working game isn’t a soft project. It needs a state machine to track what’s happening at each point, a rendering loop to update the screen correctly, and real-time event handling for player input. Students who build working games in Year 1 have understood these patterns through application, not through description.
The choice of what to build is also informative. Aaditya built a quiz game structured as a driving simulation because that’s what he wanted to make. When the brief is open and a student pursues something they’re genuinely interested in, that’s a harder signal to produce by going through the motions than a completed assignment with a defined answer.
The applications
Other students built web applications and tools.
Aeroh Hardik Tailor built BitBloom in the MERN stack: MongoDB, Express, React, and Node. BitBloom is maintained as a public open-source project. That means it has to remain functional after submission, not only at the point of grading. Abhinandan Gupta built a music-band web application. Parul Chauhan built a word-guessing game. Shivang Gautam built CampusKart, a campus-oriented application, and an AI Travel Planner, both in Year 1.
The MERN stack across several of these projects isn’t coincidental. MongoDB, Express, React, Node is a production-standard combination across a significant share of the product engineering roles that students interview for by Year 4. A student who’s built a working MERN application in Year 1 has worked with the full stack in a form a senior engineer can inspect directly.
The Capstone Challenge
The Capstone Challenge is a 6-week build.
Six weeks is long enough to make planning choices visible in the product. A student who starts writing code immediately and leaves no time for debugging ships something that doesn’t quite work. A student who scopes the problem early, designs the database schema before writing the first endpoint, and reserves time for fixing what the previous weeks broke, tends to ship something that does. The 6-week format doesn’t guarantee the second outcome. It does create the conditions in which the difference between those two approaches shows up in what gets submitted.
Lokeswara Reddy Muthumula built IntraQuiz for the Capstone: a MERN-based quiz application produced over six weeks. The brief had no preset answer, and the evaluation was by someone who didn’t design the prompt. The MERN choice reflects Year 1 directly: by Semester 2’s end, that’s the stack students know well enough to use for an open-ended build.
The 6-week format and the external evaluation structure are what separate a Capstone Challenge from a regular course assignment. An assignment asks a student to demonstrate understanding of a defined subject. A Capstone asks a student to produce something that holds up when someone external interrogates it. That’s a different kind of accountability.
What the range shows
The list has games, open-source tools, a campus app, quiz applications, and a travel planner. That range wasn’t planned by a curriculum committee.
Papert’s constructionism offers a reading here. When the brief is open, what students choose to build is evidence of two things simultaneously: what they understood well enough to attempt, and what they genuinely cared about making. Both signals are harder to fake than a completed assignment, because neither can be produced without the learning actually having happened. Snowbound Strife and QuizDrive exist because Mukilan and Aaditya chose to make them. That’s the constructionist argument made concrete.
What this catalogue doesn’t tell you
I want to be honest about the limits.
The project list doesn’t tell you whether each project was maintained, extended, or became professionally relevant for the student who built it. It doesn’t claim anything about placement outcomes or employment figures. Those belong to a separate part of the programme record, attributed to the graduating batch as of March 2026, not to Year 1 builds. The list is what it is: named, documented projects on the public testimonials page at kalvium.com/reviews/, built by named students in Year 1.
What it does show is that the Semester 1-2 full-stack structure, combined with an open Capstone brief, produces real software across a range of project types. That’s the design claim. The projects are what the design produced.
For the argument on why full-stack development starts in Year 1 rather than later, full-stack development in the first year makes the case directly. For the design reasoning behind starting Capstone-style work in Semester 2 rather than Year 4, why capstone projects start in Semester 2, not Year 4 covers it in detail. For the year-by-year arc of what students build from Semester 1 through the Final Capstone in Semester 8, what a Kalvium student builds in four years has the full picture.
Arvind is Head of Programme Design and Delivery at Kalvium. He writes about the cognitive science of learning and how it shows up in the design of a live programme, grounded in named research and honest about where the evidence is still being worked out. Read more from Arvind or browse the B.Tech category.