DEV Community: Monu Kumar

The ₹1 That Costs ₹62,400: Modelling India's Tax Slabs Without Cliff-Edge Bugs

Monu Kumar — Sat, 08 Aug 2026 17:24:28 +0000

Progressive tax is the textbook example of a reduce. Walk the slabs, tax each band at its rate, sum it up. Twelve lines, done.

Then you hit a rebate threshold and discover your function has a cliff in it.

In India's new tax regime, taxable income up to ₹12,00,000 attracts zero tax — not because the slabs produce zero, but because a rebate wipes out the computed liability. Run ₹12,00,000 through a naive implementation and you get ₹0. Run ₹12,00,001 and you get roughly ₹62,400.

One extra rupee of income, ₹62,400 of extra tax. That is not how the law works, but it is exactly how an unpatched slab function behaves.

I ran into this while building a regime-comparison tool, and the fix turned out to be the interesting part. This post covers the three discontinuities that break naive tax code, and a small binary search that answers a question closed-form algebra doesn't handle well.

Code is TypeScript, framework-agnostic. I'll mention where React comes in at the end.

The part that actually is a reduce

Start with the easy bit. A slab is an upper bound and a rate:

type Slab = { upTo: number | null; rate: number };

const NEW_REGIME_SLABS: Slab[] = [
  { upTo:   400_000, rate: 0    },
  { upTo:   800_000, rate: 0.05 },
  { upTo: 1_200_000, rate: 0.10 },
  { upTo: 1_600_000, rate: 0.15 },
  { upTo: 2_000_000, rate: 0.20 },
  { upTo: 2_400_000, rate: 0.25 },
  { upTo:      null, rate: 0.30 }, // null = no ceiling
];

Walking them:

function slabTax(taxable: number, slabs: Slab[]): number {
  let tax = 0;
  let floor = 0;

  for (const { upTo, rate } of slabs) {
    if (taxable <= floor) break;
    const ceiling = upTo ?? Infinity;
    const amountInBand = Math.min(taxable, ceiling) - floor;
    tax += amountInBand * rate;
    floor = ceiling;
  }

  return tax;
}

Sanity check at ₹11,25,000:

band 1:        0 →   400,000  @ 0%   →      0
band 2:  400,000 →   800,000  @ 5%   → 20,000
band 3:  800,000 → 1,125,000  @ 10%  → 32,500
                                total = 52,500

That's correct, and it's the last thing in this domain that behaves nicely.

The single most common bug I've seen in hand-rolled tax code is taxing the whole income at the top applicable rate instead of banding it. Someone earning ₹12,10,000 gets shown a 15% flat bill. The floor/ceiling walk above is what prevents that, and it's worth a test even though it looks obviously right.

Discontinuity one: the rebate cliff

Section 87A grants a rebate that cancels tax entirely below a threshold. In the new regime for FY 2026-27 that's up to ₹60,000 of rebate for taxable income up to ₹12,00,000.

Modelled naively:

const REBATE = {
  new: { limit: 1_200_000, maxRebate: 60_000 },
  old: { limit:   500_000, maxRebate: 12_500 },
} as const;

function applyRebate(taxable: number, tax: number, regime: Regime): number {
  const { limit, maxRebate } = REBATE[regime];
  if (taxable > limit) return tax;          // ← the cliff
  return Math.max(0, tax - maxRebate);
}

Plot taxable → tax around the threshold and you get a step function. At ₹12,00,000 the slabs produce exactly ₹60,000, the rebate cancels it, output is zero. At ₹12,00,001 the rebate vanishes and the full ₹60,000 lands, plus cess.

The law patches this with marginal relief: tax is capped at the amount by which income exceeds the threshold. Earn ₹1 over, pay at most ₹1.

function applyMarginalRelief(
  taxable: number,
  taxAfterRebate: number,
  regime: Regime
): number {
  const { limit } = REBATE[regime];
  if (taxable <= limit) return taxAfterRebate;

  const excessOverLimit = taxable - limit;
  return Math.min(taxAfterRebate, excessOverLimit);
}

Now the curve is continuous. From ₹12,00,000 upward, tax rises rupee-for-rupee with income until the relief stops binding — somewhere around ₹12,70,000 — after which normal slab tax takes over.

That transition point is emergent, not hardcoded. It's wherever slabTax - rebate crosses income - limit. Worth understanding, because if you ever find yourself wanting to hardcode ₹12,70,000 as a magic number, you've misunderstood the mechanism.

Discontinuity two: surcharge, same shape, bigger numbers

High incomes attract a surcharge — a percentage of the tax, not of income — that steps up at ₹50L, ₹1Cr, ₹2Cr and ₹5Cr.

Same cliff, worse blast radius. At ₹50,00,000 there's no surcharge. At ₹50,00,001, a 10% surcharge applies to the entire tax liability. Without relief, one rupee of income triggers a tax jump in the lakhs.

