Sumit Jha

I just got an email offering $500 to acquire ShipCheck.site. Honestly, I don't even know how to feel about it yet. I don't know whether it is fake or real. But I know one thing: I'm not ready to sell. I have much bigger plans for this product, and I feel like I've barely scratched the surface.

When I first learned pagination, OFFSET and LIMIT seemed like enough. For example, if you want to fetch 20 records from a database, you can simply use: "LIMIT 20 OFFSET 100" But there's a problem when your table grows. Imagine your table has 1 million records and someone requests page 5,000. The database still has to scan and skip a large number of rows before returning the next 20 records. That's where cursor-based pagination comes in. Instead of asking for records by page number, you ask for the next 20 records after the last record you received. For example: "WHERE id > last_seen_id" "ORDER BY id" "LIMIT 20" This avoids repeatedly skipping thousands of rows and works much better for large datasets. There's another benefit: when new records are inserted, your pagination is less likely to skip or repeat records because page boundaries aren't based on a changing offset. My takeaway: Use OFFSET pagination when you're dealing with small datasets and need page numbers. Use cursor pagination when building feeds, activity logs, or large datasets where performance matters. The important thing isn't just knowing how to paginate, but understanding what the database actually does behind the query.

AI ka future predict kar rahe the, apna present nahi sambhal paaye 💀😂

We've reached the point where a startup can raise $5 million with an Al demo and zero paying customers. Meanwhile, a profitable small business gets called boring because it doesn't have an Al strategy. Apparently, making money is old-fashioned. Losing millions while promising to change the world is innovation.

A small piece of advice for every indie hacker building a SaaS: Don't wait until launch day to think about your website quality. Before announcing your product, spend 15 minutes checking these things: 1. Broken links: Test your navigation, footer links and important CTAs. One dead link can cost you a potential customer. 2. Page metadata: Give every important page a meaningful title and meta description. 3. Social previews: Share your URL privately on platforms like LinkedIn or X. Check whether the correct title, description and image appear. 4. Image accessibility: Add descriptive alt text to meaningful images. 5. Heading structure: Keep your H1, H2 and H3 hierarchy logical. Don't use headings just to make text bigger. 6. Mobile experience: Open your website on your phone. Check buttons, navigation, spacing and horizontal scrolling. 7. Search readiness: Make sure search engines can discover and understand your important pages. One more thing: Don't assume everything is fine just because your homepage looks beautiful. Your website is often the first interaction someone has with your product. Treat it like part of your product, not just a landing page. If you want to automate some of these checks, you can try shipcheck.site. Most features are free to try. Build, test, fix, then launch.

Read the full error message before touching any code. It often tells you the file, the line and the reason.

Someone writes a script that hits your login endpoint thousands of times a minute. Your API can't tell that apart from real users. Unless you add rate limiting. Here's how it works, simply. Rate limiting means each client gets a fixed number of requests in a time window. Go over it and you get a 429 Too Many Requests instead of a response. A "client" can be an IP, a user ID or an API key. Pick based on who you're protecting against. Two common ways to count: Fixed window: reset the counter every minute. Simple, but a burst at the edge of two windows can sneak in double. Token bucket: tokens refill at a steady rate and each request spends one. Short bursts are fine, the rest gets smoothed out. A few things that catch people: Counting in app memory breaks once you run more than one server. Keep counters somewhere shared, like Redis. Send a Retry-After header so clients know when to try again. Limit login and signup harder than normal reads. Rate limiting isn't only about attackers. It also saves you from your own buggy frontend stuck in a retry loop. Cheap to add early. Painful to add after something goes down.

Webhooks vs APIs. I used to think both were doing the same thing. Imagine you're building a payment application. A customer makes a payment. Now your backend needs to know whether the payment was successful or not. There are two ways to handle this. The API way: Your backend keeps asking the payment provider: "Is the payment completed?" "How about now?" "Any update?" You're basically checking again and again until you get the answer. This is called polling. The Webhook way: Instead of asking again and again, you tell the payment provider: "Whenever a payment is successful, just notify my server." Now the customer makes a payment. Stripe processes it and sends an HTTP POST request to your webhook endpoint with the payment event. Your backend receives it, verifies the signature and processes the event. No need to keep asking for updates. So what's the actual difference? API: Your application initiates the communication. Webhook: Another service notifies your application when an event happens. One more thing worth understanding as a backend developer: Receiving a webhook doesn't mean you should blindly process it. You need signature verification, idempotency and proper retry handling because the same event can reach your server more than once. I'm currently going deeper into backend engineering while building projects and exploring how things actually work behind the scenes. The more I learn about APIs, webhooks, queues and distributed systems, the more interesting backend engineering becomes. Honestly, this is the part of software engineering that excites me the most. And I have a lot more to learn.

