DEV Community: DivyanshuLohani

The Hidden Cost of AI Agents: Tracing Tokens, Tool Calls, and Retries in TypeScript

DivyanshuLohani — Wed, 03 Jun 2026 05:21:47 +0000

AI agents do not become expensive all at once.

They become expensive one small decision at a time.

One extra routing call. One confidence check. One retry. One tool failure that triggers another LLM request. One formatting agent that exists because it felt cleaner during the first design.

Individually, these calls look harmless. Together, they can turn a simple support request into a chain of model calls, tool executions, retries, and post-processing steps that nobody can easily explain from logs alone.

That is the problem I wanted to explore with a small TypeScript project: a cost-aware customer support agent that routes incoming requests, validates actions, calls internal tools, and generates a final response.

The goal was not just to build another agent demo. The goal was to answer a more practical engineering question:

Where is the LLM spend actually going?

The Problem With Agent Cost Visibility

Most teams start with simple logs.

[10:14:02] RouterAgent: classified request as ORDER_CHANGE
[10:14:03] OrderAgent: fetched order details
[10:14:05] OrderAgent: generated response
[10:14:06] ResponseAgent: formatted final message

This is useful, but only at the surface level.

It tells us that something happened. It does not tell us how expensive the interaction was. It does not show how many LLM calls happened inside each agent. It does not clearly separate tool calls from model calls. It does not show whether retries happened. It does not reveal whether an agent made multiple calls for work that could have been handled by a cheaper model, a cache, or a simple rule.

That becomes a real problem when the system grows.

Consider a typical customer message:

"I need to change my shipping address for order #12345."

On the surface, this looks like a single, narrow intent — change a shipping address. Any developer looking at a product backlog would estimate this as a fast, cheap operation. The reality at runtime is often quite different.

A simple version of the agent flow might look like this:

RouterAgent classifies the request
OrderAgent fetches order details
OrderAgent validates whether the address can be changed
OrderAgent generates a confirmation message
ResponseAgent formats the final response

That looks reasonable until you inspect the runtime behavior.

The router might make one LLM call to classify the query, another call to verify confidence, and a third call if confidence is low. The order agent might use an LLM for validation even when the order state is clearly readable from the database. The response agent might use another LLM just to rewrite a message that could have been generated from a template.

Suddenly, one support request is no longer one AI interaction. It is a small execution graph — and that graph has a cost attached to every edge.

If you cannot see that graph, you cannot optimize it. And if you cannot optimize it during development, those costs compound silently in production.

Building a Cost-Aware Agent Workflow

For this project, I built the workflow around three basic ideas:

First, every meaningful agent phase should have a name. Anonymous execution is the enemy of cost visibility. When a step has no identity, there is no way to associate its cost with a design decision.

Second, every LLM call should capture token usage, model name, purpose, and estimated cost — not just a response string. The response content is what the application cares about. The metadata is what engineering should care about.

Third, the full interaction should be inspectable as one execution tree, not scattered across flat logs. A tree preserves the parent-child relationships between agents, tool calls, and model calls. It makes retries visible as siblings, not mysteries.

Here is a simplified wrapper around an LLM client that puts these ideas into practice:

import { step } from "agent-inspect";

import { OpenAI } from "openai";

type ModelRate = {

  inputPerMillion: number;

  outputPerMillion: number;

};

type LLMCallMetadata = {

  model: string;

  purpose: string;

  promptTokens: number;

  completionTokens: number;

  totalTokens: number;

  estimatedCost: number;

  durationMs: number;

};

const MODEL_RATES: Record<string, ModelRate> = {

  "gpt-4.1-mini": {

    inputPerMillion: 0.4,

    outputPerMillion: 1.6,

  },

  "gpt-4.1": {

    inputPerMillion: 2,

    outputPerMillion: 8,

  },

};

export class CostAwareLLMClient {

  private openai: OpenAI;

  constructor(apiKey: string) {

    this.openai = new OpenAI({ apiKey });

  }

  async chat(params: {

    model: string;

    purpose: string;

    messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;

  }): Promise<{ content: string; metadata: LLMCallMetadata }> {

    return step.llm(`llm:${params.purpose}`, async () => {

      const startedAt = Date.now();

      const response = await this.openai.chat.completions.create({

        model: params.model,

        messages: params.messages,

      });

      const usage = response.usage;

      const promptTokens = usage?.prompt_tokens ?? 0;

      const completionTokens = usage?.completion_tokens ?? 0;

      const totalTokens = usage?.total_tokens ?? 0;

      const metadata: LLMCallMetadata = {

        model: params.model,

        purpose: params.purpose,

        promptTokens,

        completionTokens,

        totalTokens,

        estimatedCost: this.estimateCost(

          params.model,

          promptTokens,

          completionTokens

        ),

        durationMs: Date.now() - startedAt,

      };

      return {

        content: response.choices[0]?.message?.content ?? "",

        metadata,

      };

    });

  }

  private estimateCost(

    model: string,

    promptTokens: number,

    completionTokens: number

  ) {

    const rate = MODEL_RATES[model];

    if (!rate) {

      return 0;

    }

    const inputCost = (promptTokens / 1_000_000) * rate.inputPerMillion;

    const outputCost = (completionTokens / 1_000_000) * rate.outputPerMillion;

    return inputCost + outputCost;

  }

}

Note on pricing: The exact rates in MODEL_RATES should always come from the provider's latest pricing page. Model pricing changes frequently, sometimes without prominent announcements. The important part is the pattern: every LLM call returns both the content and the metadata needed to understand cost. The pricing table is just a configuration concern.

The step.llm() boundary does something more than just wrap the call. It makes the model invocation a named, structured node inside the larger agent execution tree — which means you can later ask, "which step in which agent caused this spend?" and get a real answer.

Wrapping the Agent Run

Next, I wrapped the entire support workflow with inspectRun(). This is the outermost boundary — the container that gives the whole interaction a single, inspectable identity.

import { inspectRun, step } from "agent-inspect";

type SupportRequest = {

  customerId: string;

  message: string;

};

export async function handleSupportRequest(

  request: SupportRequest,

  agents: {

    router: RouterAgent;

    order: OrderAgent;

    refund: RefundAgent;

    response: ResponseAgent;

  }

) {

  return inspectRun(

    "support-agent-request",

    async () => {

      const route = await step("route-request", async () => {

        return agents.router.classify(request.message);

      });

      const result = await step(`handle-${route.intent.toLowerCase()}`, async () => {

        if (route.intent === "ORDER_CHANGE") {

          return agents.order.handle(request);

        }

        if (route.intent === "REFUND") {

          return agents.refund.handle(request);

        }

        return {

          type: "GENERAL",

          message: "This request can be handled by the general support flow.",

        };

      });

      return step("prepare-final-response", async () => {

        return agents.response.format(result);

      });

    },

    {

      traceDir: "./.agent-inspect",

    }

  );

}

This structure enforces something that most agent frameworks skip: a single entry point with named phases. Each call to step() is a named boundary. Each step.llm() inside an agent is a named model call. The result is an execution trace that mirrors your architecture — not just a raw sequence of events.

This is where the article's main idea becomes concrete. The code is not just instrumented for debugging failures. It is instrumented to understand cost behavior before failures occur. The trace answers questions like: where did time go? Where did tokens go? Did the expensive work happen in the right phase?

The RouterAgent Problem

In the first version of the project, the router was doing too much.

class RouterAgent {

  constructor(private llm: CostAwareLLMClient) {}

  async classify(message: string) {

    return step("router-agent", async () => {

      const classification = await step("classify-intent", async () => {

        const { content, metadata } = await this.llm.chat({

          model: "gpt-4.1",

          purpose: "classify-intent",

          messages: [

            {

              role: "system",

              content:

                "Classify the support request as ORDER_CHANGE, REFUND, SHIPPING, PRODUCT, or GENERAL.",

            },

            {

              role: "user",

              content: message,

            },

          ],

        });

        return {

          intent: content.trim(),

          cost: metadata.estimatedCost,

        };

      });

      const confidence = await step("verify-classification-confidence", async () => {

        const { content, metadata } = await this.llm.chat({

          model: "gpt-4.1",

          purpose: "verify-routing-confidence",

          messages: [

            {

              role: "user",

              content: How confident are you that this request is ${classification.intent}? Return a number between 0 and 1.\n\n${message},

            },

          ],

        });

        return {

          score: Number(content),

          cost: metadata.estimatedCost,

        };

      });

      if (confidence.score < 0.8) {

        return step("reclassify-with-context", async () => {

          const { content } = await this.llm.chat({

            model: "gpt-4.1",

            purpose: "reclassify-intent",

            messages: [

              {

                role: "system",

                content:

                  "Reclassify the request with additional context. Return only the intent.",

              },

              {

                role: "user",

                content: Previous intent: ${classification.intent}\nConfidence: ${confidence.score}\nRequest: ${message},

              },

            ],

          });

          return {

            intent: content.trim(),

            source: "reclassification",

          };

        });

      }

      return {

        intent: classification.intent,

        source: "initial-classification",

      };

    });

  }

}

This looked reasonable at first. The router was being careful. It classified, then verified, then reclassified when uncertain. This pattern is common in agent design — confidence thresholds feel responsible, like the system is checking its own work.

But careful is not always cheap. And in this case, careful was doing something more problematic: it was front-loading cost onto every request, including the easy ones.

For every request, the router performed classification with a high-capability model. For many requests, it also performed a confidence check — again with the same model. For some requests, it performed reclassification as a third call. That meant the very first step in the system could consume the majority of the per-request budget before any actual business logic ran.

This is the kind of issue that is easy to miss in flat logs. A log line that says RouterAgent: classified request does not show that the router made two or three model calls internally. It hides the retry. It hides the model version. It hides the cost. An execution tree does not.

Inspecting the Trace

After running a few sample support requests, I inspected the local trace using the CLI:

npx agent-inspect list --dir ./.agent-inspect

npx agent-inspect view <run-id> --dir ./.agent-inspect

The output made the structural issue immediately visible:

support-agent-request                                      [7.8s] ✓
├─ route-request                                           [3.9s] ✓
│  └─ router-agent                                         [3.8s] ✓
│     ├─ classify-intent                                   [1.4s] ✓
│     │  └─ llm:classify-intent                            [1.3s] ✓
│     ├─ verify-classification-confidence                  [1.1s] ✓
│     │  └─ llm:verify-routing-confidence                  [1.0s] ✓
│     └─ reclassify-with-context                           [1.2s] ✓
│        └─ llm:reclassify-intent                          [1.1s] ✓
├─ handle-order_change                                     [2.6s] ✓
│  └─ order-agent                                          [2.5s] ✓
│     ├─ fetch-order                                       [0.2s] ✓
│     ├─ validate-address-change                           [0.8s] ✓
│     │  └─ llm:validate-order-change                      [0.7s] ✓
│     └─ generate-confirmation                             [1.4s] ✓
│        └─ llm:generate-customer-response                 [1.3s] ✓
└─ prepare-final-response                                  [1.1s] ✓
   └─ response-agent                                       [1.0s] ✓
      └─ llm:format-final-response                         [0.9s] ✓

The numbers tell a clear story. Of the 7.8 seconds total, 3.9 seconds — exactly half — were spent before a single line of business logic ran. The router, whose job is to label an intent, was consuming as much wall-clock time and token budget as the actual order handling.

The trace also immediately revealed two secondary issues:

The response-agent was making a model call purely for formatting — a job that did not require a model at all.
The validate-address-change step was calling an LLM, but the order fetch happened before it. That is actually the right order — but it is only visible in the tree. In flat logs, you cannot tell whether deterministic data was used to constrain the model prompt.

The trace changed the conversation. Instead of saying "the support agent is expensive," I could now say: "the router is making three LLM calls on some requests, and the response agent is consuming model tokens for formatting." That is a different kind of engineering discussion. One is a budget complaint. The other is an actionable observation with a root cause attached.

Optimization 1: Use Rules Before Models

The first fix was simple: do not call an LLM when the intent is obvious from the message itself.

Routing is fundamentally a classification problem. For a large enough slice of real-world support requests, the classification is deterministic — a message that contains an order number and the phrase "shipping address" is almost certainly an ORDER_CHANGE. No model needs to make that call.