Surcharge marginal relief works the same way, phrased differently: the increase in total tax cannot exceed the increase in income over the threshold.

const SURCHARGE_BANDS = [
  { threshold:  5_000_000, rate: 0.10 },
  { threshold: 10_000_000, rate: 0.15 },
  { threshold: 20_000_000, rate: 0.25 },
  { threshold: 50_000_000, rate: 0.37 },
];

function surchargeWithRelief(
  taxable: number,
  baseTax: number,
  slabs: Slab[],
  regime: Regime
): number {
  const band = [...SURCHARGE_BANDS]
    .reverse()
    .find(b => taxable > b.threshold);

  if (!band) return 0;

  const rawSurcharge = baseTax * band.rate;

  // Tax at the threshold itself, for comparison
  const taxAtThreshold = applyMarginalRelief(
    band.threshold,
    applyRebate(band.threshold, slabTax(band.threshold, slabs), regime),
    regime
  );

  const incomeOverThreshold = taxable - band.threshold;
  const maxAllowedTotal = taxAtThreshold + incomeOverThreshold;
  const reliefCappedSurcharge = Math.max(0, maxAllowedTotal - baseTax);

  return Math.min(rawSurcharge, reliefCappedSurcharge);
}

Two things to note. The .reverse().find() picks the highest applicable band — a plain find on the ascending array returns 10% for a ₹3 crore income, which is wrong and won't show up unless you test at high incomes. And the new regime caps surcharge at 25% rather than 37%, so a production version needs a regime-aware band list.

Putting the pipeline together

Order matters, and it's the order the statute specifies:

function computeTax(input: TaxInput): TaxResult {
  const { grossIncome, deductions, isSalaried, regime, ageGroup } = input;

  const standardDeduction = isSalaried
    ? (regime === "new" ? 75_000 : 50_000)
    : 0;

  // Chapter VI-A deductions apply to the old regime only
  const applicableDeductions = regime === "old" ? deductions : 0;

  const taxable = Math.max(
    0,
    grossIncome - standardDeduction - applicableDeductions
  );

  const slabs = getSlabs(regime, ageGroup);

  const gross     = slabTax(taxable, slabs);
  const afterReb  = applyRebate(taxable, gross, regime);
  const afterRel  = applyMarginalRelief(taxable, afterReb, regime);
  const surcharge = surchargeWithRelief(taxable, afterRel, slabs, regime);
  const cess      = (afterRel + surcharge) * 0.04;

  return {
    taxable,
    totalTax: Math.round(afterRel + surcharge + cess),
    monthlyTds: Math.round((afterRel + surcharge + cess) / 12),
  };
}

Cess sits on top of tax plus surcharge — a mistake that's easy to make and hard to spot, because it only skews results for high earners who aren't your test case while you're building.

The actual problem: solving for break-even

Here's the question the tool exists to answer, and the reason I wrote any of this.

India lets you pick between two regimes. The new one has lower rates and almost no deductions. The old one has higher rates but allows deductions for investments, health insurance, rent and home loan interest.

Every comparison tool tells you which regime is cheaper given the deductions you typed in. Almost none answer the more useful question:

How much deduction would I need for the old regime to win at all?

That's an inverse problem. Fix the income, treat old-regime tax as a function of deductions, and find where it crosses the constant new-regime tax:

find D such that oldRegimeTax(income, D) === newRegimeTax(income)

You could solve it algebraically per slab, but the rebate, marginal relief and surcharge all introduce breakpoints, so a closed-form solution turns into a stack of case analysis that has to be rewritten every time a Budget moves a threshold.

The function is monotonically decreasing in D — more deductions never increase tax. Monotonic means binary search:

function findBreakEvenDeductions(input: BaseInput): number | null {
  const newTax = computeTax({ ...input, regime: "new", deductions: 0 }).totalTax;

  const oldAtZero = computeTax({ ...input, regime: "old", deductions: 0 }).totalTax;
  if (oldAtZero <= newTax) return 0;   // old regime already wins

  const oldAtMax = computeTax({
    ...input, regime: "old", deductions: input.grossIncome,
  }).totalTax;
  if (oldAtMax > newTax) return null;  // unreachable at any deduction level

  let lo = 0;                    // old regime loses here
  let hi = input.grossIncome;    // old regime wins here

  for (let i = 0; i < 50; i++) {
    const mid = (lo + hi) / 2;
    const midTax = computeTax({
      ...input, regime: "old", deductions: mid,
    }).totalTax;

    if (midTax > newTax) lo = mid;
    else hi = mid;
  }

  return Math.ceil(hi);
}

Fifty iterations narrows a ₹1 crore range to well under a rupee. Each iteration is a handful of arithmetic operations, so the whole solve runs in microseconds — fast enough to recompute on every keystroke without debouncing.

The two guard clauses matter. oldAtZero <= newTax catches incomes where the old regime already wins with nothing claimed. oldAtMax > newTax catches the case where no deduction amount can close the gap, and returning null there is honest — the alternative is a binary search converging on a meaningless boundary value that you then render as a real number.