Whenever I start building a new project, I don't open VS Code or Cursor and start writing code immediately. Before writing a single line of code or creating the folder structure, I sit down with my notebook and plan the product. Here's what I figure out first: - Problem: What problem am I solving? - Target Users: Who exactly will use this product? - Tech Stack: Which technologies make sense and why? - System Architecture: How will the overall system be structured? - HLD & LLD: How will components interact, and how will individual modules work? - Database Design: What data do I need, and how will it be stored? - API Design: What endpoints do I need? What will the request, response, authentication and error handling look like? - Folder Structure: How should I organise the codebase? - Complete Flow: What happens from the user's first action to the final result? - UI Mockups: I use v0 to visualise the interface before implementation. I document everything in my notebook until I have a clear picture of what I'm about to build. Currently, I'm following this process with WebhookOps - a backend automation platform that helps developers manage, monitor, retry, and debug webhooks with reliable event delivery and real-time visibility. Only after this planning do I open Cursor, set up the project and start writing code. AI makes coding faster, but understanding the problem, designing the system and making the right technical decisions are still my responsibility. Plan first. Code second.

One thing I pay more attention to when building backend APIs now is error handling. A successful API response is easy to handle. But what happens when: - MongoDB is unavailable? - A third-party API times out? - The user sends invalid data? - A request succeeds but the response never reaches the client? Good backend code isn't just about handling the happy path. It's about knowing what can go wrong and deciding how your system should respond.

Building a SaaS taught me something that tutorials rarely cover. Finishing the product is not the difficult part. Getting someone to discover it, understand why they need it, trust it enough to try it, and eventually pay for it is a completely different challenge. A working product is an engineering achievement. A product people consistently pay for is a business.

You should run a website check before sharing your website with the world. Here are a few situations where Shipcheck.site can help: → Launching a new SaaS or portfolio? Check for broken links, missing metadata and heading issues. → Just redesigned your website? Make sure important pages and images aren't broken. → Working on SEO? Find technical issues that might affect how search engines understand your pages. → Sharing your website on social media? Check whether your pages have the right social preview metadata. → Managing multiple client websites? Find issues before your clients or their visitors do. → Preparing for a product launch? Run a quick health check before announcing it everywhere. I built Shipcheck.site to make these checks easier without manually going through every page. You can try most of its features for free. No need to take my word for it. Put your website through it and see what you find. Try: shipcheck.site

Your user taps "Pay" and the network drops. The app retries. Did they just get charged twice? That's the problem idempotency solves. Quick breakdown. Idempotent means doing the same request once or five times leaves the system in the same state. GET, PUT and DELETE are meant to be idempotent. POST usually isn't. Every call can create something new. The common fix is an idempotency key. The client creates a unique ID for the action and sends it in a header. The server saves the key with the result. Same key again? Return the saved result instead of running it twice. A few things to get right: save the key and result together, atomically expire old keys after a sensible window same key with a different body? reject it handle two requests with the same key arriving at once Retries are normal. Networks fail, users double click, queues redeliver. Design your writes so running them twice is safe, and a whole class of weird production bugs just never shows up.

A question for developers who got their first job without a strong college placement network. How did you actually get your first opportunity? Cold emails, LinkedIn, referrals, GitHub, job portals or something else? I'm more interested in what genuinely worked than the usual advice to just keep applying.

Build the boring version first. No animations. No dark mode. No fancy dashboard. Just the one thing your project is supposed to do, working end to end. Polish feels productive. A working core actually is.

