DEV Community: Yash Matrani

# Stop Lying to Yourself: I Built a Full-Stack SaaS at 16 (While in 10th Grade)

Yash Matrani — Sat, 31 Oct 2026 11:19:52 +0000

Stop Lying to Yourself: I Built a Full-Stack SaaS at 16 (While in 10th Grade)

Let’s cut the bullshit.

You are reading this article, probably scrolling through tutorials, watching "how to code in 2026" videos, and convincing yourself that you’re making progress. You’re not. You’re just consuming.

I am 16 years old. I study in 10th grade (CBSE, India). I have board exams breathing down my neck. And yet, I just deployed a fully functional, production-ready crowdfunding platform called "Get Me A Chai".

No team. No venture capital. No rich parents funding my startup. Just me, a laptop, and an absolute refusal to be average.

If you are older than me and still making excuses about why you can't build, this article is going to hurt your ego. Good. Your ego needs to be shattered.

Here is the brutal reality of how I built it, the tech stack, and why 99% of you will remain stuck in tutorial hell forever.

1. The Tech Stack (No Hand-Holding)

If you don’t know what is happening under the hood, you are a liability, not a developer.

I used:

Next.js (App Router): For blazing-fast UI and server actions.
NextAuth (Auth.js) + GitHub OAuth: For secure session management.
MongoDB Adapter: For persistent user and payment data.
Razorpay API: For handling the transaction flow.
Tailwind CSS: For the UI (because writing raw CSS for hours is a waste of time).

The Real Fight: NextAuth in App Router

Every tutorial tells you to use useSession(). They don't tell you that if you use it inside a Server Component, your app breaks with a Hydration error.

You have to use getServerSession(authOptions) on the server and useSession() on the client. Mixing them up is a rookie mistake. I spent hours debugging this. Did I quit? No. I read the docs. I fixed the architecture.

The Beast: Razorpay Webhooks & Idempotency

Building a button that says "Pay Now" is easy. Building the backend that actually handles the money without double-charging the user is where men are separated from boys.

Razorpay sends webhooks. Sometimes, due to network issues, it sends the same webhook multiple times. If your code is weak, you will process the same payment 3 times and mess up the database.

I had to implement an idempotency check. Before saving a payment to MongoDB, I check if the payment_id already exists. If it does, I ignore it.

This is production-level logic. You won't learn this from a 10-minute YouTube video. You learn this by breaking things and building them back up.

2. Excuses Don't Build Empires

Let’s talk about your Fucking excuses.

"I don't have time."
"I'm too young."
"I need a degree first."
"I need to focus on school."

Shut The Fuck up.

Starting late or waiting for the "right time" is voluntary suicide of your potential. Every day you spend doing nothing is a day someone else is building the product that will make your skills obsolete.

I am in 10th grade. I have school from 7 AM to 2 PM. I have coaching. But school is just a side quest. My skill is the main seat.

If you want to build a business, you have to treat it like a business. I wake up, study for my boards, and then I code for hours. I sacrifice sleep, I sacrifice parties, and I sacrifice the "normal" teenage experience. Why? Because I refuse to be a broke, average adult who relies on a 9-to-5 job to survive.

If you are reading this and feeling attacked, it means you know you are slacking.

3. How to Manage School and Business

Here is the formula if you are a student: Keep school on the side, keep skill on the main seat.

School gives you a baseline. Skill gives you a future.

Study Smart, Not Long: I finish my school syllabus efficiently. I don't waste time memorizing things that don't matter. I need PCMB 75%+. That's the target.
Code Every Single Day: Even if it's just 1 hour. The consistency compounds.
Use the "Because" Principle: Every time you sit down to code, tell yourself because you want financial freedom, because you want to build a trillion-dollar company. Give your brain a reason to focus.

4. Connections Make You Money, Not Just Code

You can be the best coder in the world, but if you don't have a network, you will starve.

I didn't just write code. I built a brand. YashDevelopers.

I started posting on X (Twitter) and LinkedIn.
I engaged with real developers, founders, and freelancers.
I studied psychology and negotiation. I read Never Split the Difference and 48 Laws of Power.