Why this number is worth computing

Running it across incomes produces something more useful than any individual comparison:

Income	Break-even deductions needed
₹8L	~₹2.5L
₹10L	~₹4.5L
₹12L	~₹6.5L
₹20L	~₹7.1L

The realistic ceiling for someone without a home loan is roughly ₹3L — ₹1.5L of investments, ₹50k of pension contribution, up to ₹1L of health insurance. That's below the break-even at every row.

Which means for a large share of users, the answer isn't "the new regime is cheaper today." It's "the old regime is structurally unreachable for you, and no amount of tax-saving products will change that." Same computation, considerably more decisive framing — and it only exists because the tool solves the inverse problem rather than the forward one.

The live version is here if you want to poke at the edge cases. Try ₹12,00,001 and ₹50,00,001 — those are the two cliffs from earlier.

Testing the cliffs

Tax code is unusually well-suited to property-based testing, because the properties are legislated rather than invented.

test("tax never decreases as income increases", () => {
  for (let income = 100_000; income <= 60_000_000; income += 7_919) {
    const a = computeTax({ ...base, grossIncome: income }).totalTax;
    const b = computeTax({ ...base, grossIncome: income + 1 }).totalTax;
    expect(b).toBeGreaterThanOrEqual(a);
  }
});

test("no cliff exceeds the income increment", () => {
  for (let income = 100_000; income <= 60_000_000; income += 7_919) {
    const a = computeTax({ ...base, grossIncome: income }).totalTax;
    const b = computeTax({ ...base, grossIncome: income + 1_000 }).totalTax;
    expect(b - a).toBeLessThanOrEqual(1_000 + 1);
  }
});

The second test is the one that earns its keep. It encodes the entire point of marginal relief — an extra rupee of income can never cost more than a rupee of tax — and it fails loudly on any threshold you've forgotten to patch. The odd step size (7,919) is deliberate; round increments have a habit of stepping neatly over the exact boundaries you're trying to catch.

The rest is table-driven: known income/deduction pairs with hand-computed expected values, including one deliberately at each surcharge threshold.

React notes, briefly

Nothing above touches the DOM, which is the point — it's a pure module with no dependencies, testable in isolation and portable.

Two things worth mentioning about wiring it up:

Everything runs client-side. No income figures leave the browser, which sidesteps an entire category of privacy questions and lets the whole thing be statically served. Given the compute cost is microseconds, a server round-trip would be strictly worse in every dimension.

Next.js App Router splits cleanly. The page is a Server Component that owns the metadata, the structured data and the long-form explanatory content — all statically rendered. Only the interactive panel is a Client Component. The explanatory content is what search engines index, and it costs zero client-side JavaScript.

One useMemo, not several. Regime comparison plus break-even solve is a single derived computation:

const result = useMemo(
  () => ({
    newRegime: computeTax({ ...input, regime: "new" }),
    oldRegime: computeTax({ ...input, regime: "old" }),
    breakEven: findBreakEvenDeductions(input),
  }),
  [input]
);

Splitting these across multiple memos means multiple recomputation paths for the same underlying change, and the numbers can briefly disagree with each other mid-render. One input object, one memo, one consistent snapshot.

What I'd tell past-me

Three things, in order of how much time they cost me:

Model the discontinuities before writing the slab walk. The slabs are the easy 20%. Rebates, marginal relief and surcharge are the 80%, and retrofitting them into a "finished" function means restructuring rather than extending.

Encode the law's invariants as tests, not the outputs. "Tax is monotonic" and "no cliff exceeds its trigger" survive a Budget that moves every threshold. A test asserting ₹12,00,000 → ₹0 breaks the moment a rate changes, which trains you to update tests reflexively instead of reading them.

Solve the inverse problem too. Forward calculation — inputs to answer — is what everyone builds. The inverse — what would the input need to be for a different answer — is often the question the user actually has, and with a monotonic function it's twenty lines of binary search.

If you're modelling a jurisdiction with similar rebate mechanics, I'd be curious how you handled it. The relief interactions are where I'd expect implementations to quietly diverge.

Slab rates and thresholds above reflect India's FY 2026-27 provisions as I understood them while building; verify against the Income Tax Department before relying on any of it. This is a post about numerical edge cases, not tax advice.

How to Force AI to Write "Awwwards-Style" Minimalist UI in Next.js

Monu Kumar — Wed, 22 Apr 2026 11:32:33 +0000

Vibe coding is easy. Anyone can get ChatGPT to write a functional calculator in 20 minutes.

Vibe coding a beautiful calculator — one that looks like it belongs on Awwwards, loads instantly, feels premium in both dark and light mode, and doesn't make your users feel like they're using a 2019 Bootstrap template — that's the hard part nobody talks about.

