Papers: The invisible evolution
One notion I have heard people complain about is that Papers is essentially the same thing it was in its first iteration, just a little more polished.
UI-wise? I am sympathetic to that notion.
Yet, so much goes on under the hood. While we deliberately try to make sure the frontend experience remains familiar(including the iconic purple theme and icon) the architecture behind Papers has gone through major overhauls almost every exam season.
Here are a few fun incidents I love reminiscing about:
Storage shenanigans and deployment woes
One of the things that has changed the most is where we papers itself(pun intended).
For the longest time, we were on Vercel, with the PDFs of papers stored on Cloudinary. But as Papers grew, we started facing problems scaling this setup. Cloudinary gave us only 25 free credits per month, which simply couldn't sustain Papers, even during its relatively early stages.
We saw this coming and tried various mitigations over several exam seasons. Cloudinary had a referral programme where you could refer people and receive additional credits, and you could also publicly endorse Cloudinary for an increased credit limit.
We tried all of this and managed to reach what IIRC was the absolute limit of 75 credits. We even created two accounts and tried round-robin between these.
Yet, by last Gravitas, even that wasn't enough.
As demand kept increasing, we finally made an effort to switch to UploadThing. It seemed perfect: use the 2 GB of storage available on one account without any egress fees, and switch to another account when needed.
Except we realised a little too late that round-robining accounts like this might go against their ToS.
So, after all these trials and errors, we finally made the switch to Google Cloud Storage(CORS).
GCP cost money, yes(around ₹500 a month) but we haven't had a storage-related headache ever since, so it has absolutely been worth it.
The bigger issue, however, was Vercel.
We regularly hit its limits in the middle of exams. A few of our accounts were even restricted unless we paid because of continued limit violations.
Eventually, we bit the bullet and switched to AWS Amplify, which came with its own share of setup problems.
At first, the cost wasn't terrible: < ₹1,000/month. Not ideal, but sustainable.
Then one day, after an impressively good exam season...
WHAT? A ₹7.2K BILL?
AWS stopped serving the website just before exams. Funny enough, I was on vacation at the time.
We immediately went into panic mode.
We switched back to Vercel, investigated AWS to figure out what had caused such a massive bill, and pooled money together to salvage the AWS account.
We tried working with Vercel again, but it was annoying — and repeatedly using multiple accounts to serve the same website could very well have violated their ToS too.
We needed a solution, and we needed it FAST.
Fortunately, we came across AWS's programme for open-source projects:
AWS Cloud Credits for Open Source Projects
Papers, with its contribution-friendly approach and FOSS licence, was a pretty good fit.
We honestly calculated our expenses and submitted a request.
Before the next exam season, it was accepted!
Those credits have been sustaining Papers for months now.
Upload and approval pipeline
This is another part of Papers that has changed drastically since its conception.
Our initial pipeline was extremely simple: every uploaded paper would be sent to an email address. We would then manually add the appropriate tags before putting it into the production database.
Even in those early days, Papers was open to contributions from everyone, but clearly this pipeline had to change as the project grew.
Compare that to the architecture of our latest pipeline:
View the latest Papers pipeline architecture diagram
Today, we upload a paper to a cloud storage provider, put its URL into MongoDB, read the paper, automatically detect its tags using Gemini, and then place the processed data into another collection.
The thing a user sees — upload a paper and eventually find it on Papers — is basically the same.
Everything underneath it is completely different.
There are many more stories like these throughout the evolution of Papers.
The frontend has barely changed, but the backend has undergone massive changes that might never be obvious to its users.
And that's kind of the point.
All of those invisible changes are what quietly keep Papers running as one of the most useful PYQ resources at VIT.
Postscript: What AI changes about programming
My field of programming is changing drastically.
Ever since the advent of cheap agentic coding, people have increasingly started pushing code without necessarily reviewing every part of it themselves. Instead, you can give an AI a goal:
Convert this Figma design into a fully functioning website.
Or:
Make something that can do X.
And, honestly, AI can now produce surprisingly complete software from requirements like these in a very short amount of time.
If I gave a sufficiently capable coding agent enough tokens and asked it to recreate papers.codechefvit.com so that it looked and behaved almost exactly the same, could it do it?
Yeah, probably.
But as we saw above, Papers itself barely changed while the way it did the same things changed constantly.
The problem was rarely just:
How do I build this feature?
It was:
Cloudinary isn't scaling anymore. Do we optimise around it, abuse free tiers, move to another provider, or finally start paying for infrastructure?
It was:
Vercel isn't working for us anymore. Do we work around its limitations or move the entire application?
It was:
Our AWS bill suddenly exploded. Why? How do we keep the service alive right now, and how do we prevent this from happening again?
AI, at its current capabilities, can definitely create what you ask it to create.
But figuring out what to do when the naive solution encounters reality; and making calls like whether to change the hosting platform or try to make the existing one work; is, in my experience, still very much in your hands.