I don't just talk to people; I influence them.

When I launched "Get Me A Chai", I didn't just post a link. I built a narrative. I showed the struggle, the code, the architecture, and the result. A stranger visited my site and simulated a payment just to test if it works (Shoutout to "Tarun donated ₹67").

Why did that happen? Because I built trust. You can't hack trust with code; you build it with human connection.

5. The Hard Truth (And A Warning)

I built a system that processes real money. But I am 16. I don't have a PAN card, and I don't have a merchant KYC.

So, what did I do? I used Test Keys.

My platform is live. It is 100% production-ready. If a verified merchant puts their live keys into the .env file, it will process real money flawlessly.

BUT I WILL NOT RECOMMEND IT.
Because I built this solo. Until I audit every single edge case and form a team, putting live financial keys into this app is a massive security liability.

This is what maturity looks like. Knowing what you built, knowing its limits, and being honest about it. I don't need to fake numbers to feel validated. My code speaks for itself.

The Final Kick in the Ass

I'm 16. I'm balancing exams, client work, and building a startup. I'm not a genius. I don't have an IQ of 160. I just have an obsession with building things and a deep, terrifying fear of being ordinary.

You are reading this article. You have a laptop. You have internet. You have ZERO excuses.

If you are waiting to finish school first, you’ve already lost.
If you are waiting for someone to hold your hand, you are weak.
If you are not building, you are just consuming.

Stop reading this. Close this tab. Go to GitHub. Start a project. Break your code. Fix it. Deploy it.

And when you finally launch something real, come back and tell me. I'll be waiting.

I am building in public. If you have the guts to do the same, connect with me.

🔗 Live Site: get-me-a-chai-lac-eight.vercel.app
🔗 My Page: get-me-a-chai-lac-eight.vercel.app/YashDevelopers
🔗 X (Twitter): @Developervxku
🔗 GitHub: yashmatrani-cpu

Now, stop reading and start building.

# Stop Breaking Your Next.js App: NextAuth Setup in App Router (with MongoDB)

Yash Matrani — Thu, 22 Oct 2026 07:20:50 +0000

Setting up authentication in Next.js 14 (App Router) is a nightmare if you don't understand the boundary between Server Components and Client Components.

I spent hours debugging useSession returning null or throwing hydration errors. Here is the exact, fool-proof way to set up NextAuth (Auth.js) with a MongoDB database.

1. Installation


bash
npm install next-auth @auth/mongodb-adapter mongodb
2. Environment Variables
Create a .env.local file and add your GitHub OAuth credentials and MongoDB URI:

env
GITHUB_ID=your_github_client_id
GITHUB_SECRET=your_github_client_secret
MONGODB_URI=your_mongodb_connection_string
NEXTAUTH_SECRET=any_long_random_string
NEXTAUTH_URL=http://localhost:3000
3. The MongoDB Adapter
To save users in your database, create a file lib/mongodb.js:

javascript
import { MongoClient } from "mongodb";

if (!process.env.MONGODB_URI) {
  throw new Error('Invalid/Missing environment variable: "MONGODB_URI"');
}

const uri = process.env.MONGODB_URI;
const options = {};

let client;
let clientPromise;

if (process.env.NODE_ENV === "development") {
  if (!global._mongoClientPromise) {
    client = new MongoClient(uri, options);
    global._mongoClientPromise = client.connect();
  }
  clientPromise = global._mongoClientPromise;
} else {
  client = new MongoClient(uri, options);
  clientPromise = client.connect();
}

export default clientPromise;
4. The Auth Route Handler
In App Router, NextAuth requires a specific Route Handler. Create app/api/auth/[...nextauth]/route.js:

javascript
import NextAuth from "next-auth";
import GithubProvider from "next-auth/providers/github";
import { MongoDBAdapter } from "@auth/mongodb-adapter";
import clientPromise from "@/lib/mongodb";