function classifyWithRules(message: string) {

  const normalized = message.toLowerCase();

  if (

    /order\s*#?\d+/i.test(message) &&

    (normalized.includes("shipping address") ||

      normalized.includes("delivery address") ||

      normalized.includes("change address"))

  ) {

    return {

      intent: "ORDER_CHANGE",

      confidence: 0.95,

      source: "rule",

    };

  }

  if (

    normalized.includes("refund") ||

    normalized.includes("money back") ||

    normalized.includes("cancel my order")

  ) {

    return {

      intent: "REFUND",

      confidence: 0.9,

      source: "rule",

    };

  }

  return null;

}

Then the router uses rules first and falls back to the LLM only when the message is genuinely ambiguous:

async classify(message: string) {

  return step("router-agent", async () => {

    const ruleBasedRoute = await step("rule-based-routing", async () => {

      return classifyWithRules(message);

    });

    if (ruleBasedRoute) {

      return ruleBasedRoute;

    }

    return step("llm-routing-fallback", async () => {

      const { content } = await this.llm.chat({

        model: "gpt-4.1-mini",

        purpose: "classify-intent",

        messages: [

          {

            role: "system",

            content:

              "Classify this support request as ORDER_CHANGE, REFUND, SHIPPING, PRODUCT, or GENERAL. Return only the label.",

          },

          {

            role: "user",

            content: message,

          },

        ],

      });

      return {

        intent: content.trim(),

        confidence: 0.75,

        source: "llm",

      };

    });

  });

}

Two things changed here beyond just adding regex checks.

First, the LLM fallback now uses gpt-4.1-mini instead of gpt-4.1. Routing is a short, low-complexity classification task. There is no reason to run a high-capability model on it. If the message is genuinely hard to classify, the mini model will still get it right most of the time — and if it does not, the agent's downstream error handling can manage the rare misroute far more cheaply than running the expensive model on every request.

Second, the confidence-check loop is gone entirely. Instead of asking the model whether it was confident, the architecture now defines confidence at the source: rule-based matches carry explicit confidence scores, and the LLM fallback carries a fixed lower score. Confidence checking as a second LLM call is a design smell — it outsources a system-level decision to the model, at the model's cost.

This is not about replacing AI with rules everywhere. It is about using the right tool at the right point in the workflow. If a deterministic rule can safely route obvious cases, the model should not be charged for that decision.

Optimization 2: Make Model Choice a Per-Step Decision

The second improvement was model selection — and the realization that treating model choice as a workflow-level constant is an architectural mistake.

Different steps in an agent workflow have fundamentally different quality requirements. A customer-facing response that explains why an address change was rejected needs care, nuance, and natural language quality. A routing label that picks between five categories needs accuracy, not eloquence. A validation result that checks whether a timestamp is in the past needs neither.

Applying the same model everywhere conflates these requirements. It uses the budget of a high-capability model for work that a cheaper model handles just as well.

The fix is to make model selection explicit and purpose-driven:

const MODEL_BY_PURPOSE = {
  "classify-intent": "gpt-4.1-mini",
  "validate-order-change": "gpt-4.1-mini",
  "generate-customer-response": "gpt-4.1",
  "summarize-internal-tool-result": "gpt-4.1-mini",
} as const;

function modelForPurpose(purpose: keyof typeof MODEL_BY_PURPOSE) {
  return MODEL_BY_PURPOSE[purpose];
}

Then each LLM call is tied explicitly to a purpose — and the model follows from the purpose:

const { content, metadata } = await this.llm.chat({
  model: modelForPurpose("validate-order-change"),
  purpose: "validate-order-change",
  messages: [
    {
      role: "system",
      content:
        "Validate whether this address change is allowed based on the order state.",
    },
    {
      role: "user",
      content: JSON.stringify({
        order,
        requestedChange,
      }),
    },
  ],
});

This table is also documentation. When a new developer reads MODEL_BY_PURPOSE, they immediately understand which steps are considered high-stakes (warranting a stronger model) and which are treated as routine. That is a design decision that is now visible in the code, not buried in a prompt file or tribal knowledge.

In the trace, this also gives more actionable signal. When a run is expensive, you can distinguish between: the expensive model was used in the right place for the right reason, versus the expensive model was used for a step that did not require it. Without purpose-tagged model selection, those two cases look identical in a cost report.

Optimization 3: Remove the Formatting Agent

The third issue was the ResponseAgent, and it is the most instructive problem because it came from a design philosophy, not a specific technical choice.

The first version of the architecture treated every phase as an agent. That made the design look clean and consistent — every step was an agent, every agent had a name, every agent was wired into the orchestrator the same way. Architecturally, it felt principled.

At runtime, it was wasteful.

The ResponseAgent existed to produce a consistently formatted customer-facing message. But when the actual output of the OrderAgent is already structured — it contains a customer name, an order ID, a new address — formatting that data into a natural-sounding sentence is a template problem, not a model problem.

function formatAddressChangeConfirmation(input: {

  customerName: string;

  orderId: string;

  newAddress: string;

}) {

  return Hi ${input.customerName}, your shipping address for order ${input.orderId} has been updated to ${input.newAddress}.;

}

The template produces output that is deterministic, consistent, and free. The model call produced output that was variable, slightly inconsistent across runs, and expensive relative to the complexity of the task.

The trap here is aesthetic. Agent-based architectures look elegant when every component is symmetrical. But symmetry at the design level does not translate to efficiency at the runtime level. Some steps in a workflow are genuinely model-shaped — they require language understanding, reasoning over ambiguous inputs, or generating novel text. Others are data-shaped — they take structured inputs and produce structured or templated outputs.

Modeling a data-shaped step as an LLM call is not just wasteful. It is also less reliable — template output is deterministic and testable in a way that model output is not.

The updated trace reflected the change immediately:

support-agent-request                                      [3.2s] ✓
├─ route-request                                           [0.1s] ✓
│  └─ router-agent                                         [0.1s] ✓
│     └─ rule-based-routing                                [0.1s] ✓
├─ handle-order_change                                     [2.8s] ✓
│  └─ order-agent                                          [2.7s] ✓
│     ├─ fetch-order                                       [0.2s] ✓
│     ├─ validate-address-change                           [0.8s] ✓
│     │  └─ llm:validate-order-change                      [0.7s] ✓
│     └─ generate-confirmation                             [1.6s] ✓
│        └─ llm:generate-customer-response                 [1.5s] ✓
└─ prepare-final-response                                  [0.1s] ✓
   └─ template-format-response                             [0.1s] ✓

Total request time dropped from 7.8 seconds to 3.2 seconds — a 59% reduction — without any change to the actual intelligence of the system. The model calls that remained were the ones doing genuinely model-shaped work: generating a natural-language confirmation message that requires understanding context, and validating an order change that requires reasoning about business rules.

The important part is not just that the run became faster or cheaper. The important part is that the trace made the architectural waste visible before it became a production cost problem.

Why Execution Trees Help With Cost Debugging

Cost problems in AI systems are rarely isolated to one line of code.

They usually come from the shape of the workflow — and shape is exactly what flat logs cannot show.

A retry policy may be too aggressive, triggering an LLM call after every tool failure instead of only after structured retries are exhausted. A router may be overthinking simple cases that deterministic logic could handle cheaply. A formatting step may be using a model when a template would produce better-tested output at zero cost. A validation step may be calling the model before fetching enough deterministic data to constrain the prompt — wasting tokens on an under-informed decision. A tool failure may trigger a second model call that masks the real root cause in the logs.

Each of these is an architectural problem. None of them appear in a cost invoice. None of them are obvious in flat logs. All of them become visible in an execution tree.

The reason is structural. Flat logs record events in sequence. An execution tree records relationships. It shows which LLM call belongs to which agent. It shows whether a tool call happened before or after a model call — and whether that ordering was intentional. It shows which branches ran in parallel and which were sequential. It shows where retries happened and what triggered them. It shows whether the expensive call was part of routing, validation, generation, or cleanup.

That structure matters because cost optimization is not only a token problem. Reducing prompt length by 15% is a micro-optimization. Eliminating an unnecessary routing loop is a structural optimization. The execution tree is how you find structural optimizations.

Local-First Tracing Fits the Development Loop

There are strong hosted observability platforms for production AI systems — LangSmith, Arize, Helicone, and others — and they are valuable once a team needs dashboards, evaluations, collaboration, alerting, and long-term analysis across thousands of runs.

But during development, the requirements are different. The developer is not trying to monitor a fleet of agents. They are trying to understand one run. They changed the routing logic. They want to know whether that change made the call cheaper or more expensive. They want to see the trace, compare it to the previous run, and keep iterating.

A hosted observability dashboard introduces friction into that loop. There is authentication, a data pipeline, a UI to navigate. Those things are appropriate in production. During design iteration, they slow down the feedback cycle without adding proportional value.

That is where a local-first tool like agent-inspect fits naturally. It writes traces to a local directory. It surfaces them through a terminal command. It supports named boundaries — inspectRun(), step(), step.llm(), step.tool() — that map directly onto the agent architecture. The result is a readable execution tree that makes agent behavior easier to reason about without leaving the development environment.

The comparison to think about is code coverage tooling. A developer does not send code to a hosted service to see which lines were executed. They run the tests locally and inspect the output. The same principle applies to agent cost visibility during design iteration.

For this project, local-first tracing was enough to answer the practical question: which parts of the agent are actually costing money? That question has to be answered before any optimization is worth doing. Getting it wrong means spending engineering time on the wrong problems.

Practical Lessons

Instrument before optimizing. Without execution visibility, it is easy to guess wrong about where the cost is coming from. You may spend time reducing prompt length while the real issue is an unnecessary routing loop that adds two model calls before the prompt is even constructed. The trace tells you where to look. Guessing does not.

Treat model selection as an architectural decision. A single agent workflow can and should use different models for classification, validation, summarization, and final response generation. The right model for a customer-facing message is not the right model for a routing label. Making this explicit in a purpose-to-model mapping turns a runtime cost driver into a visible, reviewable configuration.

Use deterministic logic where it is safe. Rules, templates, caches, and structured tool outputs can remove unnecessary model calls without making the system less intelligent. The key question for each step is: does this step require language understanding and reasoning, or does it require deterministic computation over structured data? The answer should determine whether a model is involved at all.

Traces are useful beyond failures. Most observability tooling is set up to catch errors. But execution traces are equally useful for understanding cost, latency, retry behavior, and design complexity — even in runs that succeed. A successful run that costs three times what it should is still a problem. The trace shows it. The success status does not.

Keep local debugging simple during design iteration. Not every development workflow needs a production observability stack on day one. The cost of integrating hosted tooling early is overhead at exactly the time when iteration speed matters most. A local trace and a terminal view are often enough to improve the design significantly before the system is ready to be monitored at scale.

Final Thoughts

AI agents are not expensive only because models are expensive.

They are expensive because agent workflows multiply model calls. A single user request passes through a router, a validator, a tool handler, a formatter, and possibly a retry handler — and each of those phases may invoke an LLM, sometimes more than once. The cost is not on the label. It is inside the orchestration.

This multiplication is not inherently bad. Some agent workflows genuinely require multiple model calls to do their job well. The problem is when the multiplication is accidental — when model calls accumulate through design decisions that nobody revisited after the first prototype, through retry policies that are too broad, through formatting steps that felt convenient, through confidence checks that nobody questioned.

Execution-level visibility is what turns that accidental complexity into something that can be reasoned about. When you can see the run as a tree, you can stop treating cost as a monthly invoice problem and start treating it as an engineering feedback loop. You can point to a specific step, ask whether it should exist, ask whether it should use the model it is using, and make a decision based on evidence rather than assumption.

For TypeScript teams building AI agents, agent-inspect gives a lightweight way to inspect that loop locally. It does not need to replace production observability. It sits earlier in the workflow — during design — where developers are still shaping the architecture and the decisions are cheapest to change.

And in many cases, that is exactly where the biggest cost savings begin: not in prompt tuning or model compression, but in the question of whether a given model call should exist at all.

NPM library: agent-inspect on npm GitHub repository: rajudandigam/agent-inspect