I've been building MonuMoney.in for the past three months. It's a fintech calculator platform — 14 calculators, full blog system, SEO infrastructure — all built with Next.js 15, Tailwind CSS, and Google AI Studio. No design agency. No senior dev. Just me, working 7 to 10 PM on weeknights after my 9-5 digital marketing job.

The UI looks nothing like what AI usually generates. Here's how I forced it to stop giving me generic layouts.

The Core Problem With AI-Generated UI

When you give most devs (or AI) a blank prompt like "build me a calculator," you get this:

White background, black text
Input fields with default browser styling
A blue #submit button
font-family: sans-serif
Absolutely zero visual hierarchy

It's functional. It's also forgettable.

The issue isn't that AI can't write beautiful code. It's that you haven't constrained it enough. AI does what you ask. If you ask for "a calculator component," you get the average of everything it's ever seen — which is, statistically, pretty mediocre.

You need prompt architecture, not just prompts.

The Design System Lock-In Prompt

Before I generate a single component, I establish a global design constraint. I give this to Claude first, which then writes production prompts for Google AI Studio:

Design constraints for all components:
- Dark mode default, light mode toggle. Colors use CSS variables via Tailwind theme extension.
- bg-page (page background), bg-card (elevated surface), text-primary (headings), text-secondary (body), text-muted (captions)
- Border: border-border-subtle (thin, low contrast — never harsh)
- Accent colors: accent-blue, accent-green, accent-orange, accent-pink — used sparingly for data visualisation only, never for decorative borders
- Font stack: font-serif (Lora) for headings only, font-sans (Inter) for UI, font-mono (JetBrains Mono) for numbers
- Spacing: use pixel-precise values [24px], [32px], [48px], [64px] — not Tailwind utility shortcuts
- Border radius: [20px] for cards, [12px] for inputs, [8px] for buttons — consistent everywhere
- No box shadows. Depth comes from border + background contrast, not shadow.
- No gradients on text. Gradients allowed only on result cards as subtle background.

This one block, prepended to every component prompt, eliminates 90% of generic AI output. The AI can't default to white backgrounds and blue buttons because those colours aren't in the system.

The Typography Prompt That Creates Cinematic Feel

Generic AI UI uses text-xl and text-2xl for everything. Premium UI uses intentional scale jumps with tight leading.

Here's the exact typography instruction I include for hero numbers (like EMI results or SIP corpus values):

Main result number: text-[40px] md:text-[48px] font-bold text-primary font-serif leading-none
Section H1: font-serif text-[32px] md:text-[48px] font-bold text-primary leading-[1.2] tracking-tight
Section H2: font-serif text-[24px] md:text-[32px] font-bold text-primary mb-[24px]
Body copy: text-[16px] leading-[1.7] text-secondary
Captions/meta: text-[13px] text-muted
Labels: text-[15px] font-medium text-primary

The leading-none on the hero number is critical. It collapses line height to the font size, making large numbers feel sculptural rather than floaty. The tracking-tight on headings prevents the loose letter-spacing that makes AI-generated headers look cheap.

The Card System That Builds Depth Without Shadows

Every AI out of the box reaches for shadow-lg. I banned shadows entirely in my design system. Here's the card pattern I enforce:

// Standard elevated card
className="bg-card border border-border-subtle rounded-[20px] p-[24px] md:p-[32px]"

// Result/highlight card (gradient instead of shadow)
className="bg-gradient-to-br from-card to-accent-green/5 border border-border-subtle rounded-[20px] p-[24px] md:p-[32px]"

// Table container
className="bg-card border border-border-subtle rounded-[20px] overflow-hidden"

// Table header row
className="bg-card-alt border-b border-border-subtle"
// (bg-card-alt is a slightly lighter/darker variant — creates depth purely through background contrast)

No shadows. The elevation hierarchy is: bg-page → bg-card → bg-card-alt. Three levels. That's enough.

The Full Prompt Architecture in Practice

Here's what a real prompt for a calculator component looks like when you apply all these constraints. This is what I feed into Google AI Studio after Claude has pre-engineered it:

Build a React client component: EmiCalculatorClient.jsx

Use "use client" directive. Import useState from React.