One thing I've realised while building backend projects is that implementing login and signup is the easy part. Understanding what actually happens behind the scenes is where things get interesting. I've been reading documentation, technical articles, watching YouTube videos and exploring these concepts with ChatGPT to understand authentication and authorization better. Here are 7 concepts I've been learning: 1. Sessions & Cookies When a user logs in, the server creates a session and sends a session ID to the browser through a cookie. The browser sends that cookie with future requests, allowing the server to recognise the user without asking them to log in again. 2. JWT (JSON Web Token) Instead of maintaining a traditional server-side session, the server can issue a signed token containing user claims. The client sends this token with API requests, and the server verifies its signature. One important thing: JWT payloads are not encrypted by default. Anyone who gets the token can decode its contents. 3. Access & Refresh Tokens An access token is used to access protected APIs and usually has a short expiry time. A refresh token has a longer lifetime and is used to obtain a new access token when the old one expires. This way, users don't have to log in repeatedly. 4. SSO (Single Sign-On) Imagine logging into your Google account and then accessing Gmail, Drive and other connected services without signing in separately. That's the basic idea behind SSO. A central identity provider handles authentication for multiple applications. 5. OAuth 2.0 Imagine an application wants to access your Google Photos. Instead of asking for your Google password, it redirects you to Google, where you approve the requested permissions. The application then receives an access token to access the permitted resources. That's delegated authorization. 6. OpenID Connect (OIDC) I initially thought OAuth 2.0 and OIDC were the same thing. But they're different. OAuth 2.0 handles authorization, while OIDC adds an identity layer on top of it. That's what makes features like Sign in with Google possible. 7. Authentication vs Authorization These two are easy to confuse. Authentication answers: Who are you? Authorization answers: What are you allowed to do? For example, logging into an admin dashboard proves your identity. Checking whether your account actually has admin permissions is authorization. A few other things I'm keeping in mind: - Passwords should never be stored as plain text. Use password hashing algorithms like Argon2id or bcrypt. - Cookies should have appropriate HttpOnly, Secure and SameSite settings. - Refresh tokens need proper protection, rotation and revocation. - A valid JWT doesn't mean the user has permission to access every resource. - APIs should validate permissions on the server, not just hide buttons on the frontend. I'm still learning and connecting these concepts with actual implementation in my projects. I don't want to just make authentication work. I want to understand why it works that way, what can go wrong, and how to build it securely. That's a big part of becoming a better backend engineer.

Want to actually understand a concept? Try explaining it in a post. The moment you write it out, you find the parts you only thought you knew. Gaps show up fast. Fill them, then hit post.

One of the biggest mistakes people make is expecting their lives to change in a few weeks after spending years doing the same things. Give yourself time. Build skills. Make mistakes. Start again. Real progress rarely happens on your preferred timeline.

Difference between Reverse Proxy, Load Balancer, and API Gateway : They often look identical in system design diagrams, but they solve three different problems. Here's how I think about them: 1. Reverse Proxy → The Entry Point Your backend shouldn't be directly exposed to the internet. A reverse proxy sits in front of your server and handles TLS termination, request forwarding, caching, and filtering unwanted traffic. It answers: Where should this request go? 2. Load Balancer → Traffic Distribution One server eventually becomes a bottleneck. Instead of upgrading a single server forever, run multiple instances of your application. A load balancer distributes incoming traffic across them and performs health checks to avoid sending requests to unhealthy instances. It answers: Which healthy instance should handle this request? 3. API Gateway → Service Routing As your application grows into microservices, you might have separate services for authentication, orders, payments, and users. An API Gateway provides a single entry point and routes requests to the appropriate service. It can also centralize authentication, rate limiting, and logging. It answers: Which service should handle this request, and what policies should apply? One important thing engineers should understand: These aren't necessarily three separate products. A single NGINX instance can perform reverse proxying, load balancing, and some API gateway responsibilities. The difference isn't the tool. It's the responsibility it handles. When designing a system, don't just ask which technology to use. Understand the problem you're solving first.

₹2,000–₹3,000/month for a Full Stack Engineer internship. But wait, there's a catch. They want 2 YEARS OF EXPERIENCE. React, Next.js, React Native, PHP, MySQL, HTML, CSS. Basically, they want someone who can already build products, handle frontend and backend, and contribute like an experienced developer. But apparently, that developer is worth ₹3,000/month. 💀 I'm genuinely curious: Are companies hiring interns to teach them, or hiring experienced developers at intern salaries? At this point, should candidates feel underqualified or should companies reconsider their expectations? 😭

One thing I wish more developers understood before deploying their applications: A successful API response doesn't always mean your system is working correctly. Imagine this: Your API returns "200 OK", but: - The database query takes 4 seconds. - The same request triggers 5 unnecessary queries. - A third-party API is slowing down the response. - Your server is using more memory with every request. Everything looks fine from the outside. But your users are experiencing a slow application, and your infrastructure is quietly becoming expensive. That's why production debugging isn't just about checking status codes. Learn to monitor: - Response time (p95 and p99) - Database query duration - Memory and CPU usage - Error rates - External service latency Don't just build applications that work. Build applications whose health you can actually understand.