Forem: Monu Kumar

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.