System Design Is Overrated (When You're a Beginner)

DivyanshuLohani — Sat, 25 Apr 2026 05:57:24 +0000

Why obsessing over architecture before you've built anything is quietly killing your growth as a developer.

Picture this: You've just finished a beginner tutorial, you're buzzing with excitement, and you're ready to build your first real project. You open a new tab, start sketching out ideas and then you make the mistake of opening YouTube.

Suddenly, you're drowning in videos about microservices, domain-driven design, event-sourcing, CQRS patterns, hexagonal architecture, things being obselete, things you should not be using all those things which you just learned are not used anymore etc etc. A senior developer on Twitter confidently declares: "If you're not thinking about scalability from day one, you're doing it wrong."

And just like that, the excitement evaporates. Your simple todo app now needs a service mesh and a Kafka queue to be "done right."

Sound familiar? You're not alone and this is one of the most common and damaging traps that beginners fall into.

The hidden trap of early architecture

System design is a genuinely fascinating discipline. It's the kind of thing that makes experienced developers light up debating trade-offs, drawing boxes and arrows on whiteboards, thinking about how millions of users would interact with a system. And that energy is contagious.

But for beginners, it often transforms into something far less productive:

A very sophisticated, very convincing form of procrastination.

You're not avoiding work, you feel like you're working. You're writing design docs, drawing architecture diagrams, thinking about abstractions. It feels like progress. It looks like progress. But nothing is getting built.

Instead of writing the ten lines of code that would bring your feature to life, you're:

The over-engineering spiral

Designing abstractions for code you haven't written yet
Creating interfaces for problems you don't actually have
Debating database schemas for an app with zero users
Watching "clean architecture" videos instead of writing a single function
Planning for 1,000,000 concurrent users when your app doesn't even start
Avoiding tech stacks, libraries, frameworks for problems you will never face in your app

You're solving future problems for a future app that may never exist while the present app sits unbuilt on your hard drive.

The cost you can't see on a spreadsheet

The damage from premature architecture isn't always obvious because it doesn't feel like damage. You're thinking! You're planning! But here's what's actually happening beneath the surface:

Feedback loops slow to a crawl. The fastest way to learn programming is to build something, see it work (or break), and iterate (that's how I got it at 2AM debug sessions without the GPT). Every hour spent in planning mode is an hour you're not getting real feedback from real running code. You're learning theory instead of developing intuition.

Complexity compounds before you have the tools to manage it. When you introduce layers of abstraction early — repositories, factories, interfaces, dependency injection — before you understand why they exist, you're adding cognitive overhead without any of the benefits. The patterns feel arbitrary because you haven't yet experienced the pain they're designed to solve.

Momentum dies quietly. Every developer knows the energy of a new project. That excitement is a resource — and it's finite. Spending it on architecture debates rather than building features drains it fast. Many projects die not from technical failure, but from lost momentum during the planning phase. And if you're like me you can get overwheled by the things and just give up the project all together opening a way for it to the unfinished projects grave.

"The biggest mistake I see beginners make is not writing bad code. It's not writing code at all."

You never learn what actually breaks. This is the most subtle and most important cost. System design is essentially a collection of lessons learned from things going wrong at scale. But if you've never built something that broke under load, you have no frame of reference for those lessons. The concepts remain abstract, like reading a book about swimming without ever getting in the water. By choosing to plan and execute I don't say its bad that's how big organizations do work but as a beginner you don't have to think about millions of users when you're not even hosting your thing.

What beginners should actually do

If you're in the early stages of your journey, here's the honest advice that most tutorials won't give you:

Stop doing this

Abstract before building
Plan for imaginary scale
Design perfect interfaces
Get stuck in tutorials

Start doing this

Build, even if it's messy
Ship something that runs
Break it and learn why
Iterate fast and often

Messy, working code is infinitely more valuable than elegant, unwritten code. A project that runs and solves a real problem, even if the codebase would make a senior engineer wince, teaches you more than any architecture course.

When you actually build things, you naturally collide with real problems:

The problems worth solving (when they appear naturally)

Duplicated logic that makes changes a nightmare
State scattered across your app with no clear owner
Functions doing ten things when they should do one
Code you can't change without breaking three other things
Features that should take an hour taking a day

These aren't abstract concepts anymore. They're your code, causing you actual pain. That is when system design stops being theory and starts being medicine and then you can understand why the systems that are recommeded are needed.

A practical path through the early stages

Instead of front-loading architecture, think about your growth in stages:

Make it work: Write the simplest code that solves the problem. Don't worry about beauty. Just make it run.
Ship it: Get it in front of real users even if that's just one friend or yourself. Real-world feedback is irreplaceable.
Feel the pain: As your project grows, you'll notice things getting harder. Certain changes are tedious. Bugs keep reappearing. This friction is gold.
Refactor with purpose: Now reach for patterns and principles — not to be "correct," but to fix the specific pain you've experienced. Design solving real problems sticks forever.
Repeat Build the next thing. Each cycle, you'll have better instincts, and system design concepts will feel less like rules and more like tools.

When system design genuinely matters

None of this means system design is useless far from it. It's one of the highest-leverage skills a senior developer can have. The key word is timing.

System design becomes valuable and meaningful when:

Signs you're ready to go deeper

You've shipped projects and felt specific, concrete pain points
You've refactored code and understand what made it better
You've worked on a codebase that others have also touched
You've had to change something and broken three other things
You're working on a team and need to communicate decisions clearly
Performance, reliability, or maintainability are causing real problems

At this stage, system design isn't abstract theory — it's a toolkit. Every pattern you learn maps to a scar you have. You understand the trade-offs not from a blog post, but from experience. That understanding is durable in a way that tutorial knowledge simply isn't.

The reality that nobody talks about

Here's a secret that senior developers rarely volunteer: they didn't architect their best work perfectly from the start. The systems you admire were almost always built iteratively, with refactors along the way.

The industry term for this is "evolutionary architecture" — and it's not a fallback for people who got it wrong. It's the intended way to build software. Systems evolve as requirements become clearer, as usage patterns emerge, and as the team learns what actually matters.

The best engineers don't write perfect code on the first pass. They write code fast, observe what happens, and improve based on reality — not imagination. System design, in practice, is often retrofitted onto working systems, not imposed on blank canvases.

So when someone online tells you to "think about scalability from day one," what they probably mean is: don't do obviously terrible things. They don't mean you should design for Google's traffic before you have ten users.

A better mental model for building

Try replacing "How do I design this correctly?" with a two-step question:

First: How do I get this working as fast as possible? Then, once it works: Where is this causing me pain, and how do I fix that?

This reframe does something important — it puts experience before theory. You earn the right to refactor by first shipping something that runs. The improvements you make at that point are grounded in evidence, not speculation.

It also keeps you moving, which matters more than most developers acknowledge. Consistent forward progress builds skills, confidence, and a portfolio. Endless planning builds neither.

The final word

System design is a genuinely powerful discipline. There will come a point in your development journey where it clicks — where you look at a codebase and instinctively understand its structure, its trade-offs, and where it will crack under pressure. That moment is worth working toward.

But you can't think your way there. You have to build your way there.

If system design is currently stopping you from writing code, from shipping projects, from making mistakes and learning from them — then right now, for you, it's not a tool. It's a blocker.

Don't let the pursuit of doing things the right way prevent you from doing things at all. The right way is a moving target that only becomes visible once you're in motion.

Just build. Then build again. Better will come.

TL;DR

System design is important — but badly timed for beginners
Over-engineering before building kills momentum and feedback loops
Messy working code beats elegant unwritten code every time
Real understanding of design patterns comes from experiencing the pain they solve
Senior devs retrofit architecture — they don't pre-plan it perfectly
Build fast, break things, refactor with purpose, and repeat

My 2025

DivyanshuLohani — Thu, 01 Jan 2026 18:04:58 +0000

2024 was about proving things to myself that I could build, learn fast, and keep shipping projects. 2025, on the other hand, was about understanding what it actually means to build software.

This year wasn’t flashy. It didn’t revolve around frameworks or buzzwords. It was messy, practical, and occasionally uncomfortable. I shipped code to production, dealt with real failures, made architectural decisions that had consequences, and learned lessons that no tutorial could’ve taught me.

These are not lessons I learned by reading, they’re lessons I learned by doing.

Stepping Outside the Screen: Real-World Opportunities

This year I finished high school and also got into actual real world things, for the longest time, my entire relationship with tech existed behind a screen but after my boards I had very much free time to go and explore the real tech world.

This year, I attended my first ever tech fest: DevFest by GDG Ranchi . It might sound small on paper, but for me, it was a turning point. Seeing developers, speakers, and students in the same physical space made something click that online learning never quite did.

Until then, tech had felt like a solo pursuit me, my pc and an internet connection. DevFest showed me the human side of software: people sharing failures, debating decisions, and talking about systems they’ve actually broken and fixed in production.

What surprised me most wasn’t the scale of the event, but the realization that I belonged there. I wasn’t “too early” or “underprepared.” I understood the problems being discussed, asked better questions, and left with a stronger sense of direction.

This experience taught me that learning doesn’t only happen through code it also happens through exposure. Being in the same room as people building real things pushes you to raise your own standards. It made me want to ship better software, think more responsibly, and stop treating projects as disposable experiments.

Production Is a Different Game Entirely

Thanks to this habbit of writing blogs I got quite lucky I secured my first clients to work as a freelance web developer and take my skills to the real world. For a long time, I treated “shipping” as the finish line. If the app worked locally, deployed successfully, and didn’t crash immediately, I considered it done (I knew few edge cases but left it there because it was just a casual project). 2025 completely destroyed that illusion. This year I dealt with apps made for real users, real people using them, bugs that weren't just there all along but left unspotted due to manual testing and treating the app with care.

Shipping code to production is not an extension of side projects, it’s a different discipline altogether. Suddenly, every decision carries weight you can't just break things and push to prod or like get a quick change. Logs matter a lot I mean a lot things can go wrong in the frontend as well as backend. Rollbacks matter. Downtime matters. Even small changes feel heavier when real users depend on them. One wrong mistake and your whole app is down for minutes cosing you a lot.

In casual projects, mistakes are learning opportunities. In production, mistakes are responsibilities. A broken feature isn’t just “oops” it’s someone else’s workflow interrupted, someone's dilevery failed, data potentially affected, or trust slightly eroded.

This year taught me that production software demands a mindset shift:

You think twice before deploying.
You test flows you previously ignored.
You plan for failure instead of assuming success.

The biggest change wasn’t technical — it was psychological. I stopped asking “Will this work?” and started asking “What happens when this breaks?” "What more ways a user can perform this action to break things" these questions alone made me a better engineer.

Vulnerabilities Don’t Care About Your User Count

One of the most uncomfortable lessons of 2025 was realizing how exposed even a small application can be. I used to believe that security becomes important after you have users. That belief didn’t survive this year.

Major vulnerabilities surfaced that directly affected production apps including one that took my own app down. It didn’t matter that my user base wasn’t massive. It didn’t matter that the app wasn’t popular. Once something is publicly accessible, it becomes a target.

The most painful realization came at the end of the year when a critical CVE hit the ecosystem I was using. My production app was suddenly vulnerable, and the damage wasn’t theoretical it was immediate and real.

That experience taught me hard rules I won’t forget:

Never run applications as root in production — ever.
Assume every service will be scanned, probed, and tested.
Security is not an “enterprise problem”; it’s a baseline responsibility.

Security stopped being an abstract concept for me in 2025. It became personal. And once that happens, you never build the same way again.

Projects That Shaped How I Think About Software

2025 wasn’t about the number of projects I built, it was about how each project forced me to confront a different kind of complexity. Every serious project this year changed the way I reason about systems, trade-offs, and responsibility.

One of the earliest was a grocery delivery app, inspired by products like Blinkit. On the surface, it looked straightforward: users, products, carts, orders. In reality, it introduced me to time-sensitive workflows, state transitions, and operational pressure. Orders aren’t just data — they’re promises. Late updates, inconsistent states, or missing edge cases immediately translate into broken trust. You can read more about this project here

Later, I went deep into live streaming, transcoding, and video processing. This was a completely different mental model. I learned that video systems are not frontend problems —they’re infrastructure problems. Encoding formats, transcoding pipelines, latency, and resource usage all matter more than UI polish. This exploration reshaped how I think about performance and scalability. more about this here

Finflow, my expense tracker, evolved significantly this year. What started as a web app grew into a system with major updates and a Flutter mobile app that synced data with the web. Handling consistency across platforms taught me that shared state is one of the hardest problems in software. UI is forgiving — data corruption is not.

When GitHub Actions were blocked for me, I didn’t wait. I built a simple CI/CD pipeline myself. It wasn’t fancy, but it worked — and more importantly, it forced me to understand deployments at a lower level. When the tooling disappeared, the learning multiplied.

Payments were another major theme. I integrated multiple payment gateways, explored different verification patterns, callback flows, retries, and failure handling. Payments taught me that correctness matters more than elegance. You don’t optimize for beauty when money is involved — you optimize for certainty.

I briefly explored Flutter more deeply, but eventually realized my long-term focus was better aligned with Expo and JavaScript-based ecosystems. That detour wasn’t wasted — it clarified my direction.

By the end of the year, I was building something bigger: a platform-style app inspired by Hago and WePlay. Not just a game, but a system — users, sessions, state, and real-time interaction.

Every project added a new layer to how I think. Not “how do I build this?” but “what breaks first, and why?”

ReadmeHub and Remembering Why I Build

I vibe coded a simple app to try out vibe coding but also spread a positive message around the world a small, almost sarcastic project aimed at calling out fake participation during Hacktoberfest. It was for the developers who show up only for the T-shirt, not the contribution.

The app wasn’t complex. It didn’t introduce new architectural challenges. But it served a purpose it let me build something opinionated, fast, and honest without worrying about polish or metrics.

That mattered more than I expected.

ReadmeHub reminded me that building can still be playful. That not every project needs to become a product. Some projects exist just to say something, explore an idea, or scratch an itch.

In a year full of responsibility, production pressure, and real consequences, this small project helped me reconnect with why I started building in the first place.

You can checkit out at: https://readmehub.divyanshulohani.xyz/

The Biggest Lesson Wasn’t Technical

Looking back, the most important things 2025 taught me had very little to do with frameworks, languages, or tools. I didn't build too much projects I explored every aspect in my existing apps I could yeah some distractions were there that did contribute to the factor of not building new projects

But I learned that building software is an act of responsibility. Your mistake can cost a lot in production a mistake is not just a mistake its a real thing you are accountable for.

Once something is in production, it stops being “your code” and starts being something other people rely on. That shift changes how you think, how you test, how you deploy, and how you respond when things go wrong.

I also learned that speed without intention leads to fragile systems, and that maturity in engineering often looks like choosing the simpler, safer option — even when you could build something more impressive.

Most importantly, I learned that growth isn’t about how much you ship. It’s about how deeply you understand the consequences of what you ship.

That mindset changed everything.

Looking Ahead to 2026

If 2025 was about learning through experience, 2026 will be about sharing those experiences openly and building more software tougher ones.

Next year, I want to create more content not tutorials chasing trends, but honest write-ups about what worked, what broke, and what I’d do differently. I want to document the decisions behind the code, not just the code itself.

I’m entering 2026 with clearer priorities:

Build fewer things, but build them better
Treat production as sacred
Keep learning, but stay grounded
Share the journey, not just the outcomes

2025 taught me how fragile software can be. 2026 is about building it with more care and helping others do the same.

I hope you spent your 2025 just as amazing and fantastic as I did and looking forward I Wish you all a Happy 2026

The Compromise of a Production VPS

DivyanshuLohani — Wed, 10 Dec 2025 19:41:08 +0000

Security incidents often arrive quietly, without alarm bells or dramatic warnings. They sneak into production environments when we least expect them, on weekends, during moments of downtime, or when routine vigilance slips just a little.

This is the story of how my production VPS was compromised by attackers who deployed crypto-mining malware and persistent agents. What followed was a long learning process filled with investigation, cleanup attempts, unexpected failures, and finally, a deep dive into what true production-grade security really means.

A Sunday Evening Shock

It began innocently. On a calm Sunday evening, I opened my production app to check something. Except… it didn’t load. No error page. No timeout. Just a silent blank screen nothing except the slpash screen.

I assumed the server might be having a hiccup. Maybe a deployment issue or that core just again said I will not work. Maybe some error or the hosting service down (which is happening a lot recently) but I was so wrong.

My first thought today is sunday lets leave it for tomorrow but curiousity began in my mind so I got to my workstation and tried to SSH into the VPS. Connection timed out. Tried again. Timed out again I thought hmm... maybe connection failure or may the vps have been shutdown due to overdue bill I supposed. again I was so wrong.

After multiple attempts, the SSH prompt finally appeared. the machine was slow and sluggish like running ls was also taking 3 - 4 seconds that sluggishness became my first real clue

The machine wasn’t down, it was overwhelmed.

Once I logged in, the system felt painfully sluggish. Even typing commands felt like wading through molasses.

I ran:

top

And saw something that changed the tone of the night and runined the few hours of my weekend

The Bad Actor

A process named rysyslo\, located in /usr/bin/rsyslo, was consuming roughly 80% CPU and a significant amount of RAM and almost all of the disk space

I had never installed any binary by that name. Ubuntu the os, doesn’t ship such a file.

A quick chat and search confirmed it. It was malicious.

My server had been breached.

First Cleanup Attempt; Sense of a False Victory

I deleted the suspicious binary. Removed unfamiliar services. Killed the rogue processes. The load dropped. The system behaved normally. Everything felt fine. But deep down in my mind I knew that it may not have been gone with such simple attempts (spoiler alert: I was right) but still I left it as I thought I will backup the data tomorrow

The Next Day Things Get Worse, Not Better

The following morning, I again opned the app, still unavailable. Over 16 hours of downtime at this point.

SSH once again behaved erratically — refusing connections for minutes at a time. I even had to ask chat gpt to get me script to constantly try to get in using ssh because it just kept on timing out.

When I finally got in, the situation had escalated dramatically.

Running top revealed:

xmrig — a notorious crypto-mining tool
Multiple disguised binaries with random names
Fake kernel threads impersonating system processes
A mysterious program called monarx-agent consuming memory
Node processes I had not launched

The first obvious solution that came to my mind was to kill them but I knew this was not going to do anything because they must have set backdoors and other ways to restart the service. The system was no longer merely “infected.” It was owned.

The Attackers’ Footprint

I still am very beginner in devops and linux systems even though I use it as my daily driver. I asked chat gpt how can I clean the system follwed the steps closely and this bought me some time to backup any server data that was there.

First I did basic scans to search for malicious services and found alive.service and lived.service these are too not created by the os and ofcourse not by me hence: malicious they both pointed to a script file located in the following locations:

/tmp/runnv/alive.sh
/tmp/runnv/lived.sh

Both services were configured to:

Restart=always
RestartSec=5s

These scripts continuously fetched, restored, and relaunched the miner — even seconds after deletion. This explained everything: No matter how many times I killed a process or removed a binary, the malicious services resurrected them.

This wasn’t a small compromise. It was a full-scale, multi-vector persistence setup.

Services Begin to Break

Over time, the machine became unstable:

SSH stalled or dropped repeatedly
System operations slowed to a crawl
Memory usage spiked unpredictably
System logs showed irregularities
A fake agent (monarx-agent) reappeared no matter how many times it was removed
The machine would barely stay functional long enough for basic commands

There was no longer any pretense of stability it became like the VPS was setup intentionally for mining bitcoin.

The attackers had established root-level foothold (this was due to my fault but more on this later), and the operating system had been modified in ways I could no longer trust.

My Response to the things

At this stage it was not about that how can I fix the server but the important server data that's on there should be extracted asap and the user data should be checked to see that it did not have a breech

I began systematically backing up:

PostgreSQL database dumps using pgdump
Application server files
Media directories
Configuration files
User uploads
Essential environment variables
Reverse proxy configs
Logs for analysis

Because the system was barely responsive, everything required workarounds,

For anything related to files I used rsync and copied the files to my local machine but this was not the usual way I had to write scripts to check the access of the ssh and then copy the files because the ssh connection kept on dropping.

Eventually, I succeed in the task every important asset was safely backed up.

After confirming data integrity and to my surprise the application data was untouched by the hackers they just wanted to use my machine to mine crypto, so I made the decision to shut down the compromised machine permanently and migrate to a fresh VPS instance because this was destroyed beyod repair.

Searching for the Entry Point

After all the chaos I was geniunly curous that how did they get access to my server, I never had my keys leaked nor the IP so I began looking into this.

I began by reviewing all forensic data:

/var/log/auth.log
SSH access attempts
Systemd unit file timestamps
Root-level process creation logs
Cron jobs
Unknown script origins
Unfamiliar executables
Running port lists
Binaries in /usr/bin, /tmp, /dev/shm, /usr/share/updater

What I discovered:

I was right I did not had my keys leaked or something like that. The log only showed rejected SSH requests which I know happen because some people just leave everything to the default (I am one of those but not at this point)

Everything was good but annoyingly:

❗ There was no definitive entry point.

So where did they get in?

The prime suspect is the very recently disclosed React2Shell vulnerability (CVE-2025-55182) revealed just a day before the attack. This vulnerability allows remote code execution under certain misconfigured environments.

Web servers or exposed ports would have been particularly vulnerable. Another major factor:

And yes I was right I checked the nginx logs for the server and there I see someone forcefully did a post request to every endpoint they could've found and there might been vulnerable endpoints which gave them access to the machine.

Hostinger VPS firewall defaults to allow ALL inbound and outbound traffic.

Unlike cloud platforms with strict security groups (AWS, GCP), this VPS was wide open at the network level. this was the default thing I never touched.

This alone dramatically increases the attack surface.

The Biggest Lesson — Never Run Applications as root

One big mistake I had made knowingly that not to run apps with root privelleges that they can modify the system in anyway. My PostgreSQL server, which ran under a non-root system user, remained untouched by the attacker, I know they were not looking for it but in case then it would've still remained safe No tampered files. No altered configurations. No corrupt data. No suspicious access. Even though the system was compromised, the database was safe.

This incident reinforced a principle I will never ignore again:

Never run applications as root. Ever.

Give them the smallest permissions required to function and nothing more. not even modification outside the directory (unless your app has to access).

The Rebuild

After recovering and moving to a fresh VPS, I rebuilt the environment with proper security measures:

Firstly I ensured that I do not run the process as the root user I create users for each module like for the server for the frontend or for the api. NO compromise should be made in setting users up.

I enforced strict firewall rules only allow http and https ports to be expoed to the public because my app does run postgres but as an internal tool and the database should not be accisble publically all traffic is handled via nginx so other ports should not be open.

This wasn’t just “rebuilding a server.” It was rebuilding an entire philosophy about production infrastructure.

Final Thoughts

Security incidents can be unsettling, especially when a server is actively failing under the strain of malware and critical data must be preserved in a limited window of time. Yet, despite the pressure, this experience provided a deeper and more practical understanding of DevOps and cybersecurity than any structured lesson could have offered. Real incidents force you to confront the consequences of design decisions, configuration choices, and operational habits in a way theoretical learning never does.

Key lessons learned:

A VPS exposed with open ports is an open invitation for attackers. Any publicly accessible service increases the attack surface. Without strict access controls, monitoring, and proper configuration, automated scanners and bots will quickly identify and target vulnerabilities.
The presence of a crypto miner is a clear indicator of full system compromise. Attackers who deploy miners rarely stop there; they often modify system files, escalate privileges, and establish hidden footholds. Once this occurs, trust in the system is lost. Rebuilding from a clean state is the only reliable response.
Attackers rely on persistence mechanisms that are deeper than a single malicious process. Modern attacks may involve cron jobs, rootkits, altered binaries, SSH backdoors, and hidden user accounts. Removing one visible component does not eliminate the underlying compromise.
Least privilege is a critical layer of defense. Systems designed so that applications do not run as root help ensure that, even if an intrusion occurs, the damage is limited. Proper isolation, permissions, and role separation can prevent attackers from accessing sensitive data or making irreversible changes.
Backups are invaluable during emergencies. When a system is compromised, having recent, verified, and off-server backups can mean the difference between a smooth recovery and catastrophic data loss. Backup integrity and testing should be treated as core operational practices.
Default configurations are rarely secure. Vendor defaults prioritize usability and compatibility, not security. Hardening a system requires deliberate configuration: limiting access, disabling unnecessary services, enforcing strong authentication, and enabling proper logging.
Incident response demands composure and methodical action. In high-pressure situations, rushing often leads to mistakes. A structured approach—assess, contain, preserve evidence, recover, and improve—ensures that decisions are informed and effective rather than reactive.

Ultimately, this was far more than an unplanned lesson in server hardening. It served as a reminder that security is not a checkbox or a one-time setup. It is an ongoing discipline that requires continuous awareness, proactive measures, and a mindset of vigilance.

TL;DR

My production VPS was fully compromised by attackers who deployed crypto-mining malware and multiple persistence mechanisms. Initial cleanup attempts failed because the system had already been taken over at the root level. After identifying disguised services, malicious binaries, and severe instability, I focused on backing up critical data before rebuilding everything on a fresh server.

The investigation showed that open ports, default firewall settings, and a likely exploitation of a newly disclosed vulnerability created the entry point. The incident reinforced essential lessons: never expose unnecessary services, never run applications as root, always enforce least privilege, and treat security as an ongoing discipline—not a one-time setup.

When Hacktoberfest Became README-fest - I did this

DivyanshuLohani — Wed, 08 Oct 2025 10:59:58 +0000

The October of Open Source 🎃

October is a magical month for developers. While most people think it as just a normal month transition from summer to winter, we developers have our own tradition, Hacktoberfest. It’s that time of year when GitHub notifications blow up, Discord servers buzz with collaboration, and developers from every corner of the internet collectively shout,

“Hey, let’s contribute to open source!”

Hacktoberfest, started by DigitalOcean in 2014, was a simple yet brilliant idea: encourage developers to contribute to open source, reward them with limited-edition swag, and spread the joy of collaboration. It lowered the barrier for beginners so suddenly, even your first small PR (Pull Request) felt like a ticket to the world of real-world software.

It wasn’t just about code; it was about community. People made friends, joined projects, fixed typos, improved docs, and sometimes even built features that millions now use. For many developers, Hacktoberfest was their gateway drug into open source.

But like all things on the internet, what starts wholesome… eventually mutates into chaos.

Open Source: The Internet’s Most Beautiful Mess

To anyone outside the dev world, “open source” sounds like a technical term. But for us, it’s much more than that. it’s a philosophy. It’s about sharing knowledge, collaboration without boundaries, and believing that software gets better when everyone can help shape it.

I still remember my first real open source contribution. It was at Formbricks as a part of combined initiative that was oss.gg I stepped into the world by just making a small change adding a Last Used indicator to the login page.

But as we know every coin has two faces open source is no exception to that, the noble idea of coming together and helping build good software for people collided with internet culture’s favorite game: the numbers game (it ruins everything).

The Problem: When “Open Source” Turned Into “Open Spam”

Let’s be honest — the moment a reward system exists, people will find a shortcut to just abuse it and get the reward no matter the outcome.

As Hacktoberfest grew, so did YouTube tutorials titled “How to Win Hacktoberfest FAST!” New devs, excited to participate (and maybe get a free t-shirt), started following “guides” that basically said:

“Just find any repo, fix a typo, and submit four PRs.”

And thus began the era of the README Pull Request Apocalypse.

Repos everywhere were getting flooded with contributions like:

“Fixed a small grammar mistake.”
“Added full stop at the end.”
“Updated README title from H1 to H2.”
“Added emojis for ✨aesthetic✨.”

Some poeple (yes people not devs) just be like I will add my name to the readme for what reason god knows but they will do.

Open source maintainers were drowning in meaningless PRs. Some people were even creating repos just to spam each other with fake PRs. Github like introduced a feature to like limit new users from contribution which can be turned off every major framework or library has that turned on, It became a game changed from who can get do meaningful help to who could get four green squares the fastest.

Now, don’t get me wrong — I don’t blame anyone. For many, it wasn’t malice; it was desperation to belong. Beginners wanted to see their name in the contributors list. They wanted proof they were “part of open source.”

But in chasing that feeling, Hacktoberfest started losing what made it beautiful — genuine collaboration.

My Pun-In-Code Response: Enter ReadmeHub

I could’ve written a tweet thread complaining about it. Or made a meme. But instead, I thought — why not turn the whole situation into a joke that actually works as an app?

That’s how ReadmeHub was born — a parody platform for “open source contributors” who just can’t resist updating README files.

It’s like GitHub’s unserious cousin — built purely for fun and satire. You log in, type your username, and you’re now a “contributor.”

The app has a variety of repositories to contribute to:

cool-project – “The coolest project you’ll ever see (probably not)”
todo-app-9000 – “Yet another todo app that will definitely change your life”
useless-project – “A project so useless, it’s actually useful”

You can contribute to them in following ways:

Fixing Typos
Adding Emojis (AI thinks it makes a repo look professional)
Adding Quotes randomly
Vibe edit the readme using AI ofcourse

Every “contribution” you make earns you badges like:

🏆 Fixed 10 Typos – Grammar police salute you!
🚀 Added 500 Emojis – Houston, we have a contribution!
☕ Coffee-Fueled Coder – 2 a.m. commits, fueled by caffeine and chaos.
🐦 Early Bird – You were here before it was cool.

And the best part? You can generate a shareable image — a fake contribution card to flex on your developer friends.

Because sometimes, instead of fighting absurdity… it’s more fun to join in and make it funnier.

👉 Try it here: https://readmehub.divyanshulohani.xyz/

The Hidden Message Beneath the Joke 💭

ReadmeHub isn’t just a meme project (okay, maybe 90% meme, 10% message). But it also says something about developer culture today.

The world of programming is increasingly gamified — GitHub streaks, LeetCode badges, AI-assisted commits, contribution graphs. Sometimes, we forget that code is supposed to solve problems, not just earn points.

ReadmeHub pokes fun at that obsession with metrics. It’s satire for anyone who has ever stared at their GitHub profile thinking,

“I need more green squares.”

"I need to have that perfect looking github graph"

It’s a reminder that your value as a developer isn’t measured in PR counts or stars. It’s measured by curiosity, learning, and the problems you solve — even if they’re small.

Ironically, by making a fake-contribution app, I ended up having deeper conversations with developers about real open-source contribution. Sometimes humor opens doors that serious rants can’t.

The Irony of It All

The funniest (and maybe saddest) realization? A parody app about fake contributions probably got more engagement than many genuine open-source repos do in a month.

But that’s also what makes developer culture fascinating — we love building weird things, just because we can.

Every viral project starts with a mix of humor and curiosity. Whether it’s a useless API that returns random cat facts, or a website that tells you “how many coffees you’ve coded today,” — it’s all part of the same creative chaos that fuels open source.

ReadmeHub fits right into that lineage — silly, smart, and just self-aware enough to make people smile.

Conclusion: What Hacktoberfest Still Means

At its core, Hacktoberfest is still a beautiful idea. It gets thousands of people writing code, exploring projects, and learning skills they’ll carry for life maybe we will see some more open source projects.

But maybe we all need a reminder: Contributions are more than commits — they’re collaboration, communication, and creativity combined. If you’re contributing to open source this October, do it for the right reasons: to learn, to share, to help.

And if you’re just here for the badges, emojis, and “README updates”… don’t worry — we’ve got you covered. Visit ReadmeHub and go wild. After all, sometimes the best way to make a point is to turn it into a punchline.

Now go and fix some typos while I find a repo that can run on my pc.

Implementing Real-Time Chat with SSE vs WebSockets (and Why I Chose One)

DivyanshuLohani — Mon, 15 Sep 2025 04:12:03 +0000

Every developer building a chat app eventually stumbles into the same rabbit hole: Do I use WebSockets or Server-Sent Events (SSE)? It sounds like a minor technical choice at first—just pick whichever tutorial looks nicer on YouTube and move on. But trust me, this one decision can quietly shape the scalability, complexity, and sanity of your project (and your future AWS bills if you pick wrong).

When I started working on real-time communication for my Django app, I had to make this exact decision. The app needed chat, but chat wasn’t the main feature just a nice to have. So naturally I didn't wnat to spend more time on selecting techonlogies and give it a whole new timeline.

In this article, we’ll dive deep into what real-time communication really is, explore how SSE and WebSockets work, compare them side by side, and finally, I’ll share why I picked SSE for my project (and why it was some sort of inspired by linkedin).

Deep Dive into SSE

How It Works

Sever Sent Events (SSE) is like an open door which the client makes to the server the open door only allows one way communication from server to the client not the other way around it sends messages its just another TCP connection which just has its end packet forgotten so it keeps on going.

It’s built on plain old HTTP, so you don’t need to break your brain setting up new protocols.

Code Example: SSE in Django

Server (Django view):

    from django.http import StreamingHttpResponse
    import time

    def sse_chat_stream(request):
        def event_stream():
            while True:
                # In reality, pull from Redis/pub-sub
                yield f"data: New message at {time.time()}\n\n"
                time.sleep(2)

        return StreamingHttpResponse(event_stream(), content_type='text/event-stream')

Client (JavaScript):

    const eventSource = new EventSource("/chat/stream/");

    eventSource.onmessage = function(event) {
        console.log("New message:", event.data);
    };

That’s it. You’ve got a real-time connection with about 20 lines of code. (Which is about 50 fewer than WebSockets usually require.)

Pros of SSE

Simple and easy to impliment with very less of a overhaul.
One way communication mostly realtime but this can become a down side too
Your browser autoretrys the connection in an event of failure
Almost all browsers support it (Almost is due to IE)

Cons of SSE

So one way communication is also pro but can be a con depending on your project.
Not great if your app relies on the milisecond the message is sent you have to recieve it
No binary data (text only). If you need binary, look elsewhere. but can be useful

But here’s the kicker: for 80% of “real-time” needs—like chats that aren’t the entire focus of the product—SSE is more than enough you don't need NASA like communication that every millisecond matters.

Deep Dive into WebSockets

How It Works

WebSockets are like having a direct phone line between client and server. Once connected, both can talk freely, as much as they want, whenever they want, just a private, always-on conversation.

It’s a separate protocol that starts with an HTTP handshake and then upgrades to a persistent TCP connection.

Code Example: WebSockets

Server (Node.js with ws*):*

    const WebSocket = require('ws');
    const wss = new WebSocket.Server({ port: 8080 });

    wss.on('connection', ws => {
      ws.on('message', message => {
        console.log(`Received: ${message}`);
        ws.send(`Echo: ${message}`);
      });
    });

Client:

    const socket = new WebSocket("ws://localhost:8080");

    socket.onopen = () => socket.send("Hello Server");
    socket.onmessage = event => console.log(event.data);

Now you’ve got two-way communication—chat, games, collaborative docs, you name it.

Pros of WebSockets

Both ways of communication can happen any time.
Latency is very low almost realtime
Perfect for chat apps if your main focus is reducing latency to the 10th of a second
Binary data handling is supported.

Cons of WebSockets

Complex to scale and has lots of network limitations
Requires extra setup in case of django it can be another level of headache
Its too powerful for simple apps and comes with the same cost.

My Real-World Implementation

Here’s the context: I was building a Django app where chat was a nice-to-have feature, not the core. Think of it as the beverages that come in a Burger King combo not needed but good to have. (Yes I don't like soft drinks that much)

I first considered WebSockets. They’re the gold standard for chat, after all. But as I dug deeper, I realized setting up Django Channels, handling scaling with Redis, configuring sticky sessions, and then debugging it all would be like bringing a rocket launcher to open a soda can.

Then I started researching more on the topic and did some reverse engineering on apps I use such as linkedin what they use in their apps for the same I found that linkedin used SSE for the chats and it just works very well I know they have put a lot of thought in selecting this as their primary system but it gave me a way then I learned about SSE and implimented it in my app. It has allowed me to have the following:

Real-time server → client updates.
Super easy scaling with existing HTTP infra.
Less complexity to manage.

And to be honest that's all I need for my app I don't need like crazy good realtime updates its not Telegram or Discord. All I do is create a POST request for new message from clients and using simple redis queue and some pubsub magic it just works.

Simple. Effective. And no therapy sessions required.

Minimal Chat with SSE

Server (Django + Redis pub/sub):

    import json
    import redis
    from django.http import StreamingHttpResponse

    redis_client = redis.StrictRedis()

    def stream(request, room_id):
        def event_stream():
            pubsub = redis_client.pubsub()
            pubsub.subscribe(f"chat_{room_id}")
            for message in pubsub.listen():
                if message['type'] == 'message':
                    yield f"data: {message['data'].decode()}\n\n"
        return StreamingHttpResponse(event_stream(), content_type="text/event-stream")

Client:

    const eventSource = new EventSource(`/chat/stream/room123/`);

    eventSource.onmessage = function(event) {
        const message = JSON.parse(event.data);
        console.log("New message:", message.text);
    };

    // Sending messages
    document.querySelector("#send").onclick = () => {
        fetch("/chat/send/", {
            method: "POST",
            body: JSON.stringify({ text: "Hello world" }),
        });
    };

Lessons Learned & Best Practices

Start simple. Don’t dive into WebSockets unless you truly need bidirectional communication they just require lot more effort than they should. (If all you want is notifications, SSE is your friend.)
Scale smartly. Use Redis pub/sub for message distribution. Throw in Nginx as a reverse proxy, and you’re good for a long time.
Fallbacks matter. If SSE fails (say, old browsers), fall back to long-polling. Your users don’t care about protocols; they just want their message to show up.
Measure before you optimize. Don’t assume you’ll have 10 million concurrent users tomorrow. Pick the tool that works now and is easy to evolve later.

Conclusion

To sum it up:

SSE: Lightweight, simple, perfect for one-way updates.
WebSockets: Powerful, full-duplex, perfect for heavy chat/gaming apps.

For my project, I chose SSE—because it was easy, scalable enough, and fit my use case without unnecessary complexity.

Real-time communication isn’t about flexing the fanciest tech—it’s about delivering the right experience without making your life miserable as a developer.

So, what about you? Did you pick SSE or WebSockets for your project? Let me know—I’d love to hear your war stories.

How Shipping Code in a Rush Can Cause Uncalculated Losses

DivyanshuLohani — Tue, 09 Sep 2025 11:02:24 +0000

There’s a golden rule in software development—something every junior developer learns within their first month of writing code: “Never ship untested code to production.”

It sounds simple enough, right? Like “look both sides before crosing a road” or “don't use metal in a microwave” Yet, every now and then, giant corporations (with teams of thousands of developers, mind you) somehow forget this rule. And when they do, the results are usually hilarious for users and catastrophic for the company’s balance sheet.

This past week, Reliance JioMart (yes, the Reliance-backed e-commerce giant) may have had their mishappening. Officially, JioMart hasn’t said a word about it (and they probably never will—because who likes to admit they left the door wide open?). But users discovered something that looked suspiciously like a bug, and the telegram mafia did what it always does best: exploit it, and turn it into flowing cash

The Incident: When Offer Turned into Infinite Money Glitches

On the surface, JioMart’s scheme looked innocent enough. They rolled out a promotion saying: spend ₹101 or more, and you’d get ₹100 off. Great deal, right? (No, not even if this was not the incident) The kind that makes you add that extra packet of biscuits to your cart just to qualify.

Except… the way they set it up apparently had a fatal flaw. The promotional link they sent wasn’t just a one-time coupon link—it was reportedly a coupon factory. Every time you clicked it (or tweaked it just a little), boom: a brand-new coupon worth ₹100 landed in your account. Unlimited. Endless. Like Willy Wonka’s chocolate river, but instead of chocolate, it was discount codes.

And because the internet is faster at finding loopholes than companies are at closing them, people quickly caught on. Telegram groups saw a great opportunity and turned it to a cash thing. They started offering hundrends even thousands of cupons for free and once they ran out(which was pretty quick) they started selling them ₹10–20 each. Think about that: a ₹100 coupon going for just ₹10 or even free if you were lucky and quick. That’s not just a discount—that’s arbitrage, baby.

In effect, JioMart’s marketing campaign accidentally created a black market economy inside Telegram. Imagine explaining that in a board meeting:

“Sir, our competitors are not the issue. Our biggest competitor is now a Telegram group run by some college kids selling our coupons at 90% off.”

What (Allegedly) Went Wrong

From digging into the reports (and yes, some curious minds actually tested the link), the bug seemed almost embarrassingly simple. The link they sent out had a query parameter which likely was a tracking id for the specific customer but was not checked.

But here’s the kicker: the parameter could accept any random value and still generate a fresh coupon code like a coupon creating machine. Now, as developers, we can all imagine how this might have happened. Maybe someone forgot to add a validation check. Maybe QA was skipped because deadlines were looming. Or maybe the dev team thought, “Who’s going to notice?” (Answer: everyone. Everyone noticed.)

It raises the question: what kind of logic was powering this system? Was it something like:

if (request.hasQueryParam) {
    generateCoupon();
}

Because that’s what it felt like. One missing if condition. One missing database check. One small oversight that spiraled into thousands of coupons.

And the funny part? This wasn’t some deep, sophisticated hack that required genius-level skills. No, this was low-hanging fruit. It’s the digital equivalent of leaving your shop unlocked at night with a sign saying, “Please don’t steal.”

The Aftermath: Servers Down, Coupons Everywhere

As word spread, chaos followed. JioMart’s cart service and related systems reportedly buckled under the load. Think about it: hundreds (maybe thousands) of people hammering the system, generating coupon after coupon, placing order after order.

For customers, it was like Diwali came few weeks early. For JioMart, it must have looked like a DDoS attack—but powered not by bots, but by real coupon hungry people.

Financially, the losses could have been massive. Even if only a fraction of the coupons were redeemed, each represented ₹100 in lost revenue. Multiply that by thousands, and you’re staring at some very uncomfortable spreadsheets.

JioMart has not confirmed the incident. Which makes sense. You don’t exactly want your brand trending on Twitter under #UnlimitedCoupons. Admitting it would be like saying, “Yeah, we accidentally let people print money for a day. Oops.”

But interestingly, the next day the link magically stopped working. Coincidence? Or a silent fix? I’ll let you decide. (Spoiler: it was a fix.). Still some sort of bug or intended feature like everyday you would click the same link you would still get a brand new coupon but seems like its intended working.

Why This Matters (and Why It’s Funny)

On one level, this is hilarious. Big company leaves giant hole, users exploit it, chaos ensues. It’s the kind of story that makes developers shake their heads and laugh nervously, because deep down, we all know: this could happen to any of us if we’re not careful.

But on another level, it’s dead serious. This wasn’t just a minor UI glitch or a typo in the app. This was a systemic design flaw—the kind that directly hits revenue.

The sarcasm writes itself:

“Why bother with rate limiting? Let everyone generate coupons like new orders”
“Who needs backend validation when you can trust query parameters, the most trustworthy part of the internet?”
“Unit testing? Nah. Let production users do the testing for us. They’ll find bugs faster anyway.”

Lessons for Developers (and Corporates Who Don’t Listen)

Validation is sacred. Never trust input from the client side. Ever. It doesn’t matter if it’s a coupon code, a price, or a user ID—if your backend just accepts it blindly, you’re inviting chaos.
Abuse scenarios are real. When designing a system, don’t just think, “What’s the happy path?” Think, “How would someone misuse this?” Because trust me, someone will.
Testing isn’t optional. Yes, deadlines are tight. Yes, management wants the feature out “yesterday.” But the cost of rushing can dwarf the cost of a delay. Which would you rather explain in a meeting: “We’re shipping a week late,” or “We accidentally lost crores because our coupon system was a slot machine”?
Transparency matters (sometimes). JioMart chose silence, which is understandable. But imagine the goodwill they could have earned by acknowledging it lightly—“Hey, we goofed, it’s fixed, no free money anymore.” At least it would have made them human.

The Bigger Picture

Incidents like this aren’t rare. History is full of “fun” bugs that cost companies millions:

In 2014, a bug in Shoppers Stop’s online store let people order items worth thousands for ₹1.
In 2019, a Paytm glitch allowed people to generate unlimited movie tickets using promo codes.
And who can forget the infamous “Amazon accidentally listed expensive cameras for $94” bug? (Someone, somewhere, got Christmas and Diwali rolled into one.)

The common thread? Rushing to production without proper testing. It’s the software equivalent of building a skyscraper but forgetting to check if the elevator works.

Closing Thoughts

Whether or not JioMart ever admits it, this was an interesting choke point in their system design—a perfect example of how one unchecked assumption can snowball into a full-blown crisis.

For developers, it’s a cautionary tale. For users, it was a once-in-a-lifetime sale. And for JioMart, it’s probably a very expensive lesson written into some internal post-mortem doc with the title: “Why We Test Promo Systems Before Sending Them to 100 Million Users.”

So the next time you’re tempted to push that untested code to production because “it’s just a small feature,” remember JioMart’s infinite coupon generator. In the world of software, shortcuts aren’t just risky—they’re sometimes very, very costly.

Or, to put it simply: you can either test your code, or your users will test it for you—and they’ll do it with a lot more creativity.

Why MVP Mindset Saves Projects (And How I Apply It)

DivyanshuLohani — Tue, 12 Aug 2025 11:08:06 +0000

The Project Graveyard in My Github

I have a lot of unfinished projects in my GitHub. They are digital tombstones of grand ambitions that died somewhere between "revolutionary idea" and "hmm, maybe I need user authentication AND real-time chat AND AI integration AND..." everything I can think of during the planing phase and only have kanban boards or todo lists for them never got to be real.

Sound familiar?

For years, I was that developer who'd start projects with a mental feature list longer than a CVS receipt. I'd spend weeks architecting the perfect system, planning for edge cases that might never happen, and building features "just in case." The result? A graveyard of half-built applications and a growing sense that I couldn't finish anything.

Then I discovered the MVP mindset. Not just as a business concept, but as a personal productivity philosophy. And it changed everything.

What MVP Actually Means

Most people think MVP means "build something basic and hope for the best." That's wrong.

MVP means building the smallest thing that solves a real problem and gives you real feedback. It's not about being lazy or cutting corners—it's about being ruthlessly focused on what actually matters.

The skateboard-to-car analogy gets thrown around a lot, but here's what it really taught me: each iteration should be a complete, working solution. A skateboard gets you from point A to point B. So does a car. But you learn different things from each version. The way you maintain balance on a skateboard is not the same as gearing up in a car.

My mistake for years was trying to build the car from day one. Spoiler alert: it doesn't work and after this realization I belive it will never work projects built from ground up should be treated like wheels without wheels skateboard or cars are just not possible.

The Project That Actually Shipped

Last year, I had an idea for a expesne management app specifically for me. My initial plan was insane:

GitHub integration
Passbook integration
Accounts managemnet
Todo Apps
Custom admin dashboard
AI-powered suggestions
Native Mobile app
Dark mode (obviously)
Kanban boards
Budget system
Reports and analytics

I spent three weeks just setting up the database schema. Then I realized I was doing it again—building the app which is only needed by me or maybe few others when I launch

So I stopped. Started over. Built the dumbest version possible: a single page where you could add expenses only no balance maintence nothing. That's it. No database, just localStorage. No user accounts, no fancy UI. Just a working app for tracking transactions and exporting them

I shipped it in two days.

And you know what? People used it. My friends started asking for the link. I got feedback I never expected. Some wanted categories. Others wanted due dates. A few asked about multiple accounts features

But here's the key: I learned what people actually need, not what my delusional brain thought they needed.

How I Apply MVP Thinking Now

1. The "One Problem" Rule

Every project starts with one question: What's the ONE problem this solves? Not five problems. Not "it could also do this and that." One problem. My current project is expense tracker. The one problem it solves: I keep forgetting just stroing expense and nothing more than that.

That's it. Not "social media for sharing things" or "Bank account passbook" Just "store and generate csvs of your transactions."

2. The 80/20 Feature Cut

I list every feature I can imagine, then cross out 80% of them.

The remaining 20% becomes version 1. The crossed-out features? They go in a "maybe later" file. Most of the time, "later" never comes—and that's perfectly fine that feature may not be worth that time and effort maybe it will become a feature that is just there and only you use it and no one else which is obviously bad.

3. The Two-Week Test

If I can't build a working version in two weeks, the scope is too big. This isn't about rushing or cutting quality. It's about being realistic. Two weeks forces me to focus on what's actually essential versus what's just nice to have and not waste time in thinking peculiar edge cases which may be only hypothetical.

4. The "Embarrassing" Launch

I launch when I'm slightly embarrassed by how basic it looks. This was hard to learn. I'm a perfectionist since I've been in my mind. But I realized that "slightly embarrassing" to me is often "perfectly adequate" to users what I seem imprefect everyone using my app is fine with like I still think the UI could be way better but it works and helps me focus on features first. And shipping something imperfect beats not shipping anything perfect.

The Compound Effect of Small Wins

Here's what I didn't expect: shipping small things consistently builds momentum faster than planning big things perfectly. When you plan things you get into a world where everything seems like ideal like the bodies in physics they do not apply in real world and maybe are too redundent for users like I told earlier some features may seem apealing to you but may not be useful for the users.

Every completed project teaches you something. Every launch gives you confidence. Every piece of feedback makes the next version better and if you only plan and plan you will only plan and gain no expeirence in theory everything seems very easy like only I have to push it to vercel or netlify and the project is deployed but what if the time comes and you have to run it on a custom VPS how will you be able to do that.

My unfinished projects taught me nothing except how to start things. My finished MVPs taught me how products actually work in the real world and what to expect when deploying them instead of thinking this feature would be a great thing or like make my app seem better to users as a solo developer you can not know if what are you thinking will be appealing to users hence you need to launch the bare minimum to get the things your users think what they actually need and what are just nice to have.

Final Thoughts

The MVP mindset isn't just about building products faster (though it does that). It's about building products that people actually want what makes your core idea speak rather than a polished ui of a similar kind of app.

Every feature you don't build is a feature that can't break, can't confuse users, and can't distract from your core value proposition. Constraints force creativity. Limitations inspire focus. It helps you to be more productive and a better person in hitting the deadlines better.

Your first version doesn't need to be your final vision. It just needs to be the first step toward it. So what's your skateboard? What's the simplest thing you can build that solves a real problem for real people?

Stop planning the car. Start building the skateboard it will then lead to better car than you expect your car to be it will not just run it will break all the records

TL;DR: MVP isn't about building cheap products—it's about learning fast and building what people actually want. Start small, ship quickly, iterate based on real feedback.

From Web to Mobile: Building PWAs with Next.js & Bubblewrap

DivyanshuLohani — Tue, 17 Jun 2025 14:19:01 +0000

The Realization That Hit Me Like a Truck

So there I was, scrolling through my phone, and I noticed something weird. Almost every "app" I was using daily wasn't really an app—it was just a website pretending to be one. Twitter, Instagram, even some banking apps. They loaded fast, worked offline, and felt native.

That's when it clicked: Progressive Web Apps (PWAs).

I'd been building React/Next.js apps for years, but I was missing this whole world where you could take your web app and make it feel like a proper mobile app. No app store approval hell. No learning Swift or Kotlin. Just good old web tech doing mobile things.

Wait, What Actually IS a PWA?

Okay, so before I dive into the how-to, let me break down what PWAs actually are—because I definitely overthought this at first.

A PWA is basically a website that acts like a mobile app. It can:

Install on your phone like a real app
Work offline (kind of)
Send push notifications
Access device features like camera, GPS, etc.
Feel smooth and native-ish

The magic happens through something called a Service Worker (handles offline stuff) and a Web App Manifest (tells the browser how to behave like an app).

And the best part? If you're already building with Next.js, you're like 70% there already.

Why I Went Down This Rabbit Hole

I had this side project that worked great on desktop, but mobile users kept asking "where's the app?" Every time someone visited on mobile, they'd try to find it in the app store.

Building separate iOS and Android apps felt like overkill for what was essentially a web app. Enter PWAs and Bubblewrap—Google's tool that takes your PWA and wraps it into a proper Android app you can actually publish to the Play Store.

Step 1: Icons (Because First Impressions Matter)

You can't have a proper app without proper icons. I used to spend hours in Figma creating different icon sizes, but there's a much easier way.

Head over to https://pwa-icon-generator.vercel.app/ and upload your base icon. This tool generates all the sizes you need—from tiny 16x16 favicons to massive 512x512 app icons.

Download the zip, extract it to your public directory, and boom—icon problem solved.

Step 2: The Manifest (Next.js Makes This Easy)

Here's where Next.js really shines. Instead of manually creating a manifest.json file, you can create a manifest.ts file in your app directory and Next.js will automatically generate the webmanifest for you.

import type { MetadataRoute } from "next";

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: "My Awesome App",
    short_name: "AwesomeApp",
    description: "A really cool web application",
    start_url: "/",
    display: "standalone",
    background_color: "#ffffff",
    theme_color: "#2563eb",
    orientation: "portrait",
    lang: "en-US",
    scope: "/",
    id: "/",
    icons: [
      {
        src: "/icon512_maskable.png",
        sizes: "512x512",
        type: "image/png",
      },
      {
        src: "/icon192.png",
        sizes: "192x192",
        type: "image/png",
      },
    ],
  };
}

The display: "standalone" is crucial—it tells the browser to hide the address bar and make your app feel like a native one.

Step 3: Enter Bubblewrap (The Game Changer)

This is where the magic happens. Bubblewrap is a CLI tool that takes your PWA and packages it into a proper Android app.

First, install it:

npm install -g @bubblewrap/cli

IMPORTANT: Do NOT run this in your Next.js project root. Seriously. I learned this the hard way when I accidentally pushed Android build files to production and my app crashed. Create a separate folder for this.

mkdir my-app-android
cd my-app-android
bubblewrap init --manifest https://yourapp.com/manifest.webmanifest

Bubblewrap will ask you a bunch of questions—app name, package name, keystore password, etc. Just answer honestly, and it'll set up the entire Android project structure for you.

[Image placeholder: Terminal showing bubblewrap init process]

Step 4: Building Your App

Once the setup is done, building is surprisingly simple:

bubblewrap build

This generates:

An APK file (for direct installation)
An AAB file (for Play Store upload)
All the necessary Android project files

The build process takes a few minutes, but when it's done, you have a real Android app that you can install on any device.

Step 5: The URL Bar Problem (And How to Fix It)

Here's something that tripped me up initially. Even after all this setup, your app might still show that ugly browser address bar. That's because Android needs to verify that your website actually "owns" this app.

You fix this by creating a file at public/.well-known/assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.myapp.example.twa",
            "sha256_cert_fingerprints": [
                "A1:B2:C3:D4:E5:F6:G7:H8:I9:J0:K1:L2:M3:N4:O5:P6:Q7:R8:S9:T0:U1:V2:W3:X4:Y5:Z6"
            ]
        }
    },
    {
        "relation": [
            "check_validation"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.myapp.example.twa"
        }
    }
]

To get that SHA256 fingerprint, run this command in your Android project directory:

keytool -list -v -keystore android.keystore

Enter the password you set during bubblewrap init, and you'll see output like this:

Certificate fingerprints:
    SHA1: 12:34:56:78:90:AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78
    SHA256: A1:B2:C3:D4:E5:F6:G7:H8:I9:J0:K1:L2:M3:N4:O5:P6:Q7:R8:S9:T0:U1:V2:W3:X4:Y5:Z6

Copy that SHA256 value into your assetlinks.json file.

The Play Store Gotcha

If you're planning to publish to the Google Play Store, there's one more step. Google re-signs your app with their own key, so you'll need to add their SHA256 fingerprint to your assetlinks.json file as well.

You can find this in the Google Play Console under Setup → App Signing. Just add it as a second entry in the fingerprints array. A detailed guide

What Actually Changed for Me

After going through this whole process, here's what I gained:

Real app experience: Users can install it from the Play Store, it appears in their app drawer, and it feels native.
Better engagement: People are way more likely to use something that's "installed" vs bookmarked.
Offline capability: With service workers, core functionality works even without internet.
One codebase: I'm maintaining one Next.js app instead of separate web and mobile codebases.

The Reality Check

Let's be honest—PWAs aren't perfect. iOS support is still weird (thanks, Apple). Some device features are limited. And you'll still need to understand Android development concepts if you want to customize things.

But for most web apps that want mobile presence, this approach is so much faster than building separate native apps.

Conclusion

So yeah—PWAs aren't just a buzzword. If you're already building with Next.js and want to tap into the mobile app ecosystem without learning entirely new technologies, this is probably your best bet.

The whole process took me maybe 3-4 hours from start to finish (including the learning curve and that one time I accidentally nuked my build folder).

I'm still experimenting with advanced PWA features like background sync and push notifications, but so far, this has been one of the smoothest paths from web to mobile I've ever taken.

If you're sitting on a Next.js app wondering how to make it "feel more appy"—maybe it's time to go PWA.

Building Your Online Dev Identity (Before It's Too Late)

DivyanshuLohani — Mon, 09 Jun 2025 06:57:05 +0000

In 2025, Your Resume is Your Feed

The best job offer you can get today isn't from a fancy MNC or a funded startup—it's from yourself, from the brand you've built online. Having your own identity online, shaped not by a company or a brand but by your own presence, is now a legitimate career path. It takes time, no doubt. But if you don't start today, it'll always stay "someday."

The world has shifted. Traditional hiring processes are broken. HR departments are drowning in applications, and most resumes never even get seen by human eyes. Meanwhile, the most interesting opportunities are happening in DMs, through network connections, and from people who've been following your work for months. Your GitHub contributions, your blog posts, your hot takes on the latest JavaScript framework—that's your real resume now.

My Regret (and How I Fixed It)

I've been into development for over 6 years. I used to think, "Why post online? Who cares? If I'm good, people will find me." That's not how it works.

For years, I was the typical "head down, code hard" developer. I believed in meritocracy—that good work speaks for itself. I'd build amazing projects, solve complex problems, and then... nothing. No one knew about it except my immediate team. I was essentially invisible in an industry where visibility increasingly matters.

The wake-up call came when I saw junior developers with half my experience landing better opportunities simply because they had an online presence. They weren't necessarily better developers, but they were better at showing their work. That stung, but it was the reality check I needed.

In 2023, I realized the harsh truth: No one is going to dream about you and magically send an opportunity your way. You have to tell the world, again and again, that you exist. And so, in 2024, I made a shift.

I started posting updates about my dev projects, small wins, bugs I fixed, new tech I was trying—all on X (formerly Twitter). Then came blog posts: things I built, lessons learned, opinion pieces on tools, tech, or just stuff trending in the dev space. Hackathon updates, micro-tutorials—basically anything I was doing or learning.

The hardest part? Getting over the imposter syndrome. Who was I to have opinions about React when Dan Abramov exists? Who cares about my struggles with Docker when there are experts everywhere? But here's the thing—beginners and intermediate developers learn better from people just a step ahead of them, not from the untouchable experts.

Talking to a Wall (At First)

nitially? It felt like shouting into a void. No followers. No engagement. Maybe a cousin would like it once in a while. But I kept writing.

Those first few months were brutal for the ego. I'd spend hours crafting what I thought was a brilliant post about some obscure bug I'd fixed, only to get zero reactions. I started questioning everything—was my content bad? Was I posting at the wrong times? Was I even cut out for this?

I experimented with reels and YouTube videos—but honestly, I was spending more time editing than coding. The pressure to make things “viral” took away from the joy of development itself. So I backed off from daily content and chose a sustainable pace instead. (Yes, you can still check out my YouTube and Instagram)

This was a crucial lesson: sustainability beats perfection. I'd rather post one genuine article a week than burn out trying to create daily "content" that felt forced. The algorithm rewards consistency, but your sanity should come first.

Then, out of nowhere, one article hit. It wasn't even my magnum opus—just a breakdown of a Skribbl clone I had built, paired with a few improvements I was thinking of. It was honest, scrappy, and unpolished—but real. And it resonated. Slowly, views started to roll in. A few comments, some shares. Nothing viral—just 500–600 views. But when you're starting from zero, that's momentum. It meant someone out there was listening. It felt validating.

That article taught me something important: authenticity beats polish. People connect with real struggles and genuine insights more than they connect with perfectly curated content.

The Snowball Effect

Now, even when I don’t have time for constant updates, I make sure I push 2–3 solid articles a month. These usually focus on a few key areas:

Problems I’m facing – Whether it’s a tricky bug, a frustrating tool, or just a confusing decision I had to make, I document it. Writing about these challenges not only helps others but helps me make sense of my process too.
How I solved something weird – When something breaks and I fix it in a way that feels clever (or stupid), I write it down. These kinds of posts are always relatable to other devs and spark the best discussions.
Random insights – Sometimes I notice a pattern, trend, or just have a thought that might help others. These posts are spontaneous but surprisingly well received.

This isn’t about going viral. I’m not trying to be the next dev influencer. It’s about being consistent—because consistency builds presence. The more I post, the more searchable and discoverable I become. And maybe someday, that consistency becomes the reason someone reaches out with a cool opportunity.

So How Do You Start?

There is nothing I would say that is a secret sauce that I would tell you. You already know what you have to do and you're just lazy or don't feel like doing it but here are the steps anyways if you want there is nothing fancy.

Pick a Platform: X/Twitter is great for daily thoughts. Dev.to, Medium, Hashnode for longer articles. YouTube/Instagram if you like visual formats.
Share What You Do: Doesn’t have to be mind-blowing. Ship something? Share it. Broke something? Share that too.
Engage: Comment on others' posts. Be part of the community. You’ll learn and get visibility.
Repeat: Keep showing up, even if it feels like no one’s watching.

Why It Matters

When you have an online identity, it matters way more than you think:

People trust you more because they see the proof of work online and are confident on you and they can be sure you will be the one to finish their job
Recruiters find you, not the other way around, its same as you know your teacher but the teacher you know teaches hundreds of kids so you have to be special to be in his eyes.
Once you gain traction you will also start getting inboud requests no more hassle of going on to freelancing platforms to find work your inbox will be filled of it.
You become what you wanted to become in less time because these things put up a high impact.

Final Thoughts

If you’re learning dev or already good at it, your work deserves an audience. Start small. Stay consistent. Don’t care about metrics at first—just build.

Your online presence is like compound interest: the earlier you start, the bigger it grows.

TL;DR: Start building your personal dev brand today. The internet won’t find you on its own.

#PersonalBranding #DevJourney #ContentCreation #DeveloperLife

Payment Gateway Chaos: How I Converted Multiple Providers into One

DivyanshuLohani — Sun, 25 May 2025 20:25:35 +0000

Picture this: You're building an app, everything's going smooth, and then your client drops the bomb — "Can we support PayU, Stripe, and maybe Razorpay too? You know, for flexibility."

Suddenly you're staring at three different APIs, each with their own quirks, data formats, and authentication methods. PayU wants a hash, Stripe wants sessions, and don't even get me started on their different ways of handling amounts (seriously, who decided some should use paise and others should use rupees?).

I recently found myself in this exact situation while working on a project, and instead of copy-pasting code like a barbarian, I decided to build something that wouldn't make me want to throw my laptop out the window every time I needed to add a new gateway.

The Problem: Payment Gateway Spaghetti

Most developers handle multiple payment gateways like this:

Create separate functions for each gateway
Copy-paste similar logic everywhere
End up with a maintenance nightmare
Cry a little when requirements change

There's got to be a better way, right? Right?

The Solution: Abstract the Chaos Away

Here's the pattern that saved my sanity (and probably my career):

Step 1: Create a Universal Payment Interface

First, I created a common type that could handle all payment gateways without losing my mind:

    export interface PurchaseTransactionData {
      session: any;
      itemId: string;
      amount: number;
      itemType: PurchaseType;
      productinfo: string;
      gateway: PaymentGateway;
    }

    export interface PaymentData {
      // Common fields for all payment gateways
      gateway: PaymentGateway;
      transactionId: string;
      amount?: string;
      productinfo?: string;
      firstname?: string;
      email?: string;
      phone?: string;
      surl?: string;
      furl?: string;

      // PayU specific fields
      txnid?: string;
      hash?: string;
      key?: string;

      // Stripe specific fields
      stripePayUrl?: string;
      publishableKey?: string;
    }

Is it perfect? No. Does it work? Absolutely. The key insight here is that you need one interface to rule them all — even if some fields are gateway-specific.

Step 2: The Abstract Base Class (The Real MVP)

    import { PaymentData, PurchaseTransactionData } from "@/types/payment";
    import { prisma, PaymentStatus } from "@repo/db";

    export abstract class PaymentGatewayBase {
      abstract createPaymentData(
        transaction: any,
        transactionData: PurchaseTransactionData
      ): Promise<PaymentData>;

      async createTransaction(transactionData: PurchaseTransactionData) {
        return await prisma.paymentTransaction.create({
          data: {
            userId: transactionData.session.user.id,
            status: PaymentStatus.PENDING,
            amount: transactionData.amount,
            gateway: transactionData.gateway,
            itemId: transactionData.itemId,
            itemType: transactionData.itemType,
          },
        });
      }
    }

This abstract class does two things:

Forces every gateway implementation to have a createPaymentData method
Handles the common transaction creation logic so you don't repeat yourself

Step 3: Gateway Implementations (Where the Magic Happens)

Now here's where it gets fun. Each gateway just extends the base class and implements their specific logic:

PayU Implementation:

    export class PayUGateway extends PaymentGatewayBase {
      public async createPaymentData(
        transaction: any,
        transactionData: PurchaseTransactionData
      ): Promise<PaymentData> {
        const { merchantKey, merchantSalt } = await getPayUCredentials();

        const data = {
          key: merchantKey,
          gateway: PaymentGateway.PAYU,
          transactionId: transaction.id,
          txnid: transaction.id,
          amount: (transaction.amount / 100).toString(), // PAYU wants floats
          productinfo: transactionData.productinfo,
          firstname: transactionData.session.user.name ?? "John Doe",
          email: transactionData.session.user.email!,
          phone: "1234567890",
          surl: `${process.env.NEXT_PUBLIC_SITE_URL}/api/payu-response?status=success`,
          furl: `${process.env.NEXT_PUBLIC_SITE_URL}/api/payu-response?status=failure`,
          hash: "",
        };

        data.hash = generateHash(data, merchantSalt, merchantKey);
        return data;
      }
    }

Stripe Implementation:

    export class StripeGateway extends PaymentGatewayBase {
      public async createPaymentData(
        transaction: PaymentTransaction,
        transactionData: PurchaseTransactionData
      ): Promise<PaymentData> {
        const stripeCredentials = await getStripeCredentials();
        const stripe = new Stripe(stripeCredentials.secretKey);

        const session = await stripe.checkout.sessions.create({
          mode: "payment",
          customer_email: transactionData.session.user.email,
          client_reference_id: transaction.id,
          line_items: [
            {
              price_data: {
                currency: "inr",
                product_data: {
                  name: transactionData.productinfo,
                },
                unit_amount: transactionData.amount, // Stripe wants paise
              },
              quantity: 1,
            },
          ],
          billing_address_collection: "required",
          success_url: `${process.env.NEXT_PUBLIC_SITE_URL}/shop/?transactionId=${transaction.id}`,
          cancel_url: `${process.env.NEXT_PUBLIC_SITE_URL}/api/stripe-response?transactionId=${transaction.id}`,
        });

        return {
          gateway: PaymentGateway.STRIPE,
          transactionId: transaction.id,
          stripePayUrl: session.url || "",
          publishableKey: process.env.NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY!,
        };
      }
    }

Step 4: The Factory Pattern (Because We're Not Animals)

But wait, there's more! Manually instantiating gateway classes everywhere is still messy. Enter the Factory pattern:

    import { PaymentGateway } from "@repo/db";
    import "server-only";
    import { PaymentGatewayBase } from "./payment-base";
    import { PayUGateway } from "./payu";
    import { StripeGateway } from "./stripe";

    export class PaymentGatewayFactory {
      static create(gateway: PaymentGateway): PaymentGatewayBase {
        switch (gateway) {
          case PaymentGateway.PAYU:
            return new PayUGateway();
          case PaymentGateway.STRIPE:
            return new StripeGateway();
          default:
            throw new Error(`Unsupported payment gateway: ${gateway}`);
        }
      }
    }

Now your server-side code becomes beautifully simple:

    const gateway = PaymentGatewayFactory.create(selectedGateway);
    const transaction = await gateway.createTransaction(transactionData);
    const paymentData = await gateway.createPaymentData(transaction, transactionData);

Step 5: Frontend Magic (The Cherry on Top)

The frontend doesn't need to know about your fancy abstractions. It just needs to handle the response and redirect users accordingly:

    if (paymentResult.success) {
      switch (paymentResult.paymentData?.gateway) {
        case "PAYU":
          redirectToPaymentPage(paymentResult.paymentData);
          break;
        case "STRIPE":
          window.location.href = 
            paymentResult.paymentData?.stripePayUrl || window.location.href;
          break;
        default:
          throw new Error("Unsupported payment gateway");
      }
    }

Each gateway gets its own redirect logic, but the main flow stays clean and predictable.

Step 6: Adding New Gateways (The Real Test)

Now adding a new payment gateway is genuinely simple:

Create a new class that extends PaymentGatewayBase
Implement the createPaymentData method
Add the case to your Factory class
Add the frontend redirect logic
That's it. You're done.

Want to add Razorpay? Just create RazorpayGateway extends PaymentGatewayBase, add it to the factory, and handle the frontend redirect. No existing code needs to change.

The Beauty of This Approach

This pattern gives you:

Consistency: Every gateway follows the same contract
Maintainability: Common logic lives in one place
Scalability: Adding new gateways doesn't break existing code
Testability: You can mock the abstract class for unit tests
Sanity: You won't hate your life when requirements change

Conclusion

Payment gateway integration doesn't have to be a nightmare. With a little bit of abstraction and a lot of TypeScript magic, you can build something that's actually maintainable.

The next time someone asks you to "just add one more payment gateway," you can smile knowingly instead of updating your resume.

Now if you'll excuse me, I need to go figure out why Razorpay's webhook decided to stop working again. Some things never change.

My Experience with TurboRepo & Monorepos: From Chaos to Sanity

DivyanshuLohani — Sun, 20 Apr 2025 04:47:17 +0000

A Dev Setup That Started Like Everyone Else’s

If you’ve ever worked on a full-stack project, chances are your folder structure looked like this:

/client  
/server  
/README.md (you never updated)

And at first—it’s fine. Until one day, I was debugging something and realize that I am just copy-pasting the same utility function between folders and breaking the DRY rule.

Then the installs break. Then the dependency trees spiral. Then I am 10 commits deep into fixing a node_modules issue and forget what the feature even was.

Welcome to my life… until I discovered Monorepos.

Wait, What Even Is a Monorepo?

So, I had heard the term floating around in dev Twitter and Reddit threads, but I never really got it. I thought it was just one of those "enterprise-only" things Google does.

but it turend out—it’s just keeping all your packages, apps, and services in one codebase, organized and connected like a family that actually talks to each other.

You can share code. You can isolate builds. You can run tests on specific packages. And yeah, Google does it. That was enough to get me curious.

Enter: TurboRepo

I stumbled across TurboRepo, and the first thing I thought was:

“Wait, why didn’t anyone tell me about this sooner?”

It’s a high-performance build system for monorepos—designed to make your life less painful when managing multiple apps and packages in a single repo. And the cool part? It's designed for JS/TS devs like us.

No 20-step YAML configs. Just set up your pipeline, link things with workspaces, and boom—stuff starts working.

The Switch: Folder Chaos to Turbo Calm

I had an ongoing project with the usual split: one folder for the frontend (React), another for the backend (Express).

Converting that into a Turbo monorepo setup only took me an hour or two. (And that too with Express, which has like zero real monorepo resources out there—someone fix this please. (Article soon :)))

Now it looks more like:

/apps  
  /web  
  /api  
/packages  
  /ui  
  /utils  
  /config

And suddenly, my build scripts aren’t yelling at me. My eslint config is shared. And I'm not doing npm install in two places like an absolute fool.

The Real Benefits I Felt

Let’s be real, here’s what actually changed for me:

One place for all code: No more syncing packages manually or debugging two node_modules folders.
Code sharing became easy: Utils, types, and configs now live in one packages/ folder and are shared across both frontend and backend.
Less context switching: I don't need to cd into three places just to start the dev server.
My disaster folder got fixed: I once broke a project so badly because I didn’t understand workspaces properly. Turbo fixed that mess, cleaned up the structure, and gave me a fresh start.
Ease to Scale: Now it would be easier to add more things like admin or something like that.

Not All Rainbows

Turbo is powerful, but it’s also a bit opinionated. Some things still need digging around, especially if you’re working outside the Next.js happy path.

But once you get it running—it’s worth it.

(Also, don’t forget to cache smartly. Turbo's speed magic depends on it.)

Conclusion

So yeah—monorepos are not just for big corps. If you're building multi-package apps, it makes total sense even for solo devs or small teams. And TurboRepo? Chef's kiss. 🤌

I’m still experimenting and learning, especially with backend-heavy setups (looking at you, Express). But so far, I’d say this is one of the cleanest architectural decisions I’ve made in months.

If you’re stuck in the client-server folder spiral—maybe it’s time to go mono.