DEV Community: Aditya Sorathiya

goodAPI — An API Monitoring Dashboard Built with FastAPI, Render, and MongoDB Atlas

Aditya Sorathiya — Sat, 17 Oct 2026 17:13:52 +0000

Meet goodAPI,an API monitoring dashboard designed to help developers test endpoints, monitor HTTP responses, track response times, and understand API issues with AI-powered explanations.

Built with FastAPI, MongoDB Atlas, and a Netlify-hosted frontend, goodAPI demonstrates a practical use of modern cloud infrastructure.

🚀 Highlights:

Render: Hosts the FastAPI backend and provides a straightforward way to deploy and run the API.
MongoDB Atlas: Stores user accounts, API monitors, and monitoring results in a cloud-hosted database.
API monitoring: Test endpoints, check HTTP status codes, measure response times, and compare results against expected status codes.
AI-powered explanations: Uses Groq to explain API responses and suggest debugging steps.
Authentication: Google sign-in and protected, user-specific monitors.
Netlify: Hosts the frontend separately from the backend.

Demo at: https://goodapi.netlify.app
GitHub: https://github.com/sorathiya903/healthy-api

The goal is to make API testing, monitering and debugging more accessible while demonstrating how Render and MongoDB Atlas can work together in a real-world developer tool.

Built as an independent student developer project. Feedback and suggestions are welcome!

I built an AI game that forces you to close this tab and go outside 🌿 (Built with Client-Side WASM)

Aditya Sorathiya — Thu, 08 Oct 2026 13:09:29 +0000

Every developer knows the feeling. You sit down to solve "one quick bug," and suddenly it's 11:00 PM, your eyes are bloodshot, and you haven't seen a tree in three days.

As a Class 10 student developer, I wanted to build something for the Hacktoberfest Week 1 "Touch Grass" challenge that addresses this head-on. Most software is engineered to trap your attention inside a viewport. I wanted to build an app where the screen's only job is to get you away from it.

Introducing NatureMate — Touch Grass Edition.

🎮 Live Game: https://naturemate.netlify.app
📂 GitHub Repository: https://github.com/sorathiya903/nature-mate

🎮 How the Game Works

Instead of generating a boring digital checklist, NatureMate turns the real world into an active gaming arena:

Accept a Quest: The app randomly generates a real-world object for you to discover (a bicycle, a bench, a dog, a backpack).
Step Outside: You actually have to stand up, open your door, and walk into your neighborhood or local park.
Point & Verify: Use your mobile browser's camera to capture a frame of the target object.
On-Device AI Verification: A localized computer vision model reviews the frame and rewards you with XP, coins, and streak multipliers if you found it!

🧠 Architecting Client-Side AI (No API Keys, Zero Server Costs)

When planning this app, I wanted to avoid a bulky cloud backend. Pulling inspiration from my previous encrypted project ecosystem (PasteDB), privacy and speed were my main priorities.

Instead of routing camera frames to an external API, NatureMate handles machine learning entirely inside the browser's execution thread:

The Engine: Built cleanly using Astro, modern CSS variables, and vanilla JavaScript.
The Core ML Layer: Powered by Transformers.js bound to an ONNX Runtime Web / WebAssembly (WASM) layer.
The Model: A lightweight, quantized YOLOS-tiny model that maps out 43 distinct object classes directly inside your device's memory footprint.

Because the analysis is 100% local, it functions seamlessly on mobile browsers without lagging out your cellular data or logging your camera stream to a server.

🚀 Gamifying Healthy Habits

To keep loops interesting, I built in real arcade mechanics:

❤️ 3 Lives System: Skipping an unachievable object drops a life. Failing a snapshot doesn't. Hit 0 lives, and it's Game Over.
⏱️ Touch Grass Run: A separate 10-minute sprint challenge where you are tasked with identifying a specific subset of objects before the countdown clock self-destructs.

🤝 Let's Connect!

I would love to get your feedback! Open up the live link on your phone, step outside your room for five minutes, and let me know if the model tags your targets correctly.

If you like the architecture, feel free to drop a ⭐ on the GitHub Repo or open an issue if you want to help me add custom object classes!