export const authOptions = {
  adapter: MongoDBAdapter(clientPromise),
  providers: [
    GithubProvider({
      clientId: process.env.GITHUB_ID,
      clientSecret: process.env.GITHUB_SECRET,
    }),
  ],
  secret: process.env.NEXTAUTH_SECRET,
  session: {
    strategy: "jwt", 
  },
};

const handler = NextAuth(authOptions);

export { handler as GET, handler as POST };
5. The Client Component Wrapper
Because layout.js is a Server Component by default, you cannot put SessionProvider directly inside it. You need a wrapper.

Create app/providers.js:

javascript
"use client";

import { SessionProvider } from "next-auth/react";

export default function Providers({ children }) {
  return <SessionProvider>{children}</SessionProvider>;
}
Now wrap your body in app/layout.js:

javascript
import Providers from "./providers";

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  );
}
6. Using the Session (The Trap)
This is where 90% of people fail.

In Client Components:
javascript
"use client";
import { useSession } from "next-auth/react";

export default function Profile() {
  const { data: session } = useSession();
  if (!session) return <p>Not logged in</p>;
  return <p>Welcome {session.user.name}</p>;
}
In Server Components / API Routes:
Never use useSession here. Use getServerSession.

javascript
import { getServerSession } from "next-auth";
import { authOptions } from "@/app/api/auth/[...nextauth]/route";

export default async function ServerPage() {
  const session = await getServerSession(authOptions);

  if (!session) return <p>Unauthorized</p>;
  return <p>Hello {session.user.email}</p>;
}
Conclusion
NextAuth is incredibly powerful once it clicks. The golden rule of App Router: Keep hooks in the client, and getServerSession in the server.

Stop wasting hours on hydration errors. Build.

# The MERN Auth Flow: How JWT actually works (Without the headache)

Yash Matrani — Mon, 19 Oct 2026 07:29:19 +0000

Authentication is the most confusing part of learning the MERN stack.

When I started building full-stack apps, I struggled to understand what actually happens between clicking "Login" and seeing the dashboard. I read tutorials that used NextAuth, Firebase, or Passport.js, but I never understood the core mechanism.

So I decided to build it from scratch. Here is the exact flow of JWT (JSON Web Token) authentication in a MERN app.

The 3-Step Architecture

Authentication is basically a bouncer at a club.

Verify: Check the ID (Email + Password).
Issue: Give a wristband (JWT Token).
Check: Verify the wristband on every request.

Here is how it translates to code.

Step 1: Hashing the Password (Backend)

Never store passwords as plain text. When a user registers, we use bcrypt to hash the password before saving it to MongoDB.


javascript
import bcrypt from "bcryptjs";
import User from "../models/User.js";

// During Registration
const salt = await bcrypt.genSalt(10);
const hashedPassword = await bcrypt.hash(req.body.password, salt);

const newUser = new User({
  email: req.body.email,
  password: hashedPassword
});
await newUser.save();
Step 2: Generating the JWT (Backend)
When the user logs in, we compare the entered password with the hashed password. If it matches, we generate a JWT using the jsonwebtoken library.

javascript
import jwt from "jsonwebtoken";

const user = await User.findOne({ email: req.body.email });
if (!user) return res.status(404).json("User not found");

const validPassword = await bcrypt.compare(req.body.password, user.password);
if (!validPassword) return res.status(400).json("Wrong password");

// Create Token
const token = jwt.sign({ id: user._id }, process.env.JWT_SECRET, { expiresIn: "1d" });
res.json({ token, user });
Step 3: Storing the Token (Frontend)
On the React frontend, we receive this token and store it in localStorage.

javascript
const res = await fetch("/api/login", { method: "POST", body: JSON.stringify(data) });
const { token } = await res.json();

// Save the token
localStorage.setItem("token", token);
window.location.href = "/dashboard"; // Redirect
Step 4: Protecting Routes with Middleware
Now, whenever the user visits a protected route (like /dashboard), the frontend must send the token. But the backend needs to verify it. We do this using Middleware.

javascript
import jwt from "jsonwebtoken";