DESIGN SYSTEM (apply to every element, no exceptions):
- Color tokens: bg-page, bg-card, bg-card-alt, text-primary, text-secondary, text-muted, border-border-subtle, accent-blue, accent-green, accent-pink
- No hardcoded colors (#fff, #000, bg-white, bg-gray-*, text-white, text-gray-*)
- Card pattern: bg-card border border-border-subtle rounded-[20px] p-[24px] md:p-[32px]
- Result card: bg-gradient-to-br from-card to-accent-blue/5 border border-border-subtle rounded-[20px]
- No box shadows anywhere
- Spacing: always use pixel values [16px], [24px], [32px], [48px] — never arbitrary Tailwind like p-6

TYPOGRAPHY:
- Hero result number: text-[40px] md:text-[48px] font-bold text-primary font-serif leading-none
- Labels: text-[15px] font-medium text-primary
- Helper text: text-[12px] text-muted mt-[8px]

LAYOUT:
- Grid: grid-cols-1 lg:grid-cols-12 gap-[24px]
- Inputs: lg:col-span-7
- Results: lg:col-span-5 sticky top-[80px]

SLIDERS:
- className="w-full h-[6px] bg-border-subtle rounded-lg appearance-none cursor-pointer accent-accent-blue"
- Input box alongside slider: bg-page border border-border-subtle rounded-[8px] px-[12px] py-[6px]

[Then describe the actual calculator logic here]

The design constraints come first, before any business logic. AI prioritises what it sees first. Lead with design, and the logic fits around it.

The Mobile-First Card Grid Pattern

The calculator index page uses a grid of cards. Here's the exact prompt snippet I use for any card grid:

Calculator cards grid layout:
- Container: grid grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-[16px]
- Each card: bg-card border border-border-subtle rounded-[20px] p-[20px] hover:border-primary/30 transition-colors block (as Link wrapper)
- Icon area: w-[48px] h-[48px] rounded-[16px] bg-page border border-border-subtle flex items-center justify-center mb-[16px]
- Card title: text-[15px] font-medium text-primary leading-[1.4] mb-[8px]
- Card description: text-[13px] text-secondary leading-[1.5]
- No decorative arrows or "→" icons — the entire card is clickable

The hover:border-primary/30 instead of hover:shadow-md is intentional. It creates a subtle focus state that stays within the design system. Adding shadow on hover is a Bootstrap habit. We don't do that here.

Dark Mode That Actually Works

Most AI-generated dark modes are just dark:bg-gray-900. That's not dark mode. That's just a grey background.

My CSS variable system (in globals.css) defines two sets of variables under :root and .dark:

:root {
  --color-page: #fafaf9;
  --color-card: #ffffff;
  --color-card-alt: #f5f5f4;
  --color-primary: #1c1917;
  --color-secondary: #57534e;
  --color-muted: #a8a29e;
  --color-border-subtle: #e7e5e4;
}

.dark {
  --color-page: #0f0f0e;
  --color-card: #1a1917;
  --color-card-alt: #242320;
  --color-primary: #fafaf9;
  --color-secondary: #a8a29e;
  --color-muted: #57534e;
  --color-border-subtle: #2d2b28;
}

And in tailwind.config.js:

theme: {
  extend: {
    colors: {
      page: 'var(--color-page)',
      card: 'var(--color-card)',
      'card-alt': 'var(--color-card-alt)',
      primary: 'var(--color-primary)',
      secondary: 'var(--color-secondary)',
      muted: 'var(--color-muted)',
      'border-subtle': 'var(--color-border-subtle)',
    }
  }
}

Now when I tell AI to use bg-card and text-primary, it works correctly in both modes automatically. No dark: prefixes scattered throughout the JSX. The component is mode-agnostic.

The Result

MonuMoney.in is the live, production demo of this entire framework — 14 fintech calculators, full dark/light mode, mobile responsive, built entirely through AI prompts following the architecture above.

The UI has been called "looks like a real product" by multiple people who assumed it was professionally designed. It wasn't. It was prompt engineering.

The difference between "AI-generated crud" and "AI-generated product" is constraint specificity. The more precisely you define your design system in the prompt, the less the AI has to guess — and the better the output.

Quick Reference: The Anti-Generic Checklist

Before you submit any UI prompt to AI, verify:

[ ] All colors are design tokens, not hex values or Tailwind grey utilities
[ ] No box shadows — depth from background contrast only
[ ] Typography scale specified explicitly with pixel values
[ ] Card pattern specified once, applied everywhere
[ ] Mobile layout specified (stacked on small, grid on lg)
[ ] Dark mode handled via CSS variables, not dark: prefixes
[ ] No "click here" buttons — every interactive element has purposeful label

That's the whole system. Not magic. Just constraint.

Building something with this approach? Drop a comment — I'm curious what you're making.

From ₹15,000 in Debt to Building a Fintech Side Project: My "Vibe Coding" Journey

Monu Kumar — Sun, 12 Apr 2026 07:20:53 +0000

It's funny how you can have a B.Tech in Computer Science, understand complex data structures,
and write production-level code, but completely fail at basic personal finance.

A few years ago, at 22, I landed my first real full-time job. I was managing digital marketing,
technical SEO, and Meta ads. Coming from a middle-class family in Panipat, Haryana, seeing a
regular salary hit my bank account gave me a false sense of invincibility.

I fell into the classic entry-level tech trap: lifestyle creep.

I started swiping my new credit card for weekend dinners at Hangries. I bought a premium Fossil
watch just to "look the part" in client meetings. I bought SaaS subscriptions I didn't need.

Before I knew it, I was sitting on ₹15,000 in credit card debt. I had zero savings, and the
anxiety of living paycheck-to-paycheck was destroying my productivity.

Here is the story of how I coded my way out of it, why I pivoted to "vibe coding," and how my
financial mistakes led me to build my own fintech side project.

The Turning Point: Engineering a Way Out

As developers, when we see a bug in our code, we debug it. I realized I needed to debug my
finances.

I stopped swiping. I listed out every single rupee I owed. I decided to leverage my existing
9-to-5 skills — SEO, coding, and digital marketing — to build local side hustles. I started
walking into local shops in my city, offering to set up their Google My Business profiles and
build them micro-tools using simple HTML/JS.

I used the extra income to attack my debt using the Snowball Method — paying off the smallest
balances first to build psychological momentum.

I actually wrote the exact mathematical breakdown of how I cleared my debt using the snowball method, which inspired me to build the Debt Payoff Calculator
for my new project.

The "Over-Engineering" Trap

Once I was debt-free, I wanted to share my frameworks with other young professionals in India
so they wouldn't make the same dumb mistakes I did. I decided to build a personal finance hub:
MonuMoney.in.

But like any developer, my first instinct was to over-engineer it.

I started planning a massive Next.js architecture with a heavy backend, user authentication, a
PostgreSQL database for saving calculator states, and complex global state management.

Two weeks passed. I hadn't shipped a single thing. I was stuck in "tutorial hell" and
architecture paralysis.

Embracing "Vibe Coding" with AI

That's when I decided to completely change my approach. I had been hearing about "vibe coding" —
the process of using AI tools like Claude and Google AI Studio to write the boilerplate, while
you focus purely on the logic, architecture, and "vibe" of the product.

I dropped the complex backend. I realized users don't want to log in to calculate their debt;
they just want a fast, client-side web app.

Here was my new stack:

Framework: Next.js (App Router)
Styling: Tailwind CSS (for rapid UI prototyping)
Deployment: Vercel (push to ship)
The Secret Weapon: Prompting AI for component generation

Instead of writing a complex amortization formula from scratch in JavaScript, I prompted the AI:

"Write a React component using Tailwind that calculates the debt snowball method. It needs
to take in an array of debts (name, balance, interest rate, minimum payment) and output a
month-by-month payoff table."

Within seconds, I had the core logic. I spent my time doing what human developers do best:
refining the UI, fixing edge-case bugs, adjusting the layout for mobile screens, and ensuring
the local context — like using ₹ instead of $ — was perfect.

By vibe coding, I built and deployed three complex financial calculators in a single weekend.

The Takeaway for Indie Hackers and Devs

Building MonuMoney has taught me a few massive lessons that I want to pass on to the Dev.to
community.

1. Solve Your Own Bugs (In Real Life)

The best side projects come from personal pain. I built a debt payoff calculator because I
literally needed one when I was ₹15k in the hole. If you build a tool that solves your own
problem, you automatically have a target audience of at least one person.

2. Don't Over-Engineer Version 1.0

Nobody cares about your database schema if the product doesn't exist yet. Vibe code the MVP.
Use AI to write the boring boilerplate. Ship it as a static client-side app first. You can
always add a database later when people actually start using it.

3. Your Day Job is Your Superpower

Don't try to build the next Facebook on weekends. Look at what you do from 9-to-5 and figure
out how to spin that into a localized micro-SaaS or a side hustle.

When I recently tested 5 different side hustles to see what actually works,
the highest-earning ones were directly tied to my existing professional skills in SEO and
digital marketing — not some random trend I found on YouTube.

Where MonuMoney.in Stands Today

Today, my credit card balance is zero. I have multiple income streams running simultaneously.
And I'm building out MonuMoney.in in public — sharing every real number, every failed
experiment, and every win.

The tools I've shipped so far:

A Debt Payoff Calculator (Snowball + Avalanche methods)
A Side Hustle Income Tracker
A Monthly Budget Planner built for the Indian salary structure

Everything is client-side. Everything is fast. Everything is built for the Indian rupee and
Indian financial context — because most personal finance tools online are built for Americans
and don't translate well here.

If you're a dev sitting on an idea — stop architecting it in your head. Spin up a Next.js app,
use AI to vibe code the boring parts, and just hit deploy.

The best time to ship was last week. The second best time is right now.

The Gumroad Illusion: Why I Stopped Selling Digital Products and Went Back to Service Delivery

Monu Kumar — Mon, 06 Apr 2026 16:30:48 +0000

Let me guess—you’ve seen the tweets.

"Build a Notion template in 2 hours and make ₹5 lakhs while you sleep."

"Create a PDF checklist, put it on Gumroad, and wake up to passive income."

As a digital marketer with a B.Tech in Computer Science, I bought into this dream completely. In January 2026, I decided I was going to launch my first digital product. I was going to join the "passive income" club.

I built it, launched it, shared it, and waited for the money to roll in.

It didn’t.

Today, I’m going to share the exact math of my digital product failure, why I immediately pivoted back to service delivery, and the hard lesson every marketer needs to hear about building products before building an audience.

The Dream: "Build Once, Sell Forever"

The idea seemed bulletproof. My day job involves managing SEO, Google Ads, and local search campaigns. I know exactly how to rank a local business on Google Maps.

So, I packaged my knowledge into a "Local Business SEO Checklist + Template Bundle." It included:

A step-by-step Google My Business optimization guide.
A WhatsApp marketing template for local shops.
A Google review request script.

I priced it at ₹199. A no-brainer, right? Anyone running a small business should want this.

I listed it on Gumroad. I posted the link on LinkedIn and Twitter (X). I sat back and waited for the notifications.

The Math of My Failure

Here is the unvarnished truth of what happened over 30 days:

Copies sold: 2
Gross Revenue: ₹398
Gumroad Fees: ~₹58
Net Profit: ₹340

Two copies. And to make matters worse, both buyers were other digital marketers researching what I was doing—not the local business owners I had created the product for.

This wasn't just a failed product launch; it was a reality check. When I recently tested 5 different side hustles to see what actually works, my digital product was the only one that failed spectacularly, earning just ₹340. Meanwhile, offering the exact same skills as a localized service earned me ₹7,500 in the same month.

Why Digital Products Fail for Beginners (The 3 Hard Truths)

I spent a lot of time analyzing why this happened. The product was good. The price was accessible. The problem was fundamental.

1. Distribution > Product

We live in an era of information abundance. A local business owner doesn't need my ₹199 PDF—they can ask ChatGPT for a GMB optimization guide for free. What they don't have is the time to read it or the technical know-how to execute it.

I had zero audience. No newsletter. No SEO traffic. No community. A product listing on Gumroad without a distribution channel is like opening a shop in the middle of the Sahara. It doesn't matter how good your product is; nobody is walking by.

2. The "₹199 Dead Zone"

I learned that ₹199 is a terrible price point for strangers. It’s too expensive to be an impulse buy, but too cheap to signal high value. If I had given it away for free in exchange for email addresses, it would have built my audience. If I had priced it at ₹999 and positioned it as a premium "Done-With-You" framework, the two buyers might have still purchased it, and I would have made ₹2,000 instead of ₹400.

3. I Sold Information, Not Transformation

Digital products are passive. They deliver information. But businesses don't pay for information; they pay for transformation. When I walked into a local medical store and offered to set up their Google My Business profile, I wasn't selling a PDF. I was selling them the outcome of getting more local foot traffic. That human connection, the handholding, the accountability—that’s what they paid me ₹1,500 for.

The Pivot: Why Service Delivery Won

After the digital product flop, I doubled down on what actually worked: delivering the service myself.

I walked into 11 local businesses in my city. I showed them their own Google listings on my phone. I explained, in simple Hindi, how their competitors were stealing clicks from Google Maps.

My pitch was simple: "I will set this up completely. If you get even one new customer in 30 days, pay me ₹1,500. If not, it is free."

Eight said yes. Six saw measurable results. Five paid me. One paid me ₹2,500 and asked for monthly management.

Total earned: ₹7,500. Time invested: 15 hours.

Compare that to the ₹340 from the PDF. The ROI wasn't even close.

The Right Way to Build Digital Products

I haven't given up on digital products. Passive income is real, but the sequence matters. The "gurus" get the order wrong. They say: Build Product → Launch → Get Audience.

The correct order is: Build Audience → Identify Pain Points → Sell Service → Productize the Service.

Here is my revised playbook for 2026:

Sell your skills as a service first. Prove people will pay to solve the problem.
Document the process. Turn your service delivery into content (blogs, LinkedIn posts, videos).
Build the audience. Attract people who want the result but can't afford your 1-on-1 service.
Launch the product. Now you have a distribution channel and a proven market.

The Takeaway

If you are a marketer, developer, or designer sitting on a pile of skills, do not start by building a digital product in a vacuum. You are competing against free AI tools that can generate 90% of informational PDFs in 30 seconds.

Instead, sell your trust. Sell your presence. Sell your ability to look a business owner in the eye and say, "I will handle this for you."

Service delivery isn't passive. It requires sweat, phone calls, and follow-ups. But in an AI-driven world where anyone can generate a checklist, human trust is the most valuable currency you have.

Build the trust first. The passive income will follow.

The Reality of Vibe Coding: How I Built a Web App Without "Writing" Code

Monu Kumar — Sat, 28 Mar 2026 06:13:21 +0000

I have a confession. I have a B.Tech in Computer Science. I understand programming concepts. I can read code and mostly understand what it does.

But I did not write the code for my website in the traditional sense. I built the entire thing using Google AI Studio. Prompt by prompt. Component by component.

And it works. It is live. Real people use it.

Let me tell you how.

What I Built

A personal finance calculator platform for Indians called MonuMoney.in. It has 36 financial calculators (8 fully functional right now, 28 being built), a blog, SEO setup, and the whole thing runs on Next.js 15 with Tailwind CSS deployed on Vercel.

The calculators do real-time EMI calculations, SIP return projections, income tax computation based on Indian tax slabs, retirement corpus planning, and more.

This is not a toy project. The calculations need to be accurate because people will make real financial decisions based on the numbers.

What Vibe Coding Actually Means

There is a lot of hype around "vibe coding" right now, and most of it misses the point. Let me explain what it actually looks like in practice.

Vibe coding is not "tell AI to build me an app." That does not work for anything beyond a demo.

Vibe coding is more like pair programming where your AI partner does the typing and you do the thinking. You need to know what you want. You need to understand the architecture. You need to be able to read the output and know if it is right or wrong.

Here is my actual workflow:

Step 1: I decide what I need. For example, "I need an EMI calculator page with SEO metadata, structured data, and a client-side interactive component."

Step 2: I write a detailed prompt that specifies exactly what I want. Not "build me an EMI calculator" but a prompt that describes the inputs, the formula, the output display, the styling classes, the file structure, the metadata format, everything.

Step 3: Google AI Studio generates the code. I read through it. Sometimes it is 90% right and I ask it to fix the remaining issues. Sometimes it completely misunderstands what I wanted and I rephrase.

Step 4: I paste the final code into my project, test it locally, and push to GitHub. Vercel deploys it automatically.

This cycle takes anywhere from 20 minutes for a simple component to 3 or 4 hours for a complex calculator page.

Why Google AI Studio and Not Cursor or Copilot

No particular reason honestly. I started with Google AI Studio because it was free and I was already comfortable with the Google ecosystem. It just stuck.

Could I do the same thing with Cursor, Copilot, or Claude? Probably yes. The tool matters less than the skill of writing clear, specific prompts.

Things That Work Well With This Approach

Building UI components is where vibe coding really shines. Tailwind CSS components, page layouts, responsive grids, card designs. These are things where the AI has seen millions of examples and can generate solid output consistently.

SEO boilerplate is another winner. Metadata objects, structured data JSON-LD, sitemap generation, robots.txt configuration. This stuff is repetitive and well-documented. AI handles it perfectly every time.

Standard financial formulas also work great. EMI formula, compound interest, SIP returns. These formulas are well known and the AI implements them correctly.

Things That Do Not Work Well

Anything involving complex state management across multiple components gets messy. The AI generates code that works in isolation but does not always integrate cleanly with existing components. You end up spending time debugging state conflicts.

Design consistency is another challenge. If you generate each component in a separate prompt, they might use slightly different spacing, colors, or patterns. I learned to always include my existing design tokens and class names in every prompt.

Edge cases in financial calculations are the scariest part. The AI might implement the basic EMI formula correctly but miss edge cases like what happens when the interest rate is zero, or when the tenure is less than one month. You absolutely need to test every calculator with extreme values.

The Skill That Actually Matters

The most important skill in vibe coding is not prompt engineering. It is knowing what to ask for.

If you do not understand how a Next.js App Router works, you cannot write a good prompt for it. If you do not know what structured data is, you cannot ask the AI to implement it. If you do not understand the EMI formula, you cannot verify the AI's output.

My B.Tech CS background helps a lot here. Not because I write code, but because I can read it. I understand file structures, component hierarchies, client vs server rendering, and basic algorithmic logic. When the AI generates something wrong, I can usually tell and explain what needs to change.

Vibe coding does not eliminate the need for technical knowledge. It eliminates the need for typing speed and syntax memorization. Those are very different things.

The Financial Accuracy Problem

This deserves its own section because it is the most important consideration for a project like this.

When you build a calculator that people use for financial decisions, accuracy is not optional. If my EMI calculator shows a wrong number and someone budgets based on it, that is a real problem.

My approach:

Every formula is cross-verified against at least two established sources. I check against known correct values from bank websites or government portals.

I test with known inputs and expected outputs. For example, I know that a Rs 10 lakh loan at 8% for 10 years should give an EMI of Rs 12,133. If my calculator shows anything different, something is wrong.

I always include a disclaimer that calculations are for educational and estimation purposes only. Not because I am not confident in the accuracy, but because financial tools should always carry this disclaimer.

Would I Recommend This Approach

For building tool-based websites and utility apps, absolutely yes. Vibe coding with an AI assistant is faster than traditional coding for someone at my skill level. Probably 3 to 4 times faster.

For building complex applications with lots of interconnected state, authentication, databases, and real-time features, I would be more careful. At some point, the complexity of prompts exceeds the complexity of just writing the code yourself.

For my use case, a collection of independent calculators on a static site, vibe coding is perfect. Each calculator is self-contained. Each page follows the same pattern. The architecture is simple and repetitive. This is exactly where AI-assisted coding performs best.

The site is live at https://monumoney.in if you want to see the end result.

If you have questions about the workflow or specific prompts I used, drop them in the comments. Happy to share more details.