Sanjeev Srithevan

I am Sanjeev: How I Went From Picking Up Shrapnels to Picking Up Coding

2026-05-25T00:00:00+01:00

Yes, you're seeing a picture of me with a bunny as the cover image of this post 😄. His name is Mochi. He is very destructive and currently lives in Manchester. As we speak, he is probably trying to eat my friend's shoes or causing some other form of chaos.

He isn't actually mine. Mochi lives with one of my friends, who has two bunnies: Mochi and Poffin.

I don't have many photos of myself, nor do I really use social media. I'm a very private person. The few pictures I do have are usually of me standing in front of a Formula car, holding a bow and arrows, or hanging out with Mochi.

A Bit About Myself: Why Did I Spin Up a Personal Website?¶

At this stage in my career, and in life, everywhere I go, people ask for my socials and want to know a bit more about me. I will never be on social media, but I do have LinkedIn, which I share when people ask.

I needed a way to make myself publicly available, and I finally feel ready to do so. I feel that what I have to share can help a lot of people, or at least I hope it does. Over the years, I've received feedback from colleagues, friends, and even complete strangers about how my story, achievements, and advice have helped them. Some of them are doing really well in life now, partly because of that spark they got from me, combined with their own hard work and determination.

I thought a personal website would allow me to control the content and make myself publicly available in my own way. For example, I can share my photography work when people ask for my Instagram, which I don't have, after meeting me on road trips or seeing me out with my cameras. I can use it to network within my field, document my journey, and keep a diary of sorts where I can publish whatever I want in a format I'm happy with.

As you know by now, my name is Sanjeev. You can learn a bit more about me by exploring the home page.

I was born in Sri Lanka and arrived at London Heathrow Airport in 2011. I've now been in the UK for around 15 years. My family came to the UK after fleeing the Sri Lankan Civil War, specifically during its final stages. Like many others, we were looking for safety and the opportunity to build a new life. Looking back, it was a life-changing journey that shaped who I am today.

Sri Lankan Civil War / Life in Sri Lanka¶

I spent most of my childhood in Sri Lanka running into bunkers, hearing bombs drop, collecting shrapnel, and getting up to other interesting things that I won't share here, as that could be a separate post in itself.

I wasn't really in school until I came to the UK around Year 5 or 6, so when I was about 9 or 10 years old. The war disrupted education for many of us, and even when I did attend school in Sri Lanka, we would often end up being sent into bunkers anyway.

Not truly being in school was quite fun I think. To be honest, I wouldn't know any different, as we were never formally educated for much of that period.

Getting visas to come to the UK was a long process. Literally long, as the queues and waiting times were endless, and long from a paperwork perspective too. Thankfully, through a combination of hope, faith, and a bit of luck, we eventually got our visas after spending a year or two in another part of Sri Lanka where my people were not always particularly welcome at the time. There was a significant divide back then, and to some extent, there still is today.

Those years before coming to the UK were eye-opening. I had grown up in a heavily segregated environment where schools were often divided by language, ethnicity, and religion.

I ended up attending a Christian (or possibly Catholic) Tamil boys' school, I honestly can't remember which now. They were quite open to accepting anyone, provided you spoke Tamil. It was a strict school, and it taught me a lot of discipline, although the punishments could be brutal 🙃.

I spent my final years there before moving to the UK in 2011.

Coming to the UK¶

Coming to the UK was a privilege, and in many ways it was similar to how it was portrayed in some of the films I had watched in Sri Lanka. Back then, the military had significant control over what you could watch, and if you were caught with certain films, the consequences could be quite harsh.

The UK felt like a completely different world. The roads weren't bombed to pieces. There were no bombs dropping from the sky. Everywhere seemed clean compared to what I was used to. There was no shrapnel to collect, no soldiers carrying AK-47s, and people seemed to be living in peace. Most importantly, people seemed happy.

Then there was the whole debacle of living in Croydon, which was a life-changing experience in itself.

From the day we arrived in the UK, the one thing my parents, especially my mum, drilled into my head was the importance of education. If I didn't get 100%, I was apparently a failure.

Looking back, I think she was terrified that I might end up going down the wrong path. In her mind, that meant getting involved in gangs, selling drugs, getting kicked out of school, or ending up in prison.

I was a rebel, and to some extent, I still am. The difference is that I chose to go my own way in a positive sense.

I suppose I didn't quite fulfil my mum's dream of becoming a doctor or a lawyer 😆. To this day, she doesn't think typing away on a computer all day counts as a real job, so there's that.

That said, I don't think she worries about me anymore. I must be doing something right.

Skipping to the Nice Parts¶

Now, skipping past the wars, coming to the UK, life in Croydon (which was heaven for me compared to a war zone, regardless of what people think of Croydon, it's really not that bad, people; don't believe everything you see in the news), adapting to the culture, and integrating into the western world...

Let's skip ahead to how I ended up in the world of coding and software engineering, the very reason you're on this website.

Pilot¶

I always wanted to become a pilot and fly planes. Growing up in Sri Lanka, I was getting bombed by fighter jets, and seeing one in the sky was a big deal. The same went for drones.

As kids, we would sneak out to nearby military bases. Many of them were positioned in large open fields, making it possible to spot drones and, occasionally, fighter jets. Our parents hated this. Whenever we heard the sound of aircraft, we were supposed to be running into bunkers, not trying to get a better view of them.

I became fascinated with fighter jets and always dreamed of flying one myself. If I had told my parents that back then, they probably would have locked me in a bunker (there were different types, open and closed bunkers 😅). The irony was that those same fighter jets had caused immense suffering within our community.

My mum nearly died because of one. A bunker-buster bomb landed at her workplace. Thankfully, it failed to detonate, but it still collapsed the bunker she was sheltering in. The workers had to be dug out afterwards.

Becoming a pilot was an expensive career path in the UK back then and, for the most part, it still is today, although there are now some fully funded commercial airline pilot programmes available.

When I was in secondary school, however, you largely had to fund it yourself. Neither my family nor I had £100,000 lying around. Many aspiring pilots ended up remortgaging their homes or taking out significant loans to pay for flight training.

My parents are successful in business and are financially comfortable now. They could probably fund whatever my little brother wants to do with his life (assuming he can eventually get off TikTok for five minutes), but that simply wasn't an option for me back then.

So I switched my focus to the next area that had always fascinated me: technology.

The house we lived in while I was growing up in Sri Lanka didn't even have electricity. We fetched water from a well, our neighbour's cow provided milk, much of our food came from local farms, and we grew some of our own fruit and vegetables.

We rarely went into the city because it wasn't particularly safe. Technology wasn't really part of everyday life where we lived. The wealthier households had electricity, a television, and perhaps a landline telephone. For everyone else, life was much simpler.

Poking Around With Computers Like a Caveman Discovering Fire¶

It all started in primary school in the UK, where I got used to using computers, both laptops and desktops.
Google Translate was incredibly useful back then because I didn't know any English.
I learnt most of my English with the help of other kids at school who spoke Tamil and various other languages.
At first, I wasn't particularly fascinated by computers. I was far more excited about watching cartoons on TV, which was amazing considering we didn't even have a television in our house in Sri Lanka because we had no electricity. I did manage to watch some cartoons at our wealthy neighbour's house though, as they were quite fond of me.
At some point in Year 6, my class was taken to Whitgift School, a rather fancy private school with its own zoo and everything. We learnt Scratch there and built little games as a class. Looking back, there were only a handful of us who were genuinely excited about doing some form of programming, if you can even call it that, and I was definitely one of them.
What really got me excited wasn't Scratch itself. It was seeing one of the teachers remotely controlling all the computers in the classroom. You could see the mouse moving on its own, applications opening, windows changing, and all sorts of things happening across the machines. It completely blew my mind. Looking back, that's probably what sparked my interest in technology and computers more than building games in Scratch ever did.

How the Computer Science & Coding Journey Started¶

The pilot dream was shattered, so I put it in my backlog. I'm alive and well, and there are plenty of other things I can do in this great country.
Secondary school was a struggle, which could easily be another blog post or an entire book in itself. I'll spare you the details for now.

GCSEs¶

I picked Computer Science for my GCSEs, thanks largely to the influence of someone who is now one of my closest friends.
He's also a software engineer who is doing really well in his career. He loves Next.js and Vercel 50% of the time and hates them the other 50%, yet he'll never move away from them. He's also the sort of opinionated developer who hates everything and constantly threatens to build his own version of whatever he dislikes...
I think that's when I first truly came across Vercel. He recommended that I follow the Next.js documentation because, according to him, it was the best documentation he had ever seen. Given that he hates and nitpicks absolutely everything, him genuinely liking something was a strong endorsement. To be fair, the Vercel and Next.js documentation is undeniably excellent. Stripe might take second place on that list.
Fast forward a few years and I came away with some decent GCSE grades.
I was coding in Python and building all sorts of command-line applications, from ATM simulators to whatever random idea I found interesting at the time.
I loved learning from Tech With Tim and Corey Schafer. I probably owe many of my early opportunities in technology to them.

A-Levels¶

I picked Computer Science at A-Level.
I was still coding in Python and started experimenting with Tkinter, Kivy, Selenium, and a few other technologies.
I also tried to learn Django and failed catastrophically. I was trying to learn to fly before I could even walk... That experience destroyed my confidence so badly that I started telling my friends I was going to become a marine biologist instead 🤣. The only thing I knew about marine biology at the time was that they studied fish or something. Yes, I was in a very low place after Django defeated me.
Looking back, it's quite funny. These days I specialise in the Python ecosystem, particularly Python, Flask, Django, and Wagtail. I've spent enough time with them now that I'd comfortably consider myself an expert.
A-Levels during COVID were interesting. It wasn't too bad for me because I was incredibly introverted during my secondary school years, so staying indoors wasn't exactly a challenge. That said, my eyesight definitely got worse.

University of Portsmouth (Yes, It's Not Cambridge, Oxford, Stanford, or Harvard)¶

If you're looking for a Cambridge, Oxford, Stanford, Harvard, or MIT graduate, that's not me. To be honest, I don't think my way of working, mentality, or attitude would have been the right fit for those universities. They work for some people; they probably wouldn't have worked for me.
My only connection to those highly regarded universities is that I've interviewed and reviewed applications from graduates of Cambridge, Oxford, and other prestigious institutions while hiring for software engineering roles. Some applications were fantastic, while others looked almost identical, lacking evidence of passion, curiosity, side projects, or genuine effort. The strongest candidates I've seen came from all sorts of backgrounds, top universities, other universities, and some who never went to university at all. The people we hired have gone on to do exceptionally well.
One thing I really like about software engineering is that, for the most part, the barriers to entry are relatively low. If you're willing to learn, build things, and put in the effort, there are opportunities available.
I chose the Software Engineering course at the University of Portsmouth rather than Computer Science. The Software Engineering course had less theory, more hands on projects, and modules focused on JavaScript and web development, which I desperately wanted to learn after being defeated by Django.
I spent a lot of time working with JavaScript, HTML, CSS, and a bit of Express.js. It was mostly vanilla web development, which gave me a solid understanding of how things actually worked under the hood. Looking back, that depth helped me later when working with larger frameworks.
For the first time, I genuinely enjoyed education. The Software Engineering course was highly practical, which suited me perfectly. Building projects and being assessed on them felt far more rewarding than traditional exams. University was a breath of fresh air after school.
Because I was constantly going above and beyond the course requirements, I found much of the university content relatively straightforward. I spent most of my time coding, building projects, experimenting with new technologies, and generally having fun.
And yes, I finally learnt Django and defeated the Django demon. Thanks, Corey Schafer.

Work Experience During University¶

I secured an internship at JPMorgan Chase & Co. To say I learnt a lot there would be an understatement. Around that time, opportunities seemed to be appearing everywhere.
Alongside that, I worked part-time in various roles for the university, including marketing, campaigns, student engagement, and a variety of other odd jobs.
In many ways, those work experiences developed me more than the university course itself, because I was slowly breaking out of my introverted shell. When you're giving talks, leading campus tours, answering questions from prospective students and parents, keeping groups of 15-20 people engaged, making jokes, and doing it all dozens of times a day, it can be exhausting as an introvert. Over time, though, you learn how to manage the situation mentally and become more comfortable in your own skin.
I deliberately kept taking on jobs that required me to be out in public and interacting with people. I wanted to overcome my anxieties and fears around speaking to strangers and putting myself out there.
For a period, I worked in a sales-focused role at the university. Had I been a permanent member of staff, the bonus I generated on one particular day would have exceeded two weeks' worth of salary. At that point, I was getting very close to defeating my anxious self.
Surprisingly, I started to love sales as my confidence grew. I wasn't doing it for the money; I was doing it for the experience. By then, I was already working as a junior software engineer and earning a decent salary. I actually took annual leave from my engineering job so I could continue doing the sales role because I enjoyed it that much.
Most of the time, I was selling graduation-related items and clothing. We each had a sales counter tracking our performance, and I regularly ended up near the top of the leaderboard.
My fastest and biggest sale happened within about five seconds of meeting a customer. I sold over £500 worth of items almost instantly, and by pure coincidence, my manager, had taught me most of what I knew about sales, was standing right there watching. He was completely shocked. By that point, I had a carefully refined script running in my head. I was so practised that I almost felt like a robot. I wasn't even being myself anymore; I was operating in some strange trance-like flow state.
Looking back, these seemingly unrelated odd jobs helped build my confidence more than anything else. They shaped me into a person I never thought I could become. As valuable as my internship at JPMorgan and my role at the ONS have been, I don't think either would have given me that same personal growth. I genuinely don't think I'd be where I am today without those experiences.

Internships & Industrial Placements¶

If you're interested in the details, have a look at my home page and scroll through my experience section.
During university, I received three industrial placement offers: one from the Office for National Statistics (ONS), Civil Service, and two from startups.
At the time, the ONS offered the lowest salary at around £22-23k. These days, placement students and interns can earn around £27-30k at the ONS, which is pretty competitive.
One of the startups offered around £24k.
Another startup reached out to me directly. They didn't normally take placement students, but they liked my LinkedIn profile and, more importantly, my Django projects. They offered mentorship and a salary of up to £55k, which was a huge amount of money to me at the time, and still is to many people today.
In the end, I received offers from both the ONS and the startup offering £55k. The startup was incredibly tempting.
Despite that, I chose the lowest paying role and signed with the ONS. After doing my research and speaking to people who worked there, I felt it would give me the best opportunity to grow as an engineer. Looking back, it was one of the best career decisions I've ever made.
I know people who accepted offers from some of the other companies I was considering, and many of them have gone on to have successful careers too. However, for me personally, choosing growth over salary at that stage of my career paid off enormously.
Money isn't everything, especially when you're early in your career and have the opportunity to trade short term earnings for long-term growth, learning, and experience.

Graduation (I Didn't Go to It)¶

I decided not to attend my graduation ceremony. At the time, I saw it as a waste of time. By then, I was constantly working, learning, and building things. There were periods where I'd spend days coding, experimenting with neural networks, and generally being obsessed with technology, sometimes 2-3 days without no sleep (was working on a project related to ML/ NN).
Instead, during graduation week, I worked on running the graduation events. It was paid work, but like many of the jobs I took during university, I did it more for the experience than the money. I was still focused on evolving beyond my introverted personality.
Having worked behind the scenes from start to finish, I wasn't particularly fond of the heat, the long days, or the overall process. And yes, I know I'm from Sri Lanka, but 40°C in Sri Lanka feels better than 30°C in the UK with humidity.
Rather than attending my own graduation, I spent that time running a successful community session at work for more than 60 engineers. It was either a JavaScript or Python session, I genuinely can't remember now, as I ran quite a few of both. We covered frameworks, industry trends, template repositories, and other topics. Looking back, those community sessions became an important part of my career development.
I'm not against celebrating achievements or attending your well earned graduation. It just wasn't really my thing, and I had other priorities that week.
What I did enjoy was seeing the excitement on the faces of students and their families. Helping people collect their graduation attire, showing them how to wear it properly, guiding them through the event, and helping reduce some of their anxiety was genuinely rewarding.
The amount of work that goes on behind the scenes to run an event of that scale was also an incredible learning experience. We were often starting work at 7 a.m., five days a week throughout the graduation period.
Me attending a graduation ceremony like that? BIG NO.
Me helping run the graduation ceremony and making sure everyone else had one of the best days of their lives? HUGE YES.

My Career Trajectory So Far¶

If you'd like more detail, have a look at my CV or scroll through the home page.
Since joining the ONS, I've tried to take every opportunity available to me.
My career progression has been relatively rapid, which came with its own challenges. The progression framework wasn't really designed for someone moving through it at the pace I was.
It didn't start with big projects or leadership opportunities. It started the same way it does for most engineers: picking up tickets, writing code, asking lots of questions, and dealing with imposter syndrome.
While my technical skills grew significantly, I don't think technical ability alone explains my progression. What helped most were the non-technical skills, saying yes to opportunities, volunteering for things outside my comfort zone, and getting involved wherever I could.
Where there is stress, there is growth and evolution.
You don't grow in comfort.
You either get worse or get better; you don't stay the same.
Many of the people who taught and mentored me early in my career were incredibly supportive. They often commented on the level of drive and curiosity I brought to my work. While they hadn't seen many people approach things the way I did, I've since met and worked alongside plenty of highly motivated individuals who inspire me just as much.
People often asked me where my motivation came from. My answer was always the same: "You have to do your best work when you're the least motivated."
My flexi-hours balance ballooned. My annual leave entitlement effectively grew from around 25 days to over 65 days because I was apparently working too much. Personally, I didn't see it that way. I was learning, growing, and evolving. I was genuinely happy.
This was also where all those seemingly unrelated odd jobs started to pay dividends.
Within a few months, I was building proof-of-concepts, taking initiative, creating technical and non-technical presentations, pitching ideas to stakeholders, securing buy-in, and helping turn ideas into production systems. At the same time, I was mentoring my first placement student while still being a placement student myself.
I spent a huge amount of time public speaking, delivering presentations, contributing to innovation initiatives, volunteering for projects outside my day job, and working with various communities, steering groups, and working groups across the organisation.
I was invited to contribute to the Technical Advisory Group (TAG), the Software Engineering Community of Practice (CoP), and later helped found the Community Tech Exchange initiative through the Innovation Team.
I was often the youngest person in those meetings, which was slightly terrifying considering many of the engineers around the table had decades of experience and held roles such as Technical Lead, Principal Engineer, or Architect.
For more information, have a look at the Beyond the Code section on my home page.
One of the highlights of my career so far was presenting to Alison Pritchard, Deputy National Statistician at the ONS. It was incredibly nerve-racking, but all those years of public speaking, sales work, presentations, and community involvement led up to moments like that.
None of this would have been possible without the mentors, teams, friends, and support networks that helped me along the way.
At the end of the day, good people, strong networks, and genuine friendships are what take you far in life.
Within the Software Engineering community at the ONS, I became one of the fastest-progressing engineers in the organisation. Ironically, the second fastest is my tech lead. Naturally, that means my next goal is to beat his record too.
Today, I'm a Senior Software Engineer operating at a lead-engineer level in many areas of my work, soon to progress to the next level once again (again there are challenges are the progression framework isn't designed for a person like me, but the org looks after me well by now). As I write this blog post, my tech lead is off for a few weeks using some of the mountain of leave he's accumulated, while I'm stepping into the technical lead role temporarily. We can't both be off at the same time.

What Am I Doing With My Life Now?¶

Chasing dreams, finding opportunities, and seeking experiences that help me grow whether that's in my career, mentally, physically, or spiritually.
This means reading all kinds of books, from spirituality and business to self-improvement and strategy. It also means spending time in nature, meditating, travelling, and learning new skills whenever I get the chance.
Remember when I said I wanted to be a pilot? I've started taking the early steps towards making that happen. Not because I want to become a commercial airline pilot, but because I'd love to earn my pilot's licence and fly for the sheer enjoyment of it and take friends along for the ride.
I'm a competitive recurve archer, currently being coached by one of the finest coaches in the UK, whose own coach was an Olympian.
After an assessment and consultation, he agreed to take me on as a student, which was a huge honour. I shoot an Olympic recurve bow, and I've recently started competing.
My goal is to shoot two to three times per week, alongside a coached session and regular competitions. Archery is one of the most complicated, stressful, frustrating, and rewarding things I've ever done. Recurve archery, especially at a competitive level, is largely a battle of mental management. Ironically, I hated archery when I first started, which is exactly why I stuck with it. That's where growth happens. There is no growth without discomfort.
I have serious goals within archery and hope to compete at a national level one day. We'll see how that journey unfolds.
Thankfully, my coach thinks I'm on the right track.
I'm also naturally quite good at running, so I figured I might as well start entering races. It still isn't fun, though. Running still sucks.
You can find my upcoming races at the bottom of my home page.
I love go-karting, and a while ago I completed a Formula car experience at Silverstone. My next step will probably be outdoor karting at around 70 mph. After driving a Formula car around Silverstone, though, 70 mph somehow feels a lot less intimidating. I may do a few more simulator sessions before heading back to Silverstone again.
Photography is another hobby I've been exploring recently. I picked up a film camera and have been having a lot of fun with it. Once I've had my latest rolls developed, I'll start uploading some of the photos to the photography section of this website assuming I actually get around to enabling that page.

Why a Static Site?¶

I decided to build this personal website as a static site. See my article on SSG, SSR, CSR, and ISR if you'd like a deeper dive into those concepts (I mostly wrote that article to re-learn them myself).

I've always preferred starting projects with the most vanilla, bare-bones solution possible and then evolving them over time.

Even now, I can already see valid use cases for introducing technologies such as Next.js, Vercel, and other modern tooling. With v0, Tailwind CSS, and a headless CMS such as Contentful, which I've previously integrated into a production Python Flask application, I could migrate this website fairly quickly if I wanted to.

As the website grows and the requirements become more complex, I expect the tech stack to evolve with it.

The funny thing is that I already know many of the functional and non-functional requirements I'd eventually want to support. However, I genuinely enjoy building things in the simplest possible way first and then upgrading them later. It makes you appreciate the benefits and trade-offs of those upgrades much more.

The same applies to technologies such as Contentful, Next.js, and other frameworks. If you've never built something without them, it's difficult to fully appreciate what they're solving.

One thing I've noticed throughout my career is that many people jump straight into large frameworks and complex architectures without first understanding the fundamentals. In my opinion, that often comes at the expense of depth. Building things from scratch, or at least in a more vanilla way, forces you to understand how everything fits together underneath the abstractions.

That's one of the reasons I often build the same type of project multiple times using different technologies. For example, I've built blog applications in both Flask and Django (see my GitHub repositories) simply to understand the differences properly rather than relying on assumptions.

In many ways, this personal website is another experiment in that philosophy.

Special Shout Out To [NAME CLASSIFIED FOR NOW]¶

This person asked me a simple question, and it ignited something in me that resulted in deploying this website to both Netlify and Vercel at the same time.
The question was something along the lines of: "I wonder what this would look like deployed on Vercel?"
My response was simple: "Only one way to find out."
While I was experimenting, I ended up fully building out the website, replacing all the placeholder content, and turning it into something real.
It's a good reminder that you need people around you who ask interesting questions, challenge your assumptions, and spark your curiosity.
Yes, this website was auto-deploying to both Netlify and Vercel simultaneously 😅. I wanted to see how the platforms differed in practice rather than relying on marketing material or opinions from the internet.
After spending time with both platforms, I found myself gravitating heavily towards Vercel's ecosystem, developer experience, tooling, and overall product vision.
Over the past year, I've spent a lot of time researching Vercel and, naturally, that meant researching many of its competitors too.
I could probably write an entire blog post comparing Vercel, Netlify, Railway, Render, Fly.io and other modern deployment platforms, explaining why each exists and where they shine. Maybe I will one day.
In the end, I shut down the Netlify deployment and moved to a paid Vercel account.
I also have plans to build a CRM and CMS-powered platform for multiple archery clubs, and at the moment Vercel, Next.js, v0, and the surrounding ecosystem are very high on my list of technologies to use.
Whether you like Vercel, dislike Vercel, or have never used it, I think most developers would agree on one thing: they care deeply about developer experience.
The documentation is excellent, the onboarding experience is polished, and the platform generally stays out of your way so you can focus on building things.
Coming from a very opinionated Python ecosystem, I don't say that lightly. My contractor friend with the love-hate relationship with Vercel was right: the documentation really is that good.

This Website's Tech Stack¶

Python, Pelican, HTML, CSS, Jinja2, Tailwind CSS, Astral tooling (uv, Ruff, etc.), and Vercel.

Tech Stack as This Website Evolves¶

Vercel products, Next.js, Contentful, and whatever else makes sense as the requirements evolve.

What's My Plan for This Site?¶

I want to write a lot more technical blog posts, particularly around Python, Django, and Wagtail.
I've had the privilege of learning from some of the best Django and Wagtail engineers in the world at Torchbox (TBX), and over the years I've developed a fairly deep understanding of these frameworks and their internals.
I've also started getting more involved in the Wagtail open-source community.
I want to share my experiences with JavaScript, React, and some of the technologies I'm currently learning and experimenting with, such as Next.js and the Vercel ecosystem.
Beyond software engineering, I want to use this website to document my journey and achievements. There will be dedicated sections covering archery, photography, racing and go-karting, running, and whatever other adventures I end up getting myself into.
I already have designs and code prepared for many of these sections. They'll be enabled and made public gradually as the site evolves.

If you'd like to follow along, there's an Atom feed - no newsletter, no tracking, no marketing emails, just good old RSS.

Follow Me On¶

Yet a Another Front-end Rendering Strategies Article: Beginners Guide to SSR, CSR, SSG, & ISR

2026-05-25T00:00:00+01:00

Why Am I Writing Yet Another Article On This Topic?¶

If you don't care about my personal context. Skip to Let's Demystify SSR, CSR, SSG & ISR

I decided to write this article on SSR, CSR, SSG, and ISR because I recently found myself in a room with one of the senior directors of a very prominent tech company.

One of the reasons my personal website actually got fully built, deployed across multiple platforms at one point, and eventually took off was because of him, or more specifically, the inspiration, advice, and perspective I gained from speaking with him and researching his work online.

We had a genuinely great conversation, although the details will stay private. You can probably tell from my website homepage and my first blog post I am Sanjeev: How I Went From Picking Up Shrapnels to Picking Up Coding that I have some experience within the JavaScript and React ecosystem, but I am by no means a front-end expert.

At work, I’ve mainly been learning from our front-end engineer while also delegating a lot of the heavier front-end work to our front-end engineer from Torchbox (TBX) 🙃.

During the conversation, we ended up discussing SSR, CSR, SSG, and ISR. I had studied these rendering strategies before, but they are not concepts I actively think about day-to-day because my primary specialisation is in the Python ecosystem, particularly with Flask, Django, and Wagtail.

I do have experience with JavaScript, TypeScript, and React from personal projects and from a short period of working on React-based projects at the ONS. But somehow, every time I end up near a JS/TS + React codebase, the natural laws of the universe seem to pull me straight back into Python 🥲.

At one point during the discussion, both of us realised that my knowledge of SSR, CSR, SSG, and ISR was not exactly sitting in RAM anymore, it was stored away on an old HDD somewhere. The concepts were still there, but it took me a little while to spin the disk back up and bring them back to life.

So I decided to properly refresh my understanding and share what I learned along the way. This article is partly for anyone trying to understand modern front-end rendering strategies, but also partly a refresher for my future self.

Who Will Benefit From This Article?¶

You are a front-end engineer looking for a refresher, or just want to criticise me. Unfortunately for you, I do not have a comments section yet...
You come from a different ecosystem, such as the Python stack, and work in web development but are not too familiar with modern front-end rendering strategies.
You are trying to break into the JS/TS + React/Next.js ecosystem.
You could not care less about front-end rendering strategies because your area of software engineering has absolutely no concern for these topics, but you are naturally curious like I am.

Let's Demystify SSR, CSR, SSG & ISR¶

Why should we care about front-end rendering strategies in the first place?¶

If you are trying to build a highly performant web application where page load speed matters, then understanding front-end rendering strategies becomes extremely important.

Metrics such as:

First Contentful Paint (FCP)
Largest Contentful Paint (LCP)
Interaction to Next Paint (INP)
First Input Delay (FID)
Time to First Byte (TTFB)
Time to Interactive (TTI)
Total Blocking Time (TBT)
Cumulative Layout Shift (CLS)

Along with overall Core Web Vitals and SEO performance, are all heavily influenced by how your application is rendered and delivered to the browser.

Failing to properly understand rendering strategies can absolutely cost you in terms of:

web performance
user experience
SEO rankings
scalability
and even infrastructure costs in some cases

If you want to go deeper into Core Web Vitals and metrics such as FCP, LCP, INP, FID, TTFB, TTI, TBT, and CLS, I have included references further below.

And ultimately, poor performance costs users.

Which then turns into lost engagement, lost conversions, lost revenue, unhappy clients, angry stakeholders, and engineers getting pulled into “why is the site slow?” meetings nobody wants to attend.

So let’s avoid that and continue with the article.

There is also a reason we are going through these rendering strategies in this specific order. It will make much more sense by the time we reach the end of the article.

Let's start with Server-side Rendering (SSR)¶

Server-side Rendering (SSR) works by rendering the page on the server before it is sent to the browser.

When a user requests a page, the server fetches the necessary data, generates the HTML content on the server itself, and then sends a fully rendered page back to the client for the user to view.

Frameworks such as Django and Next.js provide built-in server-side rendering capabilities out of the box.

With traditional Django applications, SSR is effectively the default behaviour through Django Templates. In the React ecosystem, frameworks such as Next.js introduced SSR to solve many of the SEO and performance limitations associated with purely client-rendered applications.

Use cases for SSR

SSR is commonly used in applications where content needs to be fresh, dynamic, and easily discoverable by search engines.

Examples include:

Real-time dashboards and analytics platforms
Financial trading platforms showing live market data
Social media feeds and activity timelines
E-commerce product pages with live pricing and stock availability
Personalised user dashboards
News platforms with constantly updating content
SaaS platforms with authenticated, user-specific data

Where SSR shines

SSR serves fresh and up-to-date content on every request
Search engines receive fully rendered HTML immediately, which is excellent for SEO
Better SEO compared to purely client-side rendered applications
Faster initial content visibility for users compared to CSR
Works well for dynamic and personalised experiences
Improves social media link previews and metadata rendering

Things to keep in mind with SSR

SSR is powerful, but it does come with trade-offs.

Every request requires server-side rendering and often data fetching, which increases server load
Under high traffic, SSR applications can become expensive to scale without caching layers
Time to First Byte (TTFB) can sometimes suffer because the server must finish rendering before responding
Pages may visually appear quickly, but JavaScript still needs to hydrate on the client before the page becomes fully interactive
Rendering complex pages repeatedly on the server can increase infrastructure costs
Poorly optimised SSR applications can still end up shipping large JavaScript bundles to the browser

One important thing to understand is that SSR improves the initial render experience, but it does not magically remove the cost of JavaScript running in the browser afterwards. The client still needs to hydrate the application and attach interactivity to the rendered HTML.

Let's navigate to Client-side Rendering (CSR)¶

Client-side Rendering (CSR) relies heavily on JavaScript to render content directly within the browser on the user's device. It enables highly interactive and responsive user experiences, but it comes with trade-offs around initial load performance and SEO.

In modern applications, CSR is often layered on top of SSR, SSG, or ISR to add interactivity and dynamic client-side behaviour.

The way CSR works is relatively straightforward:

A lightweight HTML shell is initially sent to the browser
JavaScript bundles are then downloaded and executed
The application fetches data from APIs
The browser renders and updates the UI dynamically on the client side without requiring full page reloads

In this model, the browser effectively becomes responsible for controlling much of the application's rendering and state management.

Use cases for CSR

CSR works particularly well for highly interactive applications where responsiveness matters more than initial page load speed or SEO.

Examples include:

Interactive admin dashboards
Real-time analytics platforms
Project management tools
Chat and messaging applications
Collaborative applications such as online editors
Internal enterprise tools
Highly interactive SaaS products
Applications with frequent UI updates and client-side state changes

A common example is when users interact with filters, charts, forms, or live-updating components where waiting for a full server roundtrip would feel slow and clunky.

Where CSR shines

JavaScript powers rich interactivity and smooth, app-like experiences
Reduces repeated rendering work on the server
Seamless transitions between pages and application states
Excellent for highly dynamic interfaces
Works very well for real-time interactions and live-updating data
Enables sophisticated client-side state management and UI behaviour
After the initial load, navigation can feel extremely fast

Things to keep in mind with CSR

CSR also comes with several important trade-offs.

The initial page load can be slower because JavaScript bundles must download, parse, and execute before meaningful content appears
Optimising Core Web Vitals can become more challenging
Large JavaScript bundles can significantly impact performance on slower devices
SEO can become problematic because content is rendered dynamically in the browser
Search engines have improved at rendering JavaScript, but SSR and SSG are still generally more SEO-friendly
Applications often require more complex client-side state management
Users on poor network connections may experience blank screens while waiting for JavaScript to load

One of the biggest criticisms of poorly optimised CSR applications is the infamous “loading spinner experience”, where users stare at a blank page while the browser downloads and executes a massive JavaScript bundle before anything useful becomes visible.

Let's now make a pit stop at Static Site Generation (SSG)¶

Static Site Generation (SSG): SSG prerenders pages at build time, resulting in static HTML files that can be cached at the edge and served quickly and efficiently.

With SSG, HTML is generated build time, not at request time. This way, the server doesn't do the rendering; it simply serves the pre-built files.

The way SSG works is HTML for all pages is generated in advance and usually stored on a Content Delivery Network (CDN).

When users request a page, it's delivered instantly from the nearest CDN.

Use cases for SSG

Any page with content that changes very infrequently
Site layouts
Performance-critical marketing pages
Documentation or other sites that quickly rebuild

Where SSG shines

Ultra fast load times since the content is pre-rendered, it lads nearly instantly.
SEO friendly as search engines like the fully rendered pages served directly from a CDN.
Low server costs with no on the fly rendering, server handles less load.
Fastest possible page loads
Excellent SEO performance
Reduced server load
Lowest infrastructure costs

Things to keep in mind with SSG

Increased build times for sites with a large number of pages
Content updates require a new build and deployment
Can be combined with client-side data fetching for dynamic elements, but this is slower than server-side fetching since each data request initiates a new roundtrip to the server
Content is static, so it doesn't change until the next build.
Slow builds for large sites, as the number of pages grows, builds can become time-consuming

Fancy Incremental Static Regeneration (ISR)¶

Incremental Static Regeneration (ISR) allows you to update specific pages after your site has already been built, meaning you do not need to rebuild the entire application every time content changes.

In many ways, ISR combines the speed of Static Site Generation (SSG) with some of the flexibility of SSR.

The core idea behind ISR is simple:

Pages are generated statically at build time
Those pages are cached and served extremely quickly
After a configured revalidation period, the next incoming request triggers a background regeneration of the page
Users continue receiving the previously cached version while the new version is generated
Once regeneration completes, the cache is updated with the fresh page

This approach allows applications to scale to extremely large numbers of pages without suffering from painfully long full-site rebuilds.

Frameworks such as Next.js popularised ISR by introducing built-in revalidation capabilities directly into the framework.

How ISR works

A simple way to think about ISR is:

"Generate pages statically, cache them aggressively, and refresh them in the background only when needed."

Compared to traditional SSG:

build times are significantly faster for large applications
not every page needs to regenerate during deployment
content can update automatically without requiring a full rebuild

ISR can also support:

timed revalidation
on-demand revalidation
webhook-triggered regeneration
CMS-driven cache invalidation

Which becomes incredibly useful for modern content-heavy platforms.

Use cases for ISR

ISR is particularly useful when:

you want SSG-level performance
but your content changes too frequently for full static builds to remain practical

Common examples include:

E-commerce product pages
News and publishing websites
Documentation platforms
Marketing sites with CMS-managed content
Large-scale blogs
Marketplace platforms
Applications with thousands or even millions of pages

ISR becomes especially valuable when traditional SSG build times start becoming unmanageable.

Where ISR shines

You get performance that is very close to SSG
Pages remain SEO-friendly because static HTML is still served to search engines
Content can update automatically without requiring a full rebuild
Maintains extremely fast page loads through caching
Scales efficiently to very large numbers of pages
Reduces deployment bottlenecks caused by massive static builds
Can be more infrastructure-efficient than SSR in some scenarios
Supports modern CMS-driven workflows very well

One of the reasons ISR became so popular is because it helps solve the classic trade-off between:

fast static websites
and frequently changing dynamic content

Things to keep in mind with ISR

You have to be mindful of cache invalidation strategies/ approaches
Understand how ISR differs from cache control headers
There can be still a lag between data updates and page regeneration
ISR introduces additional complexity especially for large-scale applications

When to Use SSR, CSR, SSG or ISR?¶

By this point, you have probably realised something important:

There is no single “best” rendering strategy.

Each approach exists because different applications have different requirements around:

performance
SEO
scalability
infrastructure cost
freshness of data
and user experience

Choosing the wrong rendering strategy can lead to unnecessary complexity, poor performance, expensive infrastructure bills, or terrible SEO.

The real engineering skill is understanding the trade-offs.

Here are some general rules of thumb.

Use SSR when...

Use SSR when content needs to be:

dynamic
personalised
frequently updated
or request-specific

Good examples include:

Social media feeds
Financial dashboards
SaaS applications
User-specific dashboards
E-commerce checkout flows
Live sports scoreboards
Real-time analytics platforms
Applications with authentication-heavy workflows

SSR is often the right choice when freshness matters more than absolute rendering speed.

Use CSR when...

Use CSR when your application behaves more like a desktop application running in the browser.

Good examples include:

Admin dashboards
Internal enterprise tools
Chat applications
Kanban/project management platforms
Real-time collaborative editors
Interactive visualisation tools
Applications with heavy client-side interactions

CSR works best when:

SEO is less important
interactivity is extremely important
and users spend long periods interacting with the application after the initial load

A lot of modern SaaS products lean heavily into CSR.

Use SSG when...

Use SSG when content:

changes rarely
is mostly static
and benefits heavily from speed and SEO

Good examples include:

Blogs
Documentation websites
Marketing websites
Portfolio websites
Landing pages
Company information pages
Developer documentation platforms

SSG is fantastic for performance because pages are pre-built ahead of time and can be served directly from a CDN extremely quickly.

This is why many modern documentation platforms feel almost instant.

Use ISR when...

Use ISR when you want the speed of static generation, but your content changes too often for full rebuilds to remain practical.

Good examples include:

Large e-commerce platforms
News websites
CMS-driven content platforms
Marketplace listings
Large-scale blogs
Documentation platforms with frequent updates
Sites with thousands or millions of pages

ISR is effectively the middle ground between SSG and SSR.

You still get static performance characteristics, but with the ability to refresh content incrementally over time.

Hybrid Strategies¶

Here is the important part:

Modern applications rarely use just one rendering strategy.

Most real-world applications are hybrids.

A single application might use:

SSR for authenticated dashboards
SSG for marketing pages
ISR for blog content
and CSR for interactive components on the page

This is actually how many large-scale modern applications are architected today.

For example, an e-commerce platform could use:

Homepage - SSG
Product pages - ISR
User dashboard - SSR
Shopping cart interactions - CSR
Live stock indicators - CSR
Checkout flow - SSR

The modern React ecosystem, particularly frameworks such as Next.js, has heavily embraced this hybrid rendering model.

Even traditional server-rendered frameworks such as Django often use hybrid approaches:

Django Templates for SSR
HTMX or Alpine.js for partial interactivity
React components for highly dynamic sections
CDN caching for static assets
API-driven front-end enhancements where needed

The important thing is not blindly choosing a trendy rendering strategy.

The important thing is understanding:

what problem you are solving
where performance matters
where SEO matters
where interactivity matters
and where complexity starts becoming unnecessary

Because at the end of the day, engineering is all about trade-offs.

Bonus: Partial Prerendering (PPR)¶

If you made it this far into the article, good news, I have some bonus content for you.

One of the newer concepts emerging in the modern React and Next.js ecosystem is Partial Prerendering (PPR).

PPR is essentially an enhancement layered on top of existing rendering strategies rather than being a completely separate rendering model on its own.

The goal of PPR is to combine:

the instant loading experience of SSG
the dynamic flexibility of SSR
and the streaming capabilities introduced through modern React Server Components and Suspense boundaries

In simple terms:

Serve a fast static shell immediately, then progressively stream dynamic content into the page as it becomes ready.

This helps eliminate the traditional trade-off between:

static performance
and dynamic server-rendered experiences

Why PPR is interesting

Historically, developers often had to choose between:

fast static pages
or fully dynamic pages

PPR attempts to blur that line.

With PPR:

the static parts of the page can be prerendered and cached at the edge while dynamic sections stream in separately without blocking the initial render

This means users can start seeing meaningful content almost instantly while slower dynamic sections continue loading in the background.

Potential benefits of PPR

Instant initial page loads similar to SSG
Dynamic content can stream progressively into the page
Better perceived performance for users
Reduced blocking during rendering
More efficient use of server rendering
Potentially improved Core Web Vitals
Less need to fully choose between “static” and “dynamic” architectures

In many ways, PPR represents where modern rendering architectures seem to be heading.

Current considerations

PPR is still evolving and should still be considered relatively experimental.

Things to keep in mind:

Some applications may require architectural refactoring to adopt it properly
Proper Suspense boundary design becomes extremely important
Separating static and dynamic content cleanly takes planning
Debugging streaming behaviour can introduce additional complexity
The ecosystem around PPR is still maturing

Closing Thoughts¶

If you made it all the way to the end of this article, congratulations, you now probably understand front-end rendering strategies better than I did when I walked into that conversation with the senior director 😅.

Hopefully this article helped demystify SSR, CSR, SSG, ISR, and even some of the newer ideas such as Partial Prerendering (PPR), without making them feel overly academic or unnecessarily complicated.

One of the biggest things I realised while revisiting these concepts is that modern web engineering is increasingly becoming about choosing the right rendering strategy for the right problem rather than blindly committing to a single approach.

The reality is:

modern applications are hybrid
trade-offs are everywhere
performance matters
SEO matters
user experience matters
and JavaScript bundles somehow still end up being 4MB regardless 🙃

As someone whose background primarily lives within the Python ecosystem, particularly Flask, Django, and Wagtail, revisiting these concepts was genuinely refreshing. It also reminded me how much modern front-end engineering has evolved over the last few years.

We have gone from:

“everything server-rendered”
to “everything client-rendered”

And now towards intelligent hybrid architectures combining:

SSR
SSG
ISR
streaming
edge rendering
Suspense boundaries
and selective hydration

...all within the same application.

Which is both incredibly exciting and overwhelming at the same time.

Anyway, thank you for reading my “Yet Another Front-end Rendering Strategies Article”.

Now go optimise your Core Web Vitals, reduce your JavaScript bundle sizes, and try not to accidentally turn your homepage into a distributed systems research paper.

Good luck!

Sanjeev Srithevan

I am Sanjeev: How I Went From Picking Up Shrapnels to Picking Up Coding

A Bit About Myself: Why Did I Spin Up a Personal Website?¶

Sri Lankan Civil War / Life in Sri Lanka¶

Coming to the UK¶

Skipping to the Nice Parts¶

Pilot¶

Poking Around With Computers Like a Caveman Discovering Fire¶

How the Computer Science & Coding Journey Started¶

GCSEs¶

A-Levels¶

University of Portsmouth (Yes, It's Not Cambridge, Oxford, Stanford, or Harvard)¶

Work Experience During University¶

Internships & Industrial Placements¶

Graduation (I Didn't Go to It)¶

My Career Trajectory So Far¶

What Am I Doing With My Life Now?¶

Why a Static Site?¶

Special Shout Out To [NAME CLASSIFIED FOR NOW]¶

This Website's Tech Stack¶

Tech Stack as This Website Evolves¶

What's My Plan for This Site?¶

Follow Me On¶

Yet a Another Front-end Rendering Strategies Article: Beginners Guide to SSR, CSR, SSG, & ISR

Why Am I Writing Yet Another Article On This Topic?¶

Who Will Benefit From This Article?¶

Let's Demystify SSR, CSR, SSG & ISR¶

Why should we care about front-end rendering strategies in the first place?¶

Let's start with Server-side Rendering (SSR)¶

Let's navigate to Client-side Rendering (CSR)¶

Let's now make a pit stop at Static Site Generation (SSG)¶

Fancy Incremental Static Regeneration (ISR)¶

When to Use SSR, CSR, SSG or ISR?¶

Hybrid Strategies¶

Bonus: Partial Prerendering (PPR)¶

Closing Thoughts¶

References¶