export const verifyToken = (req, res, next) => {
  const authHeader = req.headers.token;

  if (authHeader) {
    jwt.verify(authHeader, process.env.JWT_SECRET, (err, user) => {
      if (err) return res.status(403).json("Token is not valid!");
      req.user = user;
      next(); // Proceed to the actual route
    });
  } else {
    return res.status(401).json("You are not authenticated!");
  }
};
Step 5: Using the Middleware
javascript
app.get("/api/dashboard", verifyToken, async (req, res) => {
  // req.user now contains the decoded ID from the token
  const user = await User.findById(req.user.id);
  res.json(user);
});
Why this matters
Tools like NextAuth or Clerk are great, but if you don't understand the underlying JWT mechanism, you will struggle when you need custom logic (like Role-Based Access Control for an Admin Panel).

Building it from scratch takes 2 days, but it gives you 10 years of clarity.

I'm 16 and currently building full-stack projects for real clients. If you are learning MERN, keep pushing.

Follow my journey on X: @Developervxku

# What the Indian education system never taught me (and how I learned it anyway)

Yash Matrani — Fri, 16 Oct 2026 04:04:56 +0000

What the Indian education system never taught me (and how I learned it anyway)

I am sixteen years old. I study in the tenth grade. And for the last two years, I have been learning things that no textbook in my syllabus has ever mentioned.

Not because my teachers are bad. Not because my school is worse than others. But because the system itself was never designed to teach these things.

This article is not a rant. It is not a complaint about the education system. It is an honest reflection on the gap I have noticed between what I am taught and what I actually need.

The memorization problem

In my school, success is measured by how accurately I can reproduce what is written in a textbook.

The chapter on electricity has twelve formulas. I memorize them. The chapter on carbon compounds has forty reactions. I memorize them. The chapter on history has dates and names and events. I memorize those too.

I am not learning physics. I am learning to recall sentences.

This is not a unique experience. Every student in India knows this pattern. We spend years perfecting the art of memorization, and somewhere along the way, we forget how to think.

The problem is not that facts are unimportant. The problem is that facts alone do not build understanding.

We study the greats. We are never taught to become them.

There is a strange contradiction at the heart of how history is taught in Indian schools.

We read about Gandhi, who led a nation to freedom. We read about Bhagat Singh, who gave his life for a cause he believed in. We read about Einstein, who rewrote physics from the ground up. We read about Abdul Kalam, who rose from a small town in Tamil Nadu to become the President of India and a scientist who shaped the country's missile program.

But we are never taught to become like them.

We are taught their dates. We are taught their achievements. We are taught to write essays about their lives. But we are not taught the one thing that actually matters — the mindset that made them who they were.

We are not taught that Gandhi failed many times before he led a movement. We are not taught that Kalam sold newspapers as a child. We are not taught that Einstein was considered a slow learner. We are not taught that every single one of these people started out exactly where we are — with nothing but an idea and the stubbornness to keep going.

The system teaches us to admire them. It never teaches us to emulate them.

Because if it did, we might start asking uncomfortable questions. Like why are we being prepared to work for someone else, when these people built their own path?

The lesson of history is not that great people existed. The lesson is that ordinary people became great by refusing to stay ordinary.

That lesson is never taught.

What is missing

When I look at the skills that actually matter in the modern world, I notice that almost none of them are part of my curriculum.

Coding is not taught.
I learned Python from YouTube. I learned React from a free course. I learned MongoDB by breaking things and rebuilding them. None of this came from school. And yet, these are the skills that will define the next twenty years of my career.

Negotiation is not taught.
I learned how to negotiate from a book written by an FBI hostage negotiator. I learned how to communicate, how to ask for what I want, and how to recognize when I am being manipulated. My school never mentioned these things. But every interaction I have as an adult will require them.

Building is not taught.
I learned to build projects by starting them and finishing them. Small tools. Websites. Scripts. Things that nobody asked me to build, but that I wanted to exist. The process of building taught me more than any exam has ever taught me.

Thinking is not taught.
I learned to think by reading books outside my syllabus, by questioning what I was told, and by sitting with confusion until it became clarity. School taught me to answer questions. It never taught me to ask them.

The cost of this gap

When I look at my classmates, I see students who are incredibly good at exams but terrified of real problems.

They can solve a quadratic equation in thirty seconds. But ask them to build something — anything — and they freeze. They can recite the periodic table from memory. But ask them to solve a problem that is not in the textbook, and they don't know where to begin.

This is not their fault. It is the system's fault. The system was built to produce good exam-takers, not good thinkers.

And the cost of this is enormous. It shows up in the workforce, where companies complain that fresh graduates cannot do real work. It shows up in the startup ecosystem, where very few people know how to build anything from scratch. It shows up in the lives of millions of students who graduate with degrees but without confidence.

The job trap

There is one more thing the system never taught me, and it is perhaps the most important.

It never taught me that I do not have to spend my life competing for a seat at someone else's table. I can build my own.

Let me be clear about what I mean.

I have deep respect for people who work jobs. My mother works. My teachers work. Millions of people in India work jobs to feed their families, and that is not something to look down upon. A job is a legitimate path. It provides stability, income, and structure. For many people, it is the right choice.

But somewhere along the way, the system started treating jobs as the only choice.

We are told to study hard so we can get a good job. We are told to build our resumes so we can get hired. We are told that our success is measured by which company we work for, how much they pay us, and how quickly we get promoted.

Nobody tells us that we can create jobs instead of applying for them.

Nobody tells us that we can build products instead of building someone else's dream.

Nobody tells us that the people who shape the world are almost never the ones waiting for permission.

Think about the names we admire. Elon Musk did not get famous by working a job — he built companies. Every empire in history started with a person who refused to wait for someone else to hand them a seat.

This is not a call to quit your job. This is a call to think bigger than a job.

If you are a student, do not spend all your energy preparing to be hired. Spend some of it preparing to build. Learn how businesses work. Learn how to sell. Learn how to ship a product. Learn how to talk to customers.

A job gives you a salary. A business gives you freedom. Neither is wrong. But only one of them is presented as a possibility to most students.

The system never taught me this. So I am teaching myself.

And I want to say one thing to everyone who has chosen a job: I respect your choice completely. There is no shame in providing for your family, in working hard, in earning an honest living. But I hope that the next generation — my generation — will be taught that both paths exist. And that both are worth considering.

Build your own table. You do not have to wait for a seat at someone else's.

Not just code. Not just marks.

There is a trap that many self-taught developers fall into, and I almost fell into it too.

The trap is believing that if you just learn to code well enough, everything else will fall into place.

It will not.

Coding is a skill. But it is not the only skill. And the developers who go the furthest are not the ones who only know how to write code. They are the ones who also know how to talk to people, how to negotiate, how to build habits that compound over time, and how to sell what they have built.

Two books changed how I think about this.

The first is Never Split the Difference by Chris Voss. It is written by a former FBI hostage negotiator, and it teaches you how to communicate when the stakes are high. It taught me that most conversations are not won by arguing harder. They are won by listening better, by labeling emotions, and by asking questions that make the other person feel heard.

The second is Atomic Habits by James Clear. It taught me that the person I become is not determined by a few big decisions, but by thousands of small ones. One percent better every day does not feel like much. Over a year, it changes everything.

There are others too. 48 Laws of Power by Robert Greene. Deep Work by Cal Newport. The Psychology of Money by Morgan Housel. Each one fills a gap that school left behind.

If you are a student like me, do not make the mistake of thinking that coding alone will save you. It will not. You need to read. You need to learn how people think, how they make decisions, and how to work with them.

The best engineers are not just engineers. They are students of human behavior.

The two paths

Here is the uncomfortable truth I have arrived at.

There are only two ways to live, and most people drift into one without ever choosing it.

The first path: enjoy the small pleasures of being poor, and stay there forever. Chai, comfort, familiar streets, and a life that never quite changes. There is nothing wrong with this. Millions of people live it and find peace in it. It is a legitimate choice.

The second path: reach the top 0.0001%, and then reach back down to pull others up.

I am not interested in the first path. Not because I look down on it — but because I know what it costs. I have seen what happens to families when the money runs out. I have seen what happens when a medical bill arrives and there is nothing in the bank. I have seen what it does to a person's dignity.

I do not want that for myself. And I do not want it for anyone else.

So I am choosing the second path. Not because I want a Lamborghini. Not because I want to show off. But because money, at a certain level, stops being about pleasure and starts being about protection — protection for my family, for my future, and eventually, for people who were born into the same situation I was.

I want to reach the top. And then I want to turn around and open the door behind me.

That is the only version of success that means anything to me.

What I did about it

I did not wait for the system to change. I started learning on my own.

I learned to code from YouTube and from documentation. I learned to write by writing. I learned to negotiate by reading books and by practicing in small conversations. I learned to build by building.

None of this was easy. There was no teacher to guide me, no syllabus to follow, no exam to prepare for. I had to figure out my own path, and I had to stay consistent even when nobody was watching.

But I learned something that no classroom could have taught me: how to teach myself.

That is the most important skill I have ever developed. And it is the one skill that the education system has consistently failed to provide.

What I would change

If I could redesign the Indian education system, I would make three changes.

First, I would replace memorization with application.
Instead of asking students to recall what a formula says, I would ask them to use the formula to solve a real problem. Instead of testing memory, I would test understanding.

Second, I would introduce coding and building from an early age.
Not as an optional subject, but as a core skill. Just like reading and writing, building should be something every student learns to do.

Third, I would teach communication and negotiation.
Because these are the skills that will determine whether a student succeeds in life, regardless of how good their grades are.

A note to students like me

If you are reading this and you feel the same way I do, here is what I want to say.

Do not wait for the system to change. Start learning what matters, on your own.

You can learn coding from free resources. You can learn negotiation from books. You can learn to build by building. You do not need permission from anyone.

The system will keep doing what it was designed to do. But you can choose to learn differently.

You can choose to be more than your marks.

A note to teachers and parents

If you are reading this, I want you to know that I do not blame you.

You are doing the best you can within a system that is hard to change. But I want to invite you to consider one thing: what would it look like if students were allowed to learn differently?

What if students were encouraged to build things instead of memorizing them?

What if marks were less important than understanding?

What if the goal of education was not to produce good exam-takers, but good thinkers?

These are not easy questions. But they are important ones.

Final thoughts

I am sixteen years old. I have been learning on my own for two years. And I have realized something important.

The gap between what I am taught and what I need is not a gap that can be closed by the system.

It is a gap that has to be closed by me.

I am not waiting for the system to change. I am changing myself.

And if you are a student like me, I hope you do the same.

*I write about code, physics, math, and the things I build. If you are also learning on your own.

let's connect:-``

GitHub: github.com/yashmatrani-cpu/My-Projects
Gumroad: yashmatrani.gumroad.com
X: @Developervxku

# Let's simulate gravitational lensing around a black hole in Python

Yash Matrani — Wed, 14 Oct 2026 11:55:32 +0000

"The black holes of nature are the most perfect macroscopic objects there are in the universe: the only elements in their construction are our concepts of space and time."
— Subrahmanyan Chandrasekhar

There is something deeply unsettling about a black hole. Not because it is massive, or distant, or invisible. But because it represents the point where our understanding of physics simply stops working. The equations that describe everything else in the universe — gravity, light, time — collapse into a singularity at the center, and nobody quite knows what happens next.

I am sixteen years old. I study in the tenth grade. And I find this terrifyingly beautiful.

This article is not a physics paper. It is not a tutorial written by an expert. It is simply an attempt by a student to understand one of the strangest phenomena in the universe by writing code. Because sometimes, reading a formula is not enough. You have to watch it move.

The mathematics of no return

Every black hole has a boundary. It is not a wall, and it is not a surface. It is a distance from the center where the escape velocity — the speed required to break free from the object's gravity — equals the speed of light. Beyond that boundary, nothing escapes. Not matter. Not radiation. Not even light.

This boundary is called the event horizon, and its radius is given by the Schwarzschild equation:
Rs = 2GM / c²

text

Here, G is the gravitational constant, M is the mass of the black hole, and c is the speed of light. It is a deceptively simple equation. Three variables. No calculus. No tensor fields. And yet, it describes the point where space and time break down.

When we plug in real numbers, something remarkable happens. If we compressed the entire Earth into a sphere, its Schwarzschild radius would be just 8.87 millimetres. That is smaller than a marble. The Sun, compressed, would have an event horizon of about 2.95 kilometres — no larger than a small city.

This is the first lesson of black hole physics: the universe is far stranger than it appears.

Three facts that break your intuition

When I first started reading about black holes, I assumed they were simple. A massive object, a strong gravitational pull, and a boundary you cannot cross. But as I went deeper, three ideas in particular challenged everything I thought I understood.

First, time slows down near a black hole. This is not science fiction. It is a direct consequence of general relativity, and it has been experimentally verified. GPS satellites orbiting Earth adjust their clocks every day to account for this effect. Near an event horizon, the dilation becomes extreme. An hour spent close to a black hole could correspond to years on Earth.

Second, black holes spin. Most of them rotate at speeds close to the speed of light. The singularity at the center — usually imagined as a point — becomes a ring. Space itself gets dragged along with the rotation, a phenomenon known as frame dragging. In some ways, this is more difficult to picture than the black hole itself.

Third, black holes are not permanent. In 1974, Stephen Hawking demonstrated that black holes emit radiation and slowly lose mass over time. A stellar-mass black hole would take approximately 10⁶⁷ years to evaporate completely. For comparison, the universe is only 10¹⁰ years old. We are safe — for now.

Each of these facts is counterintuitive on its own. Together, they suggest something profound: the universe does not have to make intuitive sense. It only has to follow the math.

Watching physics come alive through code

Reading about gravitational lensing is one thing. Watching it happen is another. Gravitational lensing is the phenomenon where light bends around a massive object — and in the case of a black hole, it bends so severely that some light never escapes.

To visualize this, I wrote a short Python script. The goal is not to accurately simulate general relativity. That would require solving Einstein's field equations, which is far beyond what a simple script can handle. Instead, the goal is to approximate the bending of light around an event horizon, so that the phenomenon becomes visible to the eye.

Before running the code, install the two necessary libraries:


bash
pip install numpy matplotlib
Then, the script below will compute event horizon sizes for three real objects and render a visualization of light rays bending near a black hole.

python
import numpy as np
import matplotlib.pyplot as plt

# Constants
G = 6.674e-11
c = 3e8

def schwarzschild_radius(mass):
    """Event horizon radius in meters."""
    return (2 * G * mass) / (c ** 2)

# Masses in kg
earth = 5.972e24
sun = 1.989e30
sagittarius_a = 8.6e36  # supermassive black hole at Milky Way center

print("Event horizon sizes:")
print(f"Earth compressed  → {schwarzschild_radius(earth)*1000:.2f} mm")
print(f"Sun compressed    → {schwarzschild_radius(sun)/1000:.2f} km")
print(f"Sagittarius A*    → {schwarzschild_radius(sagittarius_a)/1e9:.2f} million km")

# Gravitational lensing visualization
fig, ax = plt.subplots(figsize=(8, 8))
ax.set_facecolor('black')
ax.set_xlim(-10, 10)
ax.set_ylim(-10, 10)

# Light rays bending around the black hole
for y in np.linspace(-8, 8, 25):
    x = np.linspace(-10, 0, 200)
    bend = -2 / (1 + np.abs(y) ** 2)
    y_bent = y + bend * (x + 10) / 20
    ax.plot(x, y_bent, color='#ffcc00', alpha=0.4, linewidth=0.7)

# Event horizon
ax.add_patch(plt.Circle((0, 0), 1, color='black', zorder=10))
ax.add_patch(plt.Circle((0, 0), 1.05, color='#ff6b6b', fill=False, linewidth=2))

ax.set_title("Gravitational Lensing Around a Black Hole",
             color='white', fontsize=14, pad=20)
ax.set_xticks([])
ax.set_yticks([])

plt.tight_layout()
plt.show()
When you run this script, you will see something remarkable. The yellow lines represent light rays travelling through space. As they approach the black hole, they begin to curve. The ones that pass closer to the center bend more sharply. Some of them spiral inward and never emerge. The red circle marks the event horizon — the boundary of no return.

This is not a full simulation of relativity. But it captures the essential idea: mass curves space, and light follows the curve.

Why this matters beyond the black hole
In 2019, the Event Horizon Telescope captured the first real image of a black hole — the supermassive object at the center of the galaxy M87. The image looked exactly like the mathematical models had predicted.

Consider what that means. Long before we had the technology to observe a black hole, we knew what it would look like. Because the math told us. Because Einstein's equations, written over a hundred years ago, described something that nobody could see.

This is the power of physics. And this is why I write code — not to replace physics, but to see it in motion.

When I was younger, I used to think that mathematics was a tool for solving problems. Now I understand that it is something much more. It is the language the universe uses to describe itself. Black holes are not anomalies in this description. They are the most extreme examples of it.

What comes next
I am still learning. I am sixteen, and I have barely scratched the surface of what there is to know about general relativity, quantum mechanics, or computational physics. But every simulation I build, every equation I implement, every graph I plot, takes me one step deeper into the subject.

If you are also interested in physics and programming, I would encourage you to do the same. Pick an equation. Pick a phenomenon. Try to simulate it. Break it. Fix it. Change the parameters and watch what happens. That is how understanding grows.

You do not need a supercomputer. You do not need a degree. You need curiosity, and a willingness to sit with confusion until it becomes clarity.

That is all physics has ever required.

If you build something similar, let me know. I would love to see it.

GitHub: github.com/yashmatrani-cpu/My-Projects

Gumroad: yashmatrani.gumroad.com

I am sixteen. Still learning. Sharing what I build.

Tags: #python #physics #science #beginners

How I built a symbolic log inequality solver as a 16-year-old

Yash Matrani — Mon, 12 Oct 2026 12:38:37 +0000

Logarithmic inequalities are annoying.

Not because they're hard — but because most solvers skip the domain constraints. They give you the answer, you trust it, and then you realize the base was invalid the whole time.

So I built my own. In Python. Using SymPy.

I'm 16, and this is my first serious symbolic math project.

The Problem

Variable-base log inequalities like:
log(x-1)(x+1) < 2

Here the base itself is (x-1), which means:

Base must be > 0
Base must ≠ 1
Argument must be > 0
Then solve the inequality

Most online solvers:

Skip domain constraints
Assume base > 1 only
Miss the 0 < base < 1 case
Return wrong or incomplete answers

I got tired of checking manually. So I wrote a script that does it properly.

The Approach

Using SymPy's solve_univariate_inequality, the script:

Extracts free symbols from the base
Splits into cases: base > 1 and 0 < base < 1
Applies domain constraints (base > 0, base ≠ 1)
Solves each case symbolically
Returns the union of solution sets

Here's the core logic:


python
import sympy as sy

x = sy.Symbol('x')

def base_A(base):
    if x in base.free_symbols:
        return sy.solve_univariate_inequality(
            sy.And(base > 0, base != 1),
            x,
            relational=False
        )
    else:
        return base
The rest handles case splitting, domain checks, and union of intervals.

What I Learned
1. Symbolic math is different from numerical.
math.sqrt(2) gives 1.414.... SymPy gives sqrt(2) — exact.

2. Domain constraints matter more than the equation.
Most people solve the inequality, forget the domain, and get it wrong.

3. Edge cases break everything.
Base = 1? Base = 0? Base negative? Each one is a different failure mode.

4. SymPy is underrated.
Python devs use it for scripts. It's built for math.

What's Next
Add support for nested logarithms

Build a CLI interface with argument parsing

Maybe a web version with Streamlit

Links
Source code: Gumroad

GitHub: github.com/yashmatrani-cpu/My-Projects

X: @Developervxku

I'm still learning. Feedback welcome — especially from anyone who's worked with SymPy or symbolic solvers.

Thanks for reading.