Your Screen Can Have One Job: Get You Outside

Aditya Sorathiya — Thu, 08 Oct 2026 10:02:52 +0000

I Built a Game That Wants You to Stop Playing It

We've spent the last decade getting really, really good at making apps that keep you staring at your phone.

Infinite scroll, autoplay, streaks that punish you for leaving. Everything is optimized for time-on-screen.

So I had a dumb thought: what if I built one that does the opposite?

The phone gives you the quest, but you have to look away from the phone to finish it. If you keep staring at the screen, you lose.

That's how NatureMate — Touch Grass Edition started.

Live demo: https://naturemate.netlify.app
GitHub: https://github.com/sorathiya903/nature-mate/

The weird idea

The core loop is intentionally backwards.

Most games are: screen -> eyes on screen -> reward.

NatureMate is: screen -> eyes OFF screen -> reward.

I open the app and it says:

Find a bench outside.

That's it. That's the quest.

I can't tap the bench. I can't buy the bench. I have to physically get up, go outside, and find a real bench in the real world. The phone becomes the quest giver, and the street becomes the game board.

It's a small shift, but it changes how you walk. You start noticing things. "Oh, there's a fire hydrant. I didn't know we had one on this street."

So what do you actually do?

It’s stupidly simple, which is why it works on mobile.

You get one quest: Find a bicycle outside.
You go outside.
You point your camera at a bicycle.
You press Capture & Verify.
On-device AI checks that one frame and says yes or no.

If it says yes:

✓ THING FOUND! bicycle detected — 84% — +50 XP +16 🌱

You get XP, coins, your streak goes up, and that object is gone forever. You’ll never get “bicycle” again in this run.

If it says no:

Not quite... I couldn't confidently find a bicycle.

No life lost. You just try again from a better angle.

That’s the whole game. One quest at a time. 43 possible things to find. No repeats.

The interesting technical part

I didn't want to send camera frames to a server. That feels creepy for a game that asks you to point your camera at the real world, and it would be laggy outdoors.

Everything runs in the browser with Transformers.js.

The model is Xenova/yolos-tiny — a tiny YOLOS object detection model quantized to q8 so it actually loads on a phone. It's about 24MB, cached after the first load.

detector = await pipeline("object-detection", "Xenova/yolos-tiny", {
 dtype: "q8",
 progress_callback: handleProgress
});

The most important rule I set for myself:

CAMERA PREVIEW ≠ AI INFERENCE

The video element is just a preview. No detection runs while you’re walking around. Only when you press Capture does it do this:

canvas.drawImage(video, 0, 0, w, h);
const dataUrl = canvas.toDataURL("image/jpeg", 0.65);
const results = await detector(dataUrl, { threshold: 0.20 });

One button press = one frame = one inference. That’s it. It keeps the phone cool, saves battery, and feels intentional — you’re choosing to ask the AI “is this it?”

YOLOS is trained on COCO, so it can actually detect 80 real things. I limited the game to 43 that make sense outdoors and that the model can reliably see: bench, bicycle, car, person, dog, chair, bottle, potted plant, bus, truck, motorcycle, bird, cat, backpack, umbrella, frisbee, skateboard, traffic light, stop sign, kite... you get the idea.

I really wanted “tree” but COCO doesn’t have tree. So potted plant is the closest we get. I kept the display names separate from detector labels so I don’t lie about what the AI is checking:

{ id: "potted plant", detectorLabel: "potted plant", title: "plant" }

If the model says bench with >30% confidence, you pass. If not, you don’t. No faking.

Why lives and no repeats?

Early versions felt like a demo, not a game. You could just spam “skip” until you got an easy one.

So I added constraints that make it feel like an adventure:

3 lives. Shown as SVG hearts. Skipping a quest costs exactly one life. Failing detection costs zero.
No repeats, ever. Found it? It goes into foundObjects. Skipped it? Into skippedObjects. Both go into usedObjects. The next quest is always OBJECTS.filter(o => !usedObjects.has(o.id)). Guarantee.
43 unique targets. So you can actually “complete” it. Progress is 12 / 43 FOUND, not an endless loop.
XP, coins, streak. Small dopamine hits, but the real reward is you went outside.

The no-repeats rule changed everything. It stopped being “find a chair again” and started feeling like a collection journal. You’re not grinding, you’re clearing the map.

Touch Grass Run

This is my favorite mode.

You press 🏃 Touch Grass Run and normal mode pauses completely. Separate state, separate timer, no contamination.

You get 6 random targets and 10 minutes:

10:00 — Find: bench, car, dog, bottle, kite, bus

Same camera, but now it’s checking against the Run target, not your main quest. One capture can knock out multiple Run items if they’re in the same photo. Find all 6 before the timer hits zero and you get a little arcade-style win screen.

When Run ends — whether you win, time out, or hit Exit — your normal adventure is restored exactly where you left it. No lives lost, no objects marked as found unless you actually found them in normal mode.

Building that isolation was the hardest bug hunt. At first Run was modifying foundObjects and people would lose quests permanently. Now it’s state.runMode boolean: if true, Capture goes to the Run path, Skip is disabled.

Building it wasn’t completely straightforward

A few things that actually bit me:

1. Mobile browsers are picky. iOS Safari will kill your camera stream if you don’t playsinline and muted, and it hates multiple getUserMedia calls. One stream, reuse it.

2. Model loading UX. On 4G, 24MB feels big. I had to build a real progress bar from progress_callback — loaded/total per file — instead of fake percentages. The steps “Loading AI engine → Downloading model → Caching → Preparing camera → Adventure ready” actually reflect real events.

3. Stale state. Capture is async. If you generate a new quest while inference is running, you could compare results against the new quest. Fix: capture the quest at the start:


const questAtCapture = state.quest;
//... await detector()
if (state.quest !== questAtCapture) return; // game was reset

4. Busy lock. Without a busy flag, people double-tap Capture and get double XP. Now it’s if(busy) return + try/finally so the button never stays stuck.

None of these are groundbreaking ML problems. They’re just the unsexy mobile web problems that make a demo feel like a real product.

The part I like most

Most apps compete to keep you.

NatureMate uses 30 seconds of your attention to get rid of you.

The best session isn’t “I played for 2 hours.” It’s:

“I opened it, got ‘Find a bird’, went to the balcony, actually saw a bird, and closed the app.”

The longer you play, the less you should look at this page. That’s the point.

I built it because I wanted a reason to walk that wasn’t “close your rings” or “10k steps.” A little quest that makes you look up.

Try it

If you’re curious:

Live demo: https://naturemate.netlify.app
Repo: https://github.com/sorathiya903/nature-mate/

No account, no backend, no upload. Just open it on your phone, give it camera permission, and give it a quest.

Go outside. See if the AI agrees with you.

Building PasteDB: A Bulletproof Code-Sharing Platform Powered by FastAPI and OpenAI's gpt-oss-20b

Aditya Sorathiya — Sun, 04 Oct 2026 17:07:38 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built PasteDB, a lightweight code-sharing platform designed to make sharing code blocks seamless. To take it a step further for this challenge, I integrated an "Explain This Code" AI assistant layer.

Who I built it for: I built this feature specifically for my developer friends and peers who are learning to code. Often, when we share raw code snippets over chat platforms, beginners struggle to understand the core logic without context. PasteDB now automatically analyzes any shared snippet at the click of a button, acting as an on-demand mentor.

Demo

Live Link: https://pastedb.netlify.app
Backend API: https://pastedb-rw62.onrender.com

Code

Here is the official open-source repository for PasteDB:
https://github.com/sorathiya903/pastedb

How I Built It

PasteDB is engineered using a robust, free-tier distributed stack:

Frontend: Vanilla JavaScript, HTML and CSS hosted on Netlify
Backend: FastAPI (Python) hosted on a free-tier Render instance
Database: MongoDB Atlas

Overcoming Infrastructure Limits with Open-Weight AI

The biggest engineering hurdle was Render's strict 512MB RAM constraint on the free tier. Running even a small 350MB model locally on the backend would trigger an Out-of-Memory (OOM) crash once the Python dependencies and KV caches loaded.

To solve this, I decoupled the compute by making outbound streaming requests to Groq's cloud infrastructure to tap into the official open-weight OpenAI Model model. This leaves a 0MB memory footprint on Render while generating lightning-fast, structured Markdown explanations for the user.

Bulletproof Quota Protection

To protect my public API quota from malicious spam or heavy judging traffic, I engineered a zero-RAM, custom in-memory IP Rate Limiter directly inside the FastAPI routing layer. It limits users to 3 requests per minute per IP, protecting the app against HTTP 429 exhaustion while keeping the experience completely smooth and available for the judges.

# A snippet of my custom rate-limiter guarding the open-weight pipeline

Why Does Open Innovation Matter?

Open innovation was the entire foundation of this project. Relying on premium, closed-source corporate APIs forces developers into commercial paywalls, rigid token meters, and strict monetization loops from day one.

By utilizing open-weight ecosystem components like Llama 3.1, I was able to build a completely free, highly scalable utility tool for my friends. Open innovation democratizes AI execution, proving that independent developers can ship fully secured AI tools without a massive corporate budget.

Prize Categories

I am entering PasteDB into the following categories:

Grand Prize Category
Open-Source AI / Open-Weight Model Integration: I successfully deployed a 21B open-weight reasoning model pipeline (gpt-oss-20b) across a modern full-stack ecosystem consisting of Netlify (Frontend), FastAPI on Render (Backend), and MongoDB Atlas (Database). Offloading the inference compute allowed me to seamlessly integrate this open-weight powerhouse while staying perfectly within Render’s free-tier memory constraints.

I built an E2EE paste utility with 12K users (1,800+ commits). Is a local HTML/CSS/JS Android wrapper a good idea?

Aditya Sorathiya — Mon, 28 Sep 2026 14:49:14 +0000

Hey DEV community! 👋

I'm a 10th-grade self-taught developer, and for the past several months, I've been working as a one-man army (handling coding, testing, DevOps, and SEO) on my project: PasteDB.

To give you an idea of the scale, the ecosystem currently spans across a web interface, an npm CLI tool (pastedb-cli), two SDKs (Node.js/Python), and a live VS Code Marketplace extension. The core repository alone has over 1,800+ verified commits, and we just crossed 12,000+ active users completely organically.

🚀 Our Current Tech Stack (Running at ₹0)

Because I am a student, I've architected everything to run smoothly on cloud free-tiers with a strict ₹0 maintenance budget:

Frontend: Vanilla HTML, CSS, JavaScript (Hosted on Netlify)
Backend: FastAPI / Python (Deployed on Render's free tier)
Database: MongoDB Atlas (Free tier cluster) + Cloudinary for images

🔐 The Core Problem & Features

PasteDB isn't just a standard text dump. It features client-side End-to-End Encryption (E2EE) where encryption keys never touch my database server. It also supports automated "Burn After Read" pastes, an in-viewer code execution engine, automatic rolling version control history (up to 10 versions), and a 3-finger gesture-based Nearby Transfer protocol and many more…

📱 The Upcoming Milestone: A Native Android App

Now that my 1st-term school exams are wrapping up, my next major goal during vacation is to launch an official PasteDB Android App.

Because I want to minimize development time, maintain our tight browser-side cryptographic logic, and ensure the app loads instantly on slow networks, I am planning to build a Local Hybrid Architecture.

Instead of pulling the UI over the internet, my plan is to:

Embed our exact web index.html, style.css, and crypto-heavy script.js files directly inside the Android project's assets/ folder.
Build a lightweight Kotlin wrapper using Jetpack Compose.
Use Android's view container to render the UI entirely from local disk storage via loadUrl("file:///android_asset/index.html").
Point all fetch requests in the JS script to the absolute Render URL of our FastAPI backend.

This means no web browser layout is involved for the user, and the application interface will load instantaneously without costing a rupee in frontend bandwidth.

🤔 My Question to Senior Engineers: Is this a good idea?

Since this is my first time deep-diving into Android deployment, I want to know your thoughts on this approach. Specifically:

Security & Cryptography: Our client-side E2EE relies entirely on browser-based JS crypto execution. Will loading these scripts locally via file:/// inside an Android WebView introduce any native sandbox security leaks or quirks?
Performance Constraints: Are there significant performance penalties for letting local vanilla JS handle DOM updates inside a Kotlin wrapper compared to writing a completely native Kotlin UI?
Hardware Access: Will the local asset container successfully allow hardware-level access if I request native Android permissions (like Location/Bluetooth for our Nearby Transfer feature, or Camera access for scanning QR codes)?

I'd love to hear your feedback, architectural warnings, or library recommendations (should I stick to standard Android WebViews, or explore engines like QuickJS for the crypto backend?).

Drop your advice in the comments below! 👇

Hardware Limits Couldn't Stop Me From Building PasteDB

Aditya Sorathiya — Wed, 23 Sep 2026 09:49:41 +0000

I built PasteDB, an open-source developer tool, largely using a damaged bleeding smartphone. This is the story of building software despite hardware limitations and why imperfect hardware doesn't have to stop you from learning, coding, creating and SHIPPING.

The real image today (23/9/2026)

The image was clicked with my father's phone

I searched “pastebin cli” on Google... and i got my project??? 🔎

Aditya Sorathiya — Sun, 20 Sep 2026 14:33:41 +0000

One of those small milestones that feels surprisingly big. 🚀

I searched Google for:

pastebin cli

And PasteDB CLI appeared on the first page of results.

Google is showing:

“PasteDB CLI – Pastebin Command Line Tool for Developers”

The result appears below Google's AI Overview.

PasteDB is an open-source developer-focused paste platform I've been building, and the CLI lets developers work with pastes directly from their terminal.

It supports things like:

Create pastes
Read pastes
Update pastes
Delete pastes
Explore pastes
Work with the PasteDB API directly from the terminal

What makes this milestone exciting to me isn't just seeing my project's name in Google.

It's that someone searching for a generic term like “pastebin cli” can potentially discover a project I built.

It's a small SEO/discoverability milestone, but for an indie/student developer, these little moments are really motivating. 😄

PasteDB:
https://pastedb.netlify.app

GitHub:
https://github.com/sorathiya903/pastedb

Have you ever had a project unexpectedly start appearing for generic searches? I'd love to hear about it.

The API Worked Locally. Then Production Broke It. 💀

Aditya Sorathiya — Wed, 16 Sep 2026 11:58:31 +0000

┌──────────────────────────────────────┐
│ 🧪 API HEALTH CHECK                  │
├──────────────────────────────────────┤
│                                      │
│ 💻 Local                             │
│    GET /api/test                     │
│    → 200 OK ✅                       │
│                                      │
│ ☁️ Production                        │
│    GET /api/test                     │
│    → 500 Internal Server Error 💀    │
│                                      │
└──────────────────────────────────────┘

And that's where the debugging began.

Locally, everything was working exactly as expected. The API responded correctly, the frontend connected, and there were no obvious errors. But after deployment, something had changed.

So what broke?

You know that feeling when everything works perfectly on localhost?

The API responds.
The frontend gets the data.
Authentication works.
You test it five times.

So you deploy it.

And suddenly:

💥 500 Internal Server Error

Nothing changed.

Except… everything.

The classic situation

During development, I had something like:

Frontend → localhost API → Database

I tested the endpoint and got exactly what I expected.

{
  "success": true,
  "data": "Hello from the API"
}

Perfect.

Then I deployed the backend.

Frontend → Production API → Database

And the frontend started throwing errors.

The worst part?

The API worked when I tested some endpoints manually.

That made it even more confusing.

So what actually changed?

A production environment isn't just your local computer moved to the internet.

There are a lot of things that can be different:

Environment variables
CORS configuration
Database connection strings
HTTPS vs HTTP
Allowed origins
File paths
Case-sensitive filenames
Dependency versions
Python/Node versions
Proxy configuration
Authentication cookies
API URLs
Deployment-specific filesystem behavior

One tiny assumption in development can become a production bug.

One of my favorite examples: environment variables

Locally, you might have:

API_URL=http://localhost:8000

Everything works.

But your deployed frontend might still be trying to call:

http://localhost:8000

From the user's browser, localhost means their computer, not your server.

So your API isn't even being contacted.

That bug can be surprisingly easy to miss if you're only testing locally.

Another one: CORS

You might test your frontend and backend locally with:

http://localhost:5500

and:

http://localhost:8000

Then production becomes:

https://myapp.com

and:

https://api.myapp.com

Your backend needs to know that the production frontend is allowed to make requests.

A configuration that worked locally isn't necessarily correct for production.

And then there's the database 😭

Your local machine might have:

mongodb://localhost:27017/mydb

Production obviously can't use your laptop's MongoDB.

So you replace it with a hosted database connection string.

Then you discover:

Authentication failed.

Or:

Connection refused.

Or:

Network access denied.

The API code itself might be completely fine.

The environment around it isn't.

The lesson I learned

When something breaks after deployment, don't immediately rewrite the endpoint.

First ask:

"What is different between local and production?"

I now mentally go through something like:

Environment variables
        ↓
API URL
        ↓
CORS
        ↓
Database
        ↓
Authentication
        ↓
Dependencies
        ↓
File paths
        ↓
HTTPS / proxy
        ↓
Production logs

Only after checking those do I start changing application code.

Production is a different environment

This is probably one of the biggest lessons I've learned while building web projects.

"It works on my machine" isn't the end of testing.

It's actually the beginning of a new type of debugging.

Local development tells you:

"The code can work."

Production testing tells you:

"The entire system works together."

And those are two very different things.

What's the strangest "works locally, breaks in production" bug you've encountered?

I'd love to hear the weird ones. 👇

My Computer Teacher Marked My Correct Answer Wrong — So I Investigated It

Aditya Sorathiya — Mon, 14 Sep 2026 16:32:49 +0000

My Computer Teacher Marked My Correct Answer Wrong — So I Investigated It

A few days before my Class 9 annual exams, something happened during a computer science test that I still remember.

It wasn't a huge incident. It was just one MCQ worth one mark.

But that one mark taught me something much more valuable: being a student doesn't mean you should stop questioning an answer when you have evidence that something is wrong.

Note: This story is completely unrelated to my PasteDB project. It is a personal experience from my Class 9 computer science test.

The 19/20

It was March, a few days before our Class 9 annual examinations.

Our computer science teacher conducted a 20-mark test containing 20 multiple-choice questions.

A few days later, we received our papers.

I got 19/20.

Everything looked normal until I reached Question 8.

The question was:

Which of the following is not a limitation of a mobile phone?

There were four options. I don't remember options A and B exactly, but the two relevant options were:

C. Memory

D. Network

I had selected D. Network.

But my answer had been marked wrong.

According to the answer key, C. Memory was considered correct.

I immediately wondered:

How could network not be a limitation of a mobile phone?

I decided to ask about it.

Going to the Staff Room

I took my computer paper and went to the staff room with two of my friends.

There were two teachers there — my computer teacher and my maths teacher.

One of my friends had come to discuss his maths paper. After his discussion was finished, he left.

My other friend stayed with me.

I showed my computer teacher Question 8 and asked whether my mark could be reconsidered.

Initially, she didn't change it.

Instead, she opened the textbook to check the topic.

She was looking through one chapter, but I remembered that the relevant topic was actually in another chapter. I pointed that out.

Eventually, she found the question in the textbook exercise.

And that's where the real discussion started.

The Debate

My teacher believed that Memory was the answer.

I explained why I believed Network was the correct answer.

My reasoning was simple:

A mobile phone depends on network connectivity for many communication-related functions. Lack of network connectivity can therefore be a limitation.

Meanwhile, I didn't understand how memory itself could be considered the answer to a question asking what is not a limitation.

We went back and forth for quite some time.

I wasn't trying to disrespect my teacher.

I simply couldn't make the explanation fit with what I understood from the textbook.

Eventually, after the discussion had gone on for quite a while, my teacher increased my mark.

So I got my 20/20.

I thought that was the end of it.

It wasn't.

My Friend Had the Same Answer

The next working day, my friend came to me.

He had also selected D. Network.

He told me that he should receive the mark too.

I agreed.

But I suggested something slightly different.

Instead of simply asking the teacher to give him the mark, I told him to ask:

"If this exact question appears in the annual examination, which option should we select?"

That question mattered.

Because getting one mark back was one thing.

Knowing the correct answer for the actual examination was much more important.

My friend asked the teacher about it.

The answer he got was still C. Memory.

And I couldn't understand it.

If the question appeared in our annual exam, I didn't want to knowingly select an answer I believed was technically incorrect.

Taking the Question to the Principal

It was examination time, so teachers were busy with invigilation and other responsibilities.

My friend's paper wasn't resolved immediately.

So I decided to ask someone else.

I went to the principal during dispersal.

I explained that I had a doubt regarding a previous computer science unit test.

At first, the principal was understandably annoyed because it was exam time and I was bringing up an old test.

But once I explained the actual issue, she said that it would be clarified.

I went home.

And instead of just thinking about the argument, I did something more useful.

I started looking for evidence.

I Went Back to the Textbook

I searched through the textbook again.

This time, I wasn't looking for something that would simply prove me right.

I was looking for the actual explanation of the concept.

And then I found it.

There was a line in the textbook that supported my interpretation of the question.

That was important.

Now I wasn't relying only on my memory or opinion.

I had a source.

The Next Day

When I came to class the next day, my class teacher asked me about the situation.

She knew that I had taken the question to the principal.

I explained what had happened.

Then she checked the question independently.

The answer she got was:

D. Network.

I also showed her the relevant line from the textbook.

At that point, there was evidence from the textbook supporting my answer as well.

The issue was finally clear.

The original answer I had been marked wrong for was actually the answer I should have received credit for.

What I Learned From One Mark

Looking back, the most important part of this story isn't that I got one additional mark.

It's what happened while trying to resolve the disagreement.

I learned that authority doesn't automatically make an answer correct.

A teacher can know far more about a subject than a student and still make an occasional mistake.

A textbook can contain an unclear question.

An answer key can be wrong.

And a student can misunderstand something.

That's why evidence matters.

Don't Argue Just to Prove Yourself Right

There's an important distinction here.

I'm not saying students should challenge teachers about everything.

And I'm definitely not saying that students should assume their teachers are wrong.

Instead:

If you believe something is technically incorrect, investigate it.

Don't just say:

"I'm right."

Ask:

"What does the textbook say?"

"What does the documentation say?"

"Can I find another reliable source?"

"Can I explain why I believe this answer is correct?"

That changes an argument into an investigation.

The Internet Makes This Even More Important

As someone who enjoys computer science and software development, I've started noticing this even more.

In technology, you can't always rely on someone's authority.

A person might confidently tell you that an API works one way.

The documentation might say otherwise.

Someone might tell you a programming concept is impossible.

You might test it and discover that it isn't.

Someone might tell you that a particular piece of code is correct.

Running it might prove otherwise.

That's why one of the most valuable skills for a developer is learning to verify information.

What Would You Have Done?

If you were in my situation, what would you have done?

Would you have:

Accepted the answer and moved on?

Asked the teacher again?

Checked the textbook?

Looked for another reliable source?

Asked another teacher?

Taken the issue to the principal?

For me, the biggest lesson wasn't getting 20/20.

It was learning that asking questions respectfully and finding evidence can be more powerful than simply arguing.

And sometimes, the answer really is worth investigating.

I’m a Student Developer. Is Building Projects Actually Better Than Following Tutorials?

Aditya Sorathiya — Mon, 14 Sep 2026 15:33:10 +0000

I've spent the last few months building and maintaining my own projects instead of constantly jumping between tutorials.

It has been frustrating sometimes. I've had bugs that took hours to understand, deployments that broke, features that I later had to rewrite, and projects that nobody used.

But I've also learned things that I don't think I would have learned by simply completing tutorials.

So I'm curious:

For someone learning development, what do you think is more valuable — building projects or following structured courses?

I Just Made PasteDB Pasts Editable Directly Inside VS Code 🚀

Aditya Sorathiya — Mon, 14 Sep 2026 05:07:02 +0000

I just released PasteDB VS Code Extension v0.3.0, and this update adds one of the features I wanted most: Update Paste. You can now open an existing PasteDB paste in a VS Code editor, edit it like normal code, and update it with Ctrl + Shift + U — without going back to the browser. In this post, I'll share how I redesigned the update workflow and why I chose an editor-first UX.

PasteDB VS Code Extension
PasteDB on GitHub
PasteDB

Making PasteDB Easier to Read: Word Wrap & Font Size Controls

Aditya Sorathiya — Fri, 11 Sep 2026 15:57:51 +0000

Hey everyone! 👋

I'm Aditya, a student developer, and I'm building PasteDB — a paste-sharing platform for code, text, notes, logs, and more.

While using PasteDB myself, I noticed a small but annoying problem.

If a paste contained a very long line, the viewer would require horizontal scrolling.

That isn't a huge problem for code, but for normal text, notes, documentation, or things like copied questions, it can make reading pretty uncomfortable.

So I decided to improve the viewer.

📝 Introducing Word Wrap

PasteDB's viewer now has a Word Wrap option.

When word wrap is disabled, long lines stay on a single line:

This is a very long line that continues and continues and requires horizontal scrolling...

When enabled, the same content can automatically wrap inside the viewer:

This is a very long line that continues
and continues and now wraps naturally
inside the available space.

The important part is that this is soft wrapping.

The actual paste content isn't modified.

So copying the paste still gives you the original content exactly as it was.

🔤 Font Size Control

I also added a font-size slider.

Instead of having only one fixed font size, you can adjust the viewer to whatever feels comfortable.

Something like:

Small  ────────●─────────  Large
                 16px

The selected size is applied to the paste viewer and the output area as well.

This is particularly useful when viewing PasteDB on different screen sizes.

⚙️ Why I put them inside "More Options"

Initially, I considered putting both controls directly in the toolbar.

But the PasteDB viewer already has several actions:

Copy
Raw
Images
Run
Nearby Share

Adding two more buttons would make the toolbar increasingly crowded, especially on mobile.

So I decided to keep the main actions visible and put the reading controls inside a More Options menu.

That keeps the interface cleaner while still making the settings easy to access.

💾 Your preference is remembered

I didn't want users to have to enable Word Wrap every time they opened a paste.

So PasteDB stores the preferences locally using localStorage.

For example:

localStorage.setItem(
  "pastedb_word_wrap",
  "true"
);

And the font size is stored similarly.

This means your viewer preferences can persist between paste views without requiring an account or changing the actual paste.

🛠️ A small technical challenge

Getting word wrapping to work properly wasn't just adding:

white-space: pre-wrap;

PasteDB's viewer uses <pre>
and <code> elements, and the <pre> originally had a min-width based on the content.

That meant a very long line could force the code block to become wider than the screen.

So the important part was allowing the code block to shrink to the available width:

pre {
    width: 100%;
    max-width: 100%;
    min-width: 0;
}

Then the code itself can wrap:

code {
    white-space: pre-wrap;
    overflow-wrap: anywhere;
}

Without fixing the width behavior, the "word wrap" setting doesn't really feel like word wrap.

🎯 Why these small features matter

This isn't a huge feature.

It's basically two viewer settings.

But I think these are the kinds of small improvements that make a product feel much better to use.

PasteDB isn't only used for code. You can paste:

📝 Notes
💻 Source code
📋 Logs
📄 Long text
📚 Documentation
🔗 Links
🖼️ Images
🔐 Private/encrypted content

So the viewer needs to work well for more than just programmers looking at code.

🚀 What's next for PasteDB?

I'm continuing to improve PasteDB and add features based on things I actually need while using it.

Some of the things I've already worked on include:

Syntax highlighting
Markdown preview
Custom URLs
Paste expiration
Password-protected pastes
Image pastes
QR sharing
Nearby transfer
Version history
API access
End-to-end encrypted pastes
A built-in code runner

And there are still a lot more ideas I want to experiment with.

💬 I'd love your feedback

If you use PasteDB, I'd love to know:

What would you improve about the viewer?

Is there a feature that would make reading or sharing pastes easier?

I'm especially interested in small UX improvements like this one.

Thanks for reading! ❤️

PasteDB: https://pastedb.netlify.app

GitHub: https://github.com/sorathiya903/pastedb

The cover image is AI generated
The real UI is like

The UI may change after time