DEV Community: Dishank Gupta

From Dev to Dairy - Production Testing, Real Bugs, and Lessons for Fellow Vibe Coders

Dishank Gupta — Wed, 08 Oct 2025 13:30:00 +0000

The Moment of Truth

It's September 15, 2025. I'm sitting in my office at PureDairy in Jalgaon, staring at a laptop screen showing 145 real customers in my database.

Three weeks ago, this was just an idea—a crazy plan to build an ERP with zero coding experience.

Now? It's real. It's working. And it's about to face the ultimate test: real people using it for real work.

Me to my team: "Starting tomorrow, we're using this for everything. No more Excel."

Response: Cautious optimism mixed with "let's see if this actually works."

Me, internally: This is either going to be amazing or a complete disaster.

How My Team Found 47 Design Flaws in 48 Hours

I thought I'd built a great system. I'd tested everything. Or so I believed.

Reality check: I'd tested what I THOUGHT users would do, not what they ACTUALLY do.

My team became my best QA testers. Every "this doesn't work" revealed assumptions I didn't know I had. Within 48 hours, they'd found 47 issues I would never have caught testing alone.

Here are the most humbling ones:

Issue #1: The Search That Required Psychic Powers (Day 1, 9:00 AM)

Team: "I can't find Mrs. Sharma's account."

Me: "Did you search for her name?"

Team: "Yes. 'sharma'. Nothing shows up."

Me: checks database "It's stored as 'Sharmaa' with two A's."

My Design Failure: I built a search that required EXACT spelling. Who builds search like that in 2025?

The Fix (via Claude Code): Implemented fuzzy search with case-insensitive matching. Now "sharma", "Sharma", "SHARMA", and "Sharmaa" all work.

Time to fix: 20 minutes of coding, 30 minutes of embarrassment.

What I learned: Real-world data is messy. Names have spelling variations. Search needs to be forgiving, not pedantic.

Issue #2: The Invisible Save Button (Day 1, 11:00 AM)

Team: "I marked this delivery as completed, but it's still showing as pending."

Me: looks at form "Did you click the save button?"

Team: "What save button?"

Me: realizes "...oh no."

My Design Failure: I forgot to add a save button. The form looked complete but did nothing when you filled it out.

The Fix: Added the button. Yes, I forgot to add a save button. To a form. That people fill out.

Time to fix: 5 minutes.

What I learned: Test EVERY interaction. Don't assume "obvious" buttons exist. Actually click them.

Issue #3: The Payment System That Rejected Reality (Day 2, 2:00 PM)

Team: "The app won't let me allocate this payment."

Me: "What's the error?"

Team: "It says 'amount exceeds invoice total'. The invoice is ₹1,200 and the customer paid ₹1,500."

Me: "Well, you can't pay more than the invoice amount—"

Team: "They overpaid. Customers do that all the time."

Me: "...they do?"

Team: "Yes. They round up. It's normal."

My Design Failure: My validation logic prevented overpayments because I didn't think they happened. They happen ALL THE TIME.

The Fix (via Claude Code): Allow overpayments, create "unapplied_payments" entries for the excess, show clear message explaining the split.

Time to fix: 2 hours (touched payment logic across multiple files).

What I learned: Ask your team about edge cases. They know the business better than you do.

Issue #4: Search That Assumed Too Much (Day 2, 4:00 PM)

Team: "How do I find the customer on Route 1, house number 47?"

Me: "Search by their name."

Team: "I don't remember their name. I remember they're on Route 1, near the temple."

Me: "Oh. You can't search by that."

Team: "But that's how we think about customers—by location and route, not names."

My Design Failure: I assumed everyone searches by customer name. In reality, delivery personnel think in routes, landmarks, and house numbers.

The Fix: Added filters for route, delivery time, and area. Added sorting by delivery sequence.

Time to fix: 3 hours.

What I learned: Don't design based on how YOU think. Design based on how USERS think.

Issue #5: The Date Timezone Bug I Thought I'd Fixed (Day 3, 8:00 AM)

Remember that IST timezone migration where I fixed 76 files? I missed one.

Team: "Orders generated for yesterday instead of today."

Me: checks timestamp "It's 11:45 PM. Should be generating for today."

Team: "But it says yesterday's date."

My Design Failure: ONE function in the reports module was still using new Date() instead of getCurrentISTDate(). At 11:30 PM IST, UTC was still the previous day.

The Fix: Found and fixed the last remaining timezone issue.

Time to find: 3 hours. Time to fix: 5 minutes.

What I learned: "I fixed all of them" is a dangerous assumption. Test edge cases at 11:59 PM.

Issue #6: The Double-Click Disaster (Day 4, 10:00 AM)

Team: "I generated an invoice for Mrs. Reddy, and it created two identical PDFs."

Me: "How did that happen?"

Team: "I clicked 'Generate Invoice', it was taking time, so I clicked again to make sure it registered."

My Design Failure: No button disable during PDF generation. Users could click multiple times and create duplicates.

The Fix: Disable button on first click, show loading spinner, re-enable on completion or error.

Time to fix: 15 minutes.

What I learned: Users are impatient (rightfully so). If something is loading, SHOW THEM IT'S LOADING.

The Breakthroughs (When It Actually Worked)

Breakthrough #1: The 8-Second Miracle

Day 5, 6:00 AM. First real production use of order generation.

I clicked "Generate Orders for Today."

The system:

Loaded 145 customers
Checked their active subscriptions
Applied 2-day pattern logic for 37 customers
Applied 12 active modifications (skips and increases)
Calculated quantities and prices
Created 132 orders (13 customers had no active subscriptions)
Generated production summary report
Generated route-wise delivery lists for a whole month that led to more than 3000 deliveries

Time taken: 8 seconds.

My team watched the progress bar complete and just stared at the screen.

Before: 45 minutes of manual Excel work, cross-checking notes, verifying phone numbers.

After: 8 seconds. Automated. Accurate.

No one said anything for a moment. Then: "Can we trust this?"

Me: "Let's verify the first 20 orders against our manual list."

We did. Perfect match.

Team reaction: "This is going to save us hours every day."

Breakthrough #2: Professional Invoices That Changed Perception

Day 7. First real invoice generated and printed.

Professional PDF. PureDairy branding. GST calculations. Itemized deliveries. Bank details. Everything.

Team reaction: "This looks like it came from a big company."

Me: "We ARE a legitimate company."

Before this system, we used handwritten bills with carbon copies. Now we have invoices that look like they belong in a corporate office.

Unexpected benefit: Customers started paying faster. Professional invoices signal professionalism. Who knew?

Breakthrough #3: The Outstanding Report That Actually Made Sense

Day 10. First time running the full outstanding report with real data.

Output:

Total outstanding: ₹2,34,500
Broken down by customer
Then by type (invoices, opening balance, credit sales)
Then by individual transactions
With complete payment allocation history

Team: "Wait, we can see EXACTLY what each customer owes?"

Me: "Yes. Down to the paisa."

Team: "And WHY they owe it?"

Me: "Invoice number, date, amount, what's been paid, what's pending."

For the first time in 5 years of running this business, we had crystal clear financial visibility.

No more "I think they owe around ₹5,000."

Now it's: "They owe ₹5,234.50 across 3 invoices and 1 credit sale from September 3, with ₹1,000 paid on September 10 allocated to invoice #2025202600147."

Breakthrough #4: The Mistake We Caught BEFORE It Happened

Day 14. A customer called: "We'll be out of town September 20-25."

Old process:

Write it down somewhere
Hope someone sees it
Probably forget
Deliver milk anyway
Lose money on spoiled milk
Apologize to angry customer

New process:

Open Modifications
Add Skip for that date range
Save

Result: Orders for those dates automatically show 0 quantity. No delivery scheduled. No milk wasted.

The customer: Never knew how close we came to messing up. Because we didn't.

Team reaction: "This is what we've needed for years."

What My Team Taught Me About Building Software

Lesson #1: Desktop vs Web Isn't About Intelligence

My team was used to desktop software: double-click icon, program opens.

Web apps work differently: open browser → type URL → bookmark for later.

This wasn't a knowledge gap. It was a different mental model.

Desktop apps = programs you install.
Web apps = websites that act like programs.

Solution: I created desktop shortcuts that opened the browser directly to the app. Bridged the gap between mental models.

What I learned: Don't design for "tech-savvy" vs "non-tech." Design for mental models and workflows.

Lesson #2: Your Test Data Lies to You

I tested with clean data:

"Customer A", "Customer B"
Perfect spelling
Consistent phone formats
No edge cases

Real data:

Names spelled 5 different ways
Phone numbers with/without country codes
Addresses like "near the temple, blue gate"
Notes in random fields
Edge cases EVERYWHERE

What I learned: Test with real data from Day 1. Export your messiest Excel sheet and use that.

Lesson #3: "Obvious" Features Aren't Obvious

Me: "I added bulk payment entry. You can process 20 payments at once!"

Team: "Why would we do that?"

Me: "Instead of entering them one by one?"

Team: "We only get 2-3 payments a day."

Me: "What about month-end when customers pay in cash?"

Team: "Oh! That takes 2 hours. We can do them all at once now?"

What I learned: Features aren't valuable until users see them solving THEIR specific pain point.

Lesson #4: Users Reveal What You Actually Need to Build

I spent 4 hours building a "Customer Timeline" showing every interaction.

Usage count: 0. Never used.

Why? My team doesn't care about timelines. They care about:

What does this customer owe?
What are they getting today?
Any special instructions?

What I learned: Watch users work. Find pain points. Build solutions for those. Not for what looks cool.

Lesson #5: Error Messages Should Speak Human

My original error: "Foreign key constraint violation: 23503"

Team: "What does this mean?"

Me: looks it up "You're trying to create an order for a customer with no active subscription."

Team: "Then why doesn't it say that?"

Me: "...good point."

New error: "Cannot create order: This customer has no active subscriptions. Please add a subscription first."

What I learned: Error messages should explain the problem AND the solution. In plain language.

The Real Impact (Numbers Don't Lie)

After 2 months of production use with 145 real customers:

Time Savings:

Order generation: 45 min → 8 sec (99.7% reduction)
Invoice creation: 30 min → 2 min (93% reduction)
Payment tracking: 60 min/day → 10 min/day (83% reduction)
Finding customer info: 5 min → 10 sec (96% reduction)

Total time saved per day: ~2.5 hours
Total time saved per month: ~75 hours

That's nearly 2 full-time employees worth of productivity gained.

Errors Eliminated:

Delivery mistakes: 8-10/month → 0 (100% reduction)
Payment allocation errors: 3-5/month → 1 (80% reduction)
Invoice mistakes: 2-3/month → 0 (100% reduction)

Money Saved:

Spoiled milk from wrong deliveries: ~₹5,000/month → ₹0
Customer refunds for mistakes: ~₹2,000/month → ₹0
Labor time saved (valued at ₹200/hour): ~₹15,000/month

Total monthly savings: ~₹23,000
Annual savings: ~₹2,76,000

Development cost: ₹5000 (just my time learning, little cost of Claude code pro subscription)

ROI: Infinite (because initial cost was as good as zero)

What's Working (And What Isn't)

Working Great:

✅ Order Generation - Daily orders in 8 seconds, zero mistakes
✅ Modification Tracking - No more forgotten vacation skips
✅ Invoice Generation - Professional PDFs with GST compliance
✅ Outstanding Tracking - Complete financial visibility
✅ Bulk Operations - 2-hour tasks done in 10 minutes
✅ Reports - Production summaries, route lists, payment tracking

Still Needs Work:

🔧 Mobile Responsiveness - Some tables don't display well on phones
🔧 Search Performance - Slowing down with more data
🔧 Loading States - Not all actions show clear feedback
🔧 Offline Support - Delivery personnel need offline capability
🔧 Error Recovery - Need better handling of network failures

Lessons from What Isn't Working:

I didn't build mobile-first. Big mistake. Delivery happens in the field on phones.

Fix planned: Progressive Web App (PWA) with offline support.

What I learned: Build for the actual usage context, not your development environment.

What I'd Do Differently

1. Study Some Coding Fundamentals First

I jumped in completely blind. While that worked, I wasted hours on things that 2 weeks of basic coding tutorials would've prevented.

What I should've learned first:

Basic JavaScript/TypeScript syntax
How React components work (at least conceptually)
What a database query looks like
Basic Git commands

Why this matters: You can still use AI to write code, but understanding fundamentals helps you:

Ask better questions
Spot obvious mistakes
Understand what the AI is suggesting
Debug issues faster

Time investment: 2-3 weeks of YouTube tutorials would've saved me months of confusion.

2. Start with a Vision (Even If Imperfect)

I built features reactively: "Oh, we need this. Now we need that."

Better approach: Spend a week mapping out the entire system:

What are ALL the features needed?
How do they connect?
What's the data flow?
What's the user journey?

This doesn't mean perfect planning. It means having a rough mental model of the complete system before coding your first feature.

Why this matters: I rebuilt the payment system 3 times because I didn't understand how it connected to invoices, sales, and outstanding calculations. A rough vision would've prevented that.

3. Always Understand What AI Wants to Do First

This is the biggest mistake I made.

What I did:

Ask Claude Code to build something
Copy-paste the code
Run it
Hope it works
Get confused when it doesn't

Like a monkey jumping around without thinking.

What I should've done:

Ask Claude Code to explain the approach first
Understand the logic before seeing code
Ask questions about parts I don't understand
THEN have it write the code
Review the code with understanding

Example:

Bad approach (what I did):

Me: "Build a payment allocation system"
Claude: generates 200 lines of code
Me: copies without reading "It doesn't work!"

Good approach (what I should've done):

Me: "Explain how a payment allocation system should work"
Claude: "First, you need to track payments. Then create mappings to invoices..."
Me: "Wait, why do we need separate mapping tables?"
Claude: "Because one payment can be split across multiple invoices..."
Me: "Ah! Now I understand. Show me the code."

Why this matters: When you understand the approach, you can:

Spot logical errors before implementation
Modify the solution for your specific needs
Debug issues without asking AI every time
Learn from each implementation

4. Remember: AI is Support, Not You

AI writes code. You are the developer.

What this means:

YOU define requirements
YOU understand business logic
YOU make architectural decisions
YOU test with real scenarios
YOU are responsible for what ships

AI is a powerful assistant, not a replacement for thinking.

What I got wrong: I treated Claude Code like a magic box. Put in requirements, get out working code.

Reality: Claude Code is like a junior developer who:

Writes code faster than you
Knows syntax better than you
But doesn't understand YOUR business
And can't test YOUR specific workflows

Your job: Be the senior developer who directs, reviews, tests, and ensures quality.

Why this matters: The moment you stop thinking and blindly trust AI is the moment you ship broken code.

5. Test with Real Data from Day 1

I wasted 2 weeks building features that broke with real data.

Better approach: Export your messiest Excel data on Day 1. Use that for all testing.

Why this matters: Clean test data ("Customer A", "Customer B") doesn't reveal:

Spelling variations
Missing fields
Edge cases
Real-world complexity

Real data breaks your assumptions early, when it's cheap to fix.

6. Involve Users Earlier

I should've had my team testing from Day 3, not Day 21.

Why this matters: They would've caught design flaws before I built entire features around wrong assumptions.

One week of user testing saves one month of rebuilding.

Lessons for Fellow Vibe Coders

1. Your Users Are Your Best Teachers

Every "this doesn't work" is actually "you made an incorrect assumption."

Listen. Learn. Fix.

2. Real-World Usage Reveals Real Requirements

No amount of planning beats 48 hours of real users doing real work.

Ship early. Get feedback. Iterate.

3. Design Failures Aren't User Errors

If users can't figure out your interface, that's YOUR failure, not theirs.

Make it obvious. Make it forgiving. Make it helpful.

4. Perfect Code < Working Software

My code isn't perfect. Some functions are too long. Some components do too much.

But it works. It saves time. It solves problems.

Ship imperfect solutions that work over perfect solutions that never ship.

5. Mental Models Matter More Than Features

Don't build what you think is intuitive. Build what matches how users actually think.

Route → Customer → Order, not Customer → Order → Route.

6. Test at 11:59 PM

Edge cases live at boundaries:

11:59 PM (date changes)
Month end (financial periods)
Year end (financial years)
First/last customer (sorting)
0 quantity (empty states)

Test there.

7. AI Writes Code, You Ensure It's Right

Claude Code wrote 90% of my code. But I:

Defined the requirements
Tested with real data
Found the bugs
Verified the fixes
Made the decisions

AI is a powerful tool. YOU are still responsible for the outcome.

The Question Everyone Asks

"Can I really build production software with no coding experience?"

My honest answer: Yes, but it's not magic. Here's the reality:

What You CAN Do:

Build real solutions to real problems - If you understand the problem deeply
Ship working software - Not perfect, but functional
Learn on the job - YouTube tutorials + AI coding + real testing
Save money - ₹0 development cost vs ₹50,000+ for commercial ERP
Customize perfectly - Built exactly for YOUR business needs

What You CAN'T Do (At Least Not Yet):

Build it in 3 days - My Day 1 was foundation. Day 30 was usable. Day 60 was solid.
Understand everything - I still don't know what half the code does
Avoid all bugs - 47 bugs in 48 hours. That's normal.
Skip the learning curve - You'll spend hours on YouTube, reading docs, asking AI
Ignore user feedback - Your assumptions WILL be wrong

The Realistic Timeline:

Week 1: Core features (messy but working)
Week 2-3: Refinements and testing
Week 4-6: Bug fixes and real usage
Month 3+: Optimization and improvements

This is a marathon, not a sprint.

Where I Am Now (October 2025)

The app is in production with 145 customers. Real business operations depend on it daily.

Current status:

✅ Daily orders generated automatically
✅ Deliveries tracked accurately
✅ Invoices sent professionally
✅ Payments allocated correctly
✅ Outstanding tracked precisely
🔧 Mobile optimization ongoing
🔧 Performance improvements in progress

What's changed:

Zero delivery mistakes in 1.5 months
3 hours saved every day
₹23,000 saved every month
Professional image with customers
Complete financial clarity
Confidence that I can build solutions

Most importantly: I'm not afraid of technology anymore. I don't wait for permission to build solutions.

I'm a dairy farmer who codes. And it's working.

What's Next

I'm planning to:

Open-source the dairy-specific logic - Help other dairies
Build customer self-service portal - Let customers manage subscriptions
Create video tutorials - Show other business owners how
Optimize for mobile - Better field experience
Add offline support - Work without internet

And most importantly: Help others do the same.

Because if a dairy farmer in Jalgaon can build an ERP with AI, anyone can solve their business problems with code.

For My Fellow Vibe Coders

You don't need to understand everything to build something valuable.

You need:

A real problem you understand deeply
Willingness to learn (YouTube + AI + testing)
Patience with yourself and your users
Courage to ship imperfect solutions
Openness to feedback

Start today.

Not tomorrow. Not when you "know enough." Today.

Describe your problem to Claude Code. Let it write the first line.

Then the second. Then the third.

You'll make mistakes. (I made 47 in 48 hours)

You won't understand everything. (I still don't)

Your users will find issues. (They're your best teachers)

But you'll build something that works.

And that's what matters.

Read the Complete Series:

Part 1: Why I Built an ERP for My Dairy Business
Part 2: Vibe Coding Through Subscriptions, Payments, and PDF Nightmares
Part 3: Production Testing & Lessons (You Are Here)

Series: From Dairy Farmer to Developer: Building a Production ERP with AI

Follow my journey: dev.to/dishankg

Questions? Want to try this yourself? Drop a comment. I'll answer honestly, including "I don't know, but here's how I'd figure it out."

This and all the posts in this series are written with full assistance from Claude Code, but reflect my actual stories, experiences and problems to the fullest.

To my fellow vibe coders, non-technical founders, and small business owners:

You don't need permission to solve your problems with code.

You just need to start.

Now go build something.

This and all the posts in this series are written with full assistance from Claude Code, but reflect my actual stories, experiences and problems to the fullest

Dishank Gupta
Dairy Farmer | Vibe Coder | Building solutions with AI
Jalgaon, Maharashtra, India

Stay tuned for more

Vibe Coding Through Subscriptions, Payments, and PDF Nightmares

Dishank Gupta — Tue, 07 Oct 2025 13:30:00 +0000

Day 2: When "Easy" Features Aren't Easy

I woke up on August 6, 2025, feeling like a coding god.

I mean, I'd built a working customer management system in 5.5 hours. Database, authentication, forms, everything. How hard could the rest be?

Narrator: It was harder.

Today's mission: Build the order generation system and delivery tracking. Should be simple, right? Subscriptions exist. Just... generate orders from them.

4 hours later: I was staring at code that looked like ancient hieroglyphics, trying to understand why a "2-day pattern" calculation was 47 lines of logic.

Let me take you through the real journey—not the polished version, but the messy, confused, "what am I even doing" version.

The Features That Seemed Simple (But Weren't)

1. Modifications System (Aug 5-6) - "Just Let Them Skip Days"

What I thought: Add a "skip this date" button. Done.

What it actually needed:

Skip modifications (quantity → 0)
Increase modifications (1L → 2L temporarily)
Decrease modifications (2L → 1L temporarily)
Date ranges (apply from Aug 10-20)
Automatic integration with order generation
Status management (active/inactive)
Customer + product relationship tracking

I remember asking Claude Code: "Can't we just... mark the order as skipped?"

Claude Code: "That would work, but then you lose the audit trail of WHY it was skipped, WHEN it was planned, and WHO requested it. Also, what if they want to increase quantity for a date range? You'd need..."

Me: "Okay, okay! Show me the 'proper' way."

Turns out, the "proper" way involves:

A separate modifications table
Date-based filtering during order generation
Validation to prevent conflicting modifications
UI to show active vs expired modifications

Did I understand all of it? No.
Did it work? Yes.
Did I move on? Absolutely.

2. Order Generation (Aug 6) - "The Math That Broke My Brain"

Here's where things got spicy.

Daily orders need to:

Look at active subscriptions
Apply 2-day pattern logic
Apply active modifications
Calculate the final quantity
Calculate the price
Create the order

The 2-day pattern logic alone made my head spin:

Me: "Wait, so if the pattern started on August 1 (a Thursday), and today is August 6 (a Tuesday), how do we know if it's Day 1 or Day 2 of the pattern?"

Claude Code: "We calculate the number of days between the pattern start date and today, then use modulo 2 to determine the cycle position."

Me: "...modulo?"

Claude Code: "The remainder after division. If days difference is even, it's the same day as the start. If odd, it's the other day."

Me: googles "what is modulo"

I spent 2 hours just testing this logic:

Create subscription with Day 1: 1L, Day 2: 2L, Start: Aug 1
Generate orders for Aug 1-14
Manually verify each day matched the pattern

It worked. I still don't fully understand modulo arithmetic, but it worked.

3. Delivery Tracking (Aug 6) - "Planned vs Actual: A Novel"

This seemed straightforward: Record what was actually delivered vs what was planned.

But then:

What if they delivered 1.5L when 1L was planned?
What if they delivered 0L (customer wasn't home)?
What about additional items (like butter or paneer)?
How do we calculate variance?
What's acceptable variance (+/- 20%)?

I ended up with:

deliveries table with planned_quantity and actual_quantity
delivery_additional_items table for extras
Variance calculations with color-coded indicators
Delivery performance reports

The report generation alone took 3 hours because I kept finding edge cases:

What if an order has no delivery?
What if a delivery has no order? (manual delivery)
What if the variance is exactly 0?

Each time I thought I was done, I'd test with real data from our business and find another gap.

The "Oh God, What Have I Done" Moments

Moment #1: Invoice Generation (Aug 13)

I needed invoices. Professional invoices. With GST. In PDF format.

Me: "I need to generate invoices as PDFs."

Claude Code: "We'll use Puppeteer to convert HTML to PDF."

Me: "What's Puppeteer?"

Claude Code: "It's a headless Chrome browser we can control programmatically."

Me: "We're... launching a whole browser... to make a PDF?"

Claude Code: "Yes."

Me: "That seems excessive."

Claude Code: "It's the best way to get professional PDFs from HTML templates."

Me: "...okay."

Installing Puppeteer:

pnpm add puppeteer

Output: Downloading Chromium... 150MB...

Me, watching the progress bar: "This is fine. Everything is fine."

Then came the invoice template. I spent an ENTIRE DAY on the invoice HTML:

PureDairy logo positioning
GST breakdown calculations
Line items layout
Subscription deliveries + manual sales in one invoice
Footer with bank details
Page breaks for multiple pages

I don't know CSS well. I know it even less after that day.

Favorite Claude Code moment:

Me: "The logo is showing up on the second page too. I want it only on page 1."

Claude Code: "Add this CSS: @page { @top-left { content: ''; } } and use thead { display: table-header-group; }"

Me: "I understood literally none of those words, but let me try it."

It worked. I still don't know why.

Moment #2: Financial Year Logic (Aug 13)

Indian financial year runs April-March. Invoice numbering needed format: YYYYYYYYNNNNN (start year + end year + sequential number).

Example: First invoice of FY 2025-26 = 2025202600001

Me: "How do we get the financial year from a date?"

Claude Code: "If the month is April or later, FY starts that year. Otherwise, it started the previous year."

Me: "So if it's March 2026, the FY is 2025-2026?"

Claude Code: "Correct. March 2026 is the last month of FY 2025-26."

Me: brain melting "Just... write the function."

export function calculateFinancialYear(date: Date): { startYear: number; endYear: number } {
  const year = date.getFullYear()
  const month = date.getMonth()

  if (month >= 3) { // April = month 3 (0-indexed)
    return { startYear: year, endYear: year + 1 }
  } else {
    return { startYear: year - 1, endYear: year }
  }
}

I tested this for an hour with different dates, convinced it would break somewhere. It didn't.

Moment #3: Payment Allocation (Aug 20-21)

This is where things got COMPLICATED.

Customers make payments. Those payments need to be allocated to:

Invoices (for subscription deliveries)
Opening balance (old outstanding from before the system)
Direct sales (cash/credit sales without invoices)

The payment screen needed to show:

All unpaid invoices for this customer
Their opening balance
All unpaid credit sales
Let the admin allocate the payment across all three

I read the conversation file payment_gaps_conv.txt where I asked Claude to analyze the entire payment system for gaps.

Claude found 12 potential issues.

Race conditions. Circular logic. Missing validations. Inconsistent outstanding calculations.

I spent 2 days fixing payment logic. The breakthrough came when Claude suggested:

"Instead of calculating outstanding from payments, calculate it from invoices and sales. Payments reduce outstanding, they don't create it."

Mind. Blown.

I'd been thinking about it backwards the entire time.

Moment #4: The IST Timezone Migration (Aug 25)

76 files. 76 files were using the wrong date pattern.

The problem:

// ❌ WRONG (uses local browser timezone)
new Date()
new Date().toISOString().split('T')[0]

// ✅ CORRECT (uses IST consistently)
getCurrentISTDate()
formatDateForDatabase(getCurrentISTDate())

Why does this matter?

If a customer in Jalgaon (IST) generates an order at 11 PM, and the browser thinks it's UTC (5.5 hours behind), it might generate the order for the NEXT day.

Invoice numbers could be wrong. Financial years could be wrong. Reports could be wrong.

Everything date-related was potentially wrong.

I created a Task in Claude Code to find and fix all 76 files.

4 hours later: All fixed. Zero TypeScript errors. All tests passing.

Do I fully understand timezone handling? No.
Do I trust the IST utilities now? Absolutely.

The "I Have No Idea What I'm Doing" Moment

It was August 23. I was working on database migrations.

Me: "I need to re-enable Row Level Security policies."

Claude Code: "That's a breaking change. Many things will break, but we can fix them slowly."

Me: panic rising "MANY THINGS? How many things?"

Claude Code: "Potentially any query that accesses the database without proper authentication context."

Me: "...which is how many queries?"

Claude Code: "Most of them."

I sat there for 10 minutes, staring at the screen, thinking:

"What am I doing? I don't understand RLS. I don't understand authentication contexts. I don't understand middleware. If this breaks, I don't know how to fix it. Why did I think I could build this? This is insane. I'm going to break everything and have nothing."

Then I took a deep breath and asked:

Me: "Can we do this incrementally? Fix one thing at a time?"

Claude Code: "Yes. Let's start with the customers table and see what breaks."

Me: "Okay. Let's do that."

We fixed it. One table at a time. With Claude Code explaining each step.

That's the moment I realized: I don't need to know everything. I need to know how to ask the right questions.

The Bulk Operations That Changed Everything

By late August, I had individual features working. But using them one-by-one was painful:

Generate orders for 145 customers? 145 button clicks.
Enter 50 sales? 50 forms.
Process 30 payments? 30 allocation dialogs.

I needed bulk operations.

Bulk Sales Entry (Aug 28):

Multi-row form with customer search
Product selection with GST auto-calculation
Keyboard shortcuts (Alt+A to add row, Tab on last field for new row)
Real-time validation
Progress tracking

Bulk Payment Entry (Sept 2):

Same multi-row pattern
Per-row allocation dialog
Auto-add on save
Real-time status badges

Bulk Modifications (Oct 3):

Customer search with subscription filtering
Product dropdown (only their active subscriptions)
Type selection (Skip/Increase/Decrease/Add Note)
Date range selection

These took FOREVER to build. Each one had unique challenges:

How to validate 20 rows at once?
How to handle partial success (10 succeed, 5 fail)?
How to show progress without freezing the UI?
How to make keyboard navigation feel natural?

But once they worked? Chef's kiss.

Data entry that used to take 2 hours now took 10 minutes.

What I Actually Learned (vs What I Pretended to Learn)

Things I Actually Understand Now:

Server Actions are like API endpoints but simpler
Forms collect data, validation checks it, actions save it
Dates are hard and timezones are harder
Database relationships are important
Good error messages save lives

Things I Still Fake Understanding:

What exactly middleware is doing under the hood
Why some things need to be client components
What "hydration" means (I know it's bad when there's an error)
Why TypeScript yells at me sometimes
How Supabase RLS actually secures data

Things I Just Trust:

If Claude Code says I need a package, I install it
If the build succeeds, it's probably okay
If tests pass, good enough
If it works in dev, it'll probably work in production (narrator: it didn't always)

PS C:\Learn\Claude code projects\milk_subs> pnpm build

> milk_subs@0.1.0 build C:\Learn\Claude code projects\milk_subs
> next build

   ▲ Next.js 15.4.5
   - Environments: .env.local, .env

   Creating an optimized production build ...
 ✓ Compiled successfully in 9.0s

./src/lib/file-utils.ts
4:29  Warning: 'formatDateForDatabase' is defined but never used.  @typescript-eslint/no-unused-vars (118 Warning like this one)

info  - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/app/api-reference/config/eslint#disabling-rules
 ✓ Linting and checking validity of types 
 ✓ Collecting page data    
 ✓ Generating static pages (56/56)
 ✓ Collecting build traces    
 ✓ Finalizing page optimization

Route (app)                                         Size  First Load JS
┌ ƒ /                                              182 B         101 kB
├ ○ /_not-found                                     1 kB         101 kB
├ ƒ /api/customers/with-unapplied-payments         182 B         101 kB
├ ƒ /api/invoices/bulk-generate                    182 B         101 kB
├ ƒ /api/print/customer-delivered-quantity         182 B         101 kB
├ ƒ /api/print/customer-invoice                    182 B         101 kB                  
├ AND MANY OTHERS
├ AND MANY OTHERS
├ AND MANY OTHERS
├ ƒ /dashboard/sales/products                      182 B         101 kB
├ ƒ /dashboard/sales/reports                       183 B         104 kB
├ ƒ /dashboard/settings                            182 B         101 kB
├ ƒ /dashboard/subscriptions                     5.57 kB         176 kB
├ ƒ /dashboard/subscriptions/[id]                  183 B         104 kB
├ ƒ /dashboard/subscriptions/[id]/edit             159 B         196 kB
├ ƒ /dashboard/subscriptions/new                   159 B         196 kB
└ ○ /icon.png                                        0 B            0 B
+ First Load JS shared by all                     100 kB
  ├ chunks/0a9a203b-524236b7ed69f56d.js          54.1 kB
  ├ chunks/7742-f909f68c9802a9dd.js              44.2 kB
  └ other shared chunks (total)                  2.09 kB


ƒ Middleware                                     67.6 kB

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand

The Resources That Kept Me Sane

Between coding sessions, I watched:

Ray Amjad - AI Coding expert with amazing simplicity. Too much to learn from him.
Riley Brown - How to quickly develop an app.
Sean Kochel - Prompting guides and avoiding pitfalls.
100x Engineers - Varun Mayya, an amazing Indian content creator on AI.

I didn't watch to master anything. I watched to understand just enough to ask Claude Code better questions.

Example:

Me initially: "The thing isn't working."

Me after watching tutorials: "The server action is returning data, but the client component isn't re-rendering. Do I need revalidatePath?"

Better questions = better answers = faster progress.

Tools That Actually Mattered

Claude Code - My primary coding partner. Wrote 90% of the code.
Perplexity - For quick answers to "what is X?" questions.
YouTube - For conceptual understanding.
Supabase Dashboard - For debugging database issues visually.
Browser DevTools - For finding why things looked broken (usually CSS).

That's it. No fancy setup. No paid courses. Just some paid tools and determination.

By End of August: What Actually Worked

✅ Customer Management - 145 real customers migrated
✅ Subscription System - Daily + 2-day patterns working
✅ Modification Tracking - Skips, increases, decreases
✅ Order Generation - Automated daily orders
✅ Delivery Tracking - Planned vs actual with variance
✅ Payment Management - Multi-allocation support
✅ Invoice Generation - Professional PDFs with GST
✅ Sales Tracking - Cash/Credit/QR payment support
✅ Outstanding Reports - Triple-level expandable reports
✅ Bulk Operations - Sales, payments, modifications

From August 5 to August 29: 24 days.

Not perfect. But functional. Actually usable. Ready for real testing.

The Lessons I Learned the Hard Way

Start Messy, Refine Later - My first invoice template was ugly. It got better. Don't wait for perfect.
Real Data Exposes Real Problems - Testing with "Customer A" and "Customer B" didn't show the issues that 145 real customers exposed.
Complex Features Are Just Many Simple Features - Payment allocation felt impossible until I broke it into: select invoice, enter amount, validate, save, update outstanding. Simple steps.
AI Doesn't Read Your Mind - Clear explanations = better code. "Make a payment system" vs "Create a form where admins can allocate a payment across multiple invoices, sales, and opening balance with validation" = very different results.
You Don't Need to Understand Everything - I still don't fully understand half the code. But I understand the business logic, and that's enough to direct the AI.
Panic is Part of the Process - Every "this will break everything" moment passed. Every one.
Build for Real Use, Not Portfolio - I wasn't trying to impress anyone. I was trying to stop losing money on spoiled milk. That focus helped.

What's Next

In Part 3, I'll take you through the real test: actually using this thing in production.

Spoiler: I found bugs I never imagined. I discovered workflows that made no sense in practice. I had to explain to my 60-year-old admin how a "browser" works.

But it's working. Real customers. Real data. Real business running on software I built.

Part 3 coming soon: "From Dev to Dairy: Production Testing, Real Bugs, and Lessons for Fellow Vibe Coders"

Read the series:

Part 1: Why I Built an ERP
Part 2: The Coding Journey (You Are Here)
Part 3: Production Testing & Lessons

About Me: I'm Dishank, a dairy farmer in Jalgaon, Maharashtra, learning to code with AI to solve real business problems. Follow along at dev.to/dishankg.

Your Questions:

"How did you handle X?" - Probably poorly at first, then Claude Code fixed it.
"Did you really not know Y?" - Correct. Still don't fully understand it.
"Can I do this too?" - Yes. If I can, you definitely can.

Drop questions below! I'll answer honestly, including the parts I still don't understand.

This and all the posts in this series are written with full assistance from Claude Code, but reflect my actual stories, experiences and problems to the fullest

Part 3 is where it gets real: bugs in production, explaining "the internet" to my admin, and why testing with real users is both terrifying and essential.

Why I Built an ERP for My Dairy Business (And Why You Should Too)

Dishank Gupta — Mon, 06 Oct 2025 12:29:46 +0000

The ₹800 Mistake That Changed Everything

It was mid-July 2025. A customer had asked us to skip their daily milk delivery from July 15-20 because they were going on vacation. They told us in mid-June—plenty of notice, right?

We wrote it down. Multiple times. In multiple places.

And we still delivered milk to their house. Every. Single. Day.

For five days, 2 liters of fresh milk sat outside their locked door in the Jalgaon heat. Spoiled. Wasted. Gone.

Cost to us: ₹800 in lost milk.
Cost to our reputation: One very angry customer.
Cost to my sanity: Watching this happen again and again and again.

This wasn't a one-time thing. This was every week. Different customers, same story. Manual notes failed. WhatsApp reminders failed. Even printed schedules taped to the delivery vehicle failed.

I run PureDairy in Jalgaon, Maharashtra—a small town where tech is still catching up. We have 50 animals, 5 employees, and about 150 customers. We're not a big operation. We can't afford expensive ERPs that cost lakhs of rupees.

But we also can't afford to keep losing money on spoiled milk and frustrated customers.

So on August 5, 2025, I did something crazy.

I decided to build my own ERP system.

From scratch.

With zero coding experience.

"But You Don't Know How to Code!"

Correct. I didn't know what Next.js was. I didn't know what Supabase was. I didn't know what TypeScript was.

But I knew my dairy business inside out. And I had Claude Code.

If you've read my previous posts (here and here), you know I'm a "vibe coder"—someone who codes by intuition, AI assistance, and sheer determination rather than formal training.

I'd built a few projects before (a task manager, a coloring page generator, a blog system). But those were hobby projects. This was different.

This had to work. Real customers. Real money. Real consequences.

The Decision Point

Here's what I knew I needed:

Customer Management - Profiles, contact info, delivery routes
Subscription System - Daily deliveries, 2-day patterns (like Mon: 1L, Tue: 2L, repeat)
Modification Tracking - Skips, increases, decreases with date ranges
Order Generation - Automated daily orders from subscriptions
Delivery Confirmation - Track what was actually delivered vs planned
Payment Management - Track payments and outstanding amounts
Invoice Generation - Professional PDFs with GST compliance
Sales Tracking - Manual cash/credit sales
Reports - Production summaries, delivery lists, outstanding reports

I looked at existing dairy management software:

Option 1: Big ERPs - ₹50,000-₹2,00,000+ setup costs + monthly fees
Option 2: Generic apps - Didn't fit our specific workflows
Option 3: Excel - What we were already doing (and failing at)
Option 4: Build it myself - ₹0 + my time + learning

The choice was obvious. I'd rather spend time learning than money we don't have.

Day 1: August 5, 2025 - "Let's Just Start"

I opened Claude Code at 6:00 PM IST with one simple goal: Get something running.

I didn't have a perfect plan. I didn't have a complete design. I just had a requirements document I'd typed out explaining what a dairy business needs.

6:00 PM - Project Setup

create-next-app milk_subs --typescript --tailwind --app
cd milk_subs
pnpm install

I had no idea what half of those flags meant. But Claude Code did.

7:30 PM - Database Schema

By 7:30 PM, I had a Supabase PostgreSQL database with 9 tables:

customers - Billing info, contact details, routes
products - Cow Milk (₹75/L), Buffalo Milk (₹80/L)
routes - Route 1 & Route 2 with personnel
base_subscriptions - Daily and 2-day pattern support
modifications - Temporary changes with date ranges
daily_orders - Generated orders with pricing
deliveries - Actual delivery tracking
payments - Payment history
product_pricing_history - Price audit trail

I didn't design this schema. I described my business to Claude Code:

"We deliver milk in the morning and evening. Some customers get 1L every day. Some get 1L on odd days and 2L on even days. We need to track when they skip, increase, or decrease deliveries temporarily. We need to know what we actually delivered vs what was planned. We need to track payments and outstanding balances."

Claude Code turned that into a normalized database schema with foreign keys, constraints, and proper relationships.

9:00 PM - Authentication + UI

By 9 PM, I had:

Login/logout working (Supabase Auth)
Protected admin routes
A responsive dashboard with a sidebar
Mobile-friendly navigation
Indian Rupee (₹) formatting

10:00 PM - Customer Management

By 10 PM, I could:

Add customers with billing names and contact persons
Store 3 phone numbers per customer
Assign them to routes
Set delivery times (Morning/Evening)
Track opening balances

11:00 PM - Subscription System

This is where it got interesting. I needed to explain subscription patterns:

Me: "Some customers want the same quantity every day—that's easy. But some want alternating patterns. Like Day 1: 1 liter, Day 2: 2 liters, then repeat. Based on a start date."

Claude Code: "Got it. We'll store daily_quantity for fixed subscriptions and pattern_day1_quantity + pattern_day2_quantity + pattern_start_date for alternating patterns."

By 11 PM, the subscription system was working. I could create subscriptions, see 14-day pattern previews, and the system would automatically calculate which day of the pattern we were on.

What I Actually Understood vs What I Faked

Let me be honest about what I knew at this point:

What I Understood:

Forms collect data and save it to database
Tables display data from database
Dates are hard (timezone issues everywhere)
Buttons need to do something when clicked

What I Had No Clue About:

What "Server Actions" were
Why some components were "client" and some were "server"
What the hell "middleware" did
Why everyone kept talking about "revalidation"
What Row Level Security actually secured

What I Just Trusted:

If Claude Code said it needed TypeScript, fine
If it said use Zod for validation, okay
If it said I need this package, I installed it
If it compiled without errors, good enough

The Resources That Saved Me

I spent the gaps between coding sessions watching YouTube:

Ray Amjad - AI Coding expert with amazing simplicity. Too much to learn from him.
Riley Brown - How to quickly develop an app.
Sean Kochel - Prompting guides and avoiding pitfalls.
100x Engineers - Varun Mayya, an amazing Indian content creator on AI.

I didn't watch them to become an expert. I watched them to understand just enough to ask Claude Code better questions.

When Claude Code said "We'll use Server Actions for this," I'd watch a 10-minute video on Server Actions. Not to master them, but to know what Claude was talking about.

End of Day 1: 11:30 PM

By 11:30 PM on August 5, 2025, I had:

✅ Complete database structure (9 tables)
✅ Authentication system
✅ Customer management (CRUD operations)
✅ Subscription management with 2-day patterns
✅ Mobile-responsive UI
✅ All code compiling without errors

From 6:00 PM to 11:30 PM. 5.5 hours.

I didn't write most of this code. Claude Code did. But I understood the business logic. I tested every feature. I knew what each button should do and verified that it worked.

Was the code perfect? Probably not.
Did it work? Yes.
Could I keep building on it? Absolutely.

Why This Matters for You

If you're a small business owner like me, sitting with Excel sheets that aren't cutting it anymore, here's what I learned on Day 1:

You Don't Need to Know Everything - I didn't know React, Next.js, or TypeScript. I learned just enough to direct Claude Code.
Start with What You Know - I knew my dairy business. I knew what deliveries looked like, what customers needed, what went wrong. That was enough.
Real Problems > Perfect Code - I wasn't trying to build the "best" ERP. I was trying to stop losing ₹800 on spoiled milk.
AI is a Co-Pilot, Not Auto-Pilot - Claude Code couldn't read my mind. I had to explain my business clearly. The clearer I was, the better it coded.
Ship Fast, Learn Faster - By the end of Day 1, I had working software. Not finished. Not perfect. But working. That momentum is everything.

What's Next

In Part 2, I'll take you through the full development journey—from modifications and orders to the nightmare that was PDF invoice generation, the payment allocation system that almost broke me, and the IST timezone migration that made me question everything.

Spoiler: I built a complete dairy ERP in about 3 weeks. It's now running in production with 145 real customers.

But it wasn't smooth. There were moments I wanted to quit. Moments I had no idea what I was doing. Moments where Claude Code said "this is a breaking change" and I panicked.

Part 2 coming soon: "Vibe Coding Through Subscriptions, Payments, and PDF Nightmares"

Read the series:

Part 1: Why I Built an ERP (You Are Here)
Part 2: The Coding Journey
Part 3: Production Testing & Lessons

About Me: I'm Dishank, a dairy farmer in Jalgaon, Maharashtra, learning to code with AI. Follow my journey at dev.to/dishankg.

Want to try this yourself? You don't need my exact code. You need Claude Code (or similar AI tools), a clear problem, and the willingness to ask "dumb" questions until things work.

Questions? Comments? Drop them below! I'll answer everything honestly—including the stuff I still don't understand.

This and all the posts in this series are written with full assistance from Claude Code, but reflect my actual stories, experiences and problems to the fullest

Next up: Part 2 - where things get messy, I learn about database migrations the hard way, and invoice generation becomes my nemesis.

From Non-Coder to Production in 4 Days: My AI-Powered App Journey (And Why Imperfect is Perfect)

Dishank Gupta — Tue, 05 Aug 2025 08:43:36 +0000

Part 3 of my AI-powered transformation series

4 days ago, I couldn't code. Today also I cannot code. I have a live app with real users.

I'm not talking about a simple landing page or a basic CRUD tutorial. I'm talking about a full-production task management application with a real database, authentication, drag-and-drop functionality (well, mostly), comprehensive testing, and deployment pipelines that would make professional developers nod in approval.

The catch? The UI looks like it was designed by someone who learned design from early 2000s websites (spoiler: that someone is me), and half the features I envisioned are still broken or missing.

And you know what? I shipped it anyway.

This is the story of how AI transformed me from someone who gets overwhelmed by the idea of coding into someone who ships production software—imperfections and all.

The Context: Building on My AI Journey

If you've been following my series, you know this isn't my first rodeo with AI-assisted development:

But this time was different. This time, I wasn't just adding features to an existing project. I was building something from absolute zero, with real users in mind, and with every intention of actually shipping it to production.

The pressure was real. The ENTP perfectionist in me was screaming.

Day 1: The Endless Possibilities Trap

As an ENTP, I have a superpower: I can see infinite possibilities in any project.

This is also my kryptonite.

I started my conversation with Claude Code with a simple idea: "I want to build a task management app." Within minutes, I had envisioned:

Hierarchical task structures with unlimited nesting
AI-powered productivity insights
Energy-based scheduling algorithms
Team collaboration features
Advanced analytics dashboards
Template systems
Bulk operations
Time tracking with focus metrics
Mobile apps
Calendar integrations
And about 47 other "essential" features

Sound familiar, fellow ENTPs?

This is where most of my projects die—drowning in the ocean of possibilities before I ever write a single line of code.

But something was different this time. Claude Code, acting like the senior developer I never had, gently guided me back to reality:

"Let's start with core task management. We can build a foundation that supports all these features, but ship something functional first."

That was my first lesson: AI doesn't just write code—it provides the discipline I lack.

Day 2-3: AI as My Senior Developer

Here's what working with Claude Code actually looks like:

Me: "I want users to be able to drag tasks to reorder them, but I don't know how drag and drop works."

Claude: "I'll implement this using @dnd-kit, which is the modern standard. Here's the complete implementation with accessibility features..."

[5 minutes later, I have working drag and drop]

Me: "This needs to work on mobile too, and what about database consistency, and what if users try to drag while the network is slow, and..."

Claude: "Let's implement optimistic updates with rollback handling. Here's how we'll structure the state management..."

This pattern repeated dozens of times. I'd describe what I wanted (often badly), and Claude would:

Interpret my unclear requirements into technical specifications
Suggest industry-standard solutions I'd never heard of
Implement complete, production-ready code with error handling I wouldn't have thought of
Explain the decisions so I actually learned something

It was like having a patient senior developer who never got annoyed when I asked "why" for the hundredth time.

The Architecture That Emerged

What's crazy is that the app Claude helped me build has architecture that would impress professional developers:

Next.js 15 with React 19 (bleeding edge tech stack)
TypeScript throughout (type safety I didn't even know I needed)
Supabase backend with 10 comprehensive database migrations
Row Level Security policies (because apparently user data should be secure, who knew?)
Comprehensive testing with Jest and Playwright
Production deployment pipeline with Vercel
Performance optimization with lazy loading and caching

I couldn't have designed this architecture if you gave me 6 months to study. But through conversation with AI, we built it in days.

Day 4: The Reality Check

By day 4, I had something that worked. Sort of.

Here's what was beautifully functional:

Users could sign up and create tasks ✅
Database relationships worked perfectly ✅
Authentication was rock solid ✅
The app was responsive and fast ✅
Real-time updates worked like magic ✅

Here's what made me cringe:

The drag and drop feature worked... sometimes 😅
My font choices looked like a ransom note 🤦‍♂️
The overall UI had the aesthetic appeal of a government form 📋
Half the advanced features I'd planned were still broken 🚧

This is where the old me would have stopped. "It's not ready. It's not perfect. What will people think?"

But here's what I realized: 70% done and shipped beats 100% perfect and never launched.

The Technical Wins (Despite Being a Non-Coder)

Let me blow your mind with what AI helped me accomplish:

Database Design That Scales

-- One of 10 migration files that create a production-ready schema
CREATE TABLE tasks (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    user_id UUID REFERENCES auth.users(id) ON DELETE CASCADE,
    title TEXT NOT NULL,
    status task_status DEFAULT 'todo',
    priority priority_level DEFAULT 'medium',
    parent_task_id UUID REFERENCES tasks(id) ON DELETE CASCADE,
    sort_order INTEGER DEFAULT 0,
    -- ... 20+ more thoughtfully designed columns
);

-- Row Level Security (because security matters)
ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Users can only access their own tasks" ON tasks
    FOR ALL USING (auth.uid() = user_id);

Testing That Would Make Pros Proud

81 unit tests covering critical functionality
Cross-browser end-to-end testing with Playwright
Production test suite that validates deployment readiness
Accessibility testing because everyone should be able to use the app

Performance Optimization

282kB initial bundle size (optimized for speed)
Lazy loading for non-critical components
Optimistic updates for instant UI feedback
Comprehensive caching strategy

Production Infrastructure

Automatic deployments on every commit
Environment management for different stages
Error tracking and performance monitoring
Database backups and security policies

This isn't no-code. This isn't a template. This is real, scalable, professional-grade software architecture that I built without knowing how to code.

From MVP to Minimum Lovable Product

The moment of truth came when I hit the deploy button.

Would it work? Would real users be able to sign up and use it?

I held my breath, visited the live URL, and... it worked. I created an account, added tasks, and watched them sync in real-time. The authentication flow was smooth. The responsive design actually worked on my phone.

Sure, the drag-and-drop was glitchy. Sure, the colors made my designer friends cry. But it worked.

More importantly, it provided real value. I started using it for my own tasks. Friends who tested it said, "The UI needs work, but this is actually useful."

That's when it hit me: Perfect is the enemy of shipped.

The Democratization of Development

Here's what this experience taught me about AI and development:

No-code tools are amazing for specific use cases. But they hit a ceiling fast. Want custom authentication flows? Complex data relationships? Real-time features? Advanced testing? You're out of luck.

Traditional coding requires years of study before you can build anything meaningful. The learning curve is steep, and by the time you're proficient, your initial enthusiasm is long gone.

AI-assisted development gives you the best of both worlds: the unlimited possibilities of real code with the approachability of guided conversation.

The gap between "I have an idea" and "I have a working product" has shrunk from years to days.

Permission to Ship Imperfect

If you're reading this and thinking, "I have an idea for an app, but I don't know how to code," here's my challenge to you:

Stop perfecting. Start shipping.

Your first version will be imperfect. The UI will look amateur. Features will be buggy. People might judge your aesthetic choices (they should—mine are objectively bad).

Ship it anyway.

Because here's what happens when you ship:

You learn what users actually want (spoiler: it's different from what you think)
You get real feedback instead of imaginary concerns
You build confidence in your ability to create
You join the exclusive club of people who ship, not just dream

What's Next?

My task tracker is live at smart-task-tracker-mofq.vercel.app. It's 70% complete, aesthetically challenged, and I couldn't be prouder of it.

The GitHub repo is public because learning should be transparent. Poke around. Judge my code. Learn from my mistakes.

But most importantly: start your own journey.

AI has democratized development in ways we're only beginning to understand. The question isn't whether you're qualified to build software—it's whether you're brave enough to ship something imperfect and learn in public.

Your move.

What project have you been putting off because it won't be perfect? What would you build if you knew you could ship it in 4 days? Let me know in the comments—I'd love to cheer you on.

Previous posts in this series:

Connect with me:

Follow my journey on Dev.to
Check out the live app: Smart Task Tracker
Explore the code: GitHub Repository

This post was made with assistance from Claude Code.

Building a Coloring Page Generator with Google AI Studio: From Prompt to Production in 30 Minutes

Dishank Gupta — Fri, 25 Jul 2025 13:46:49 +0000

This post is my submission for DEV Education Track: Build Apps with Google AI Studio.

What I Built

I set out to build a simple yet delightful web app that transforms text descriptions into black-and-white coloring pages for kids. The key prompt I used was: "Build a single-page, fully functional web application using React that allows users to generate black-and-white coloring book pages from a simple text description" - but the magic happened when I asked Google AI Studio to enhance each user prompt with specific coloring book styling instructions like "simple bold outlines, black and white, no shading, clean lines, white background." I utilized the Imagen API for image generation and implemented native Web Share functionality for easy sharing.

Demo

You can try the live app here: (Link Removed) As the free Tier was done and I couldn't afford paying for it. When it worked it worked wonders.
Github Repo Link: Coloring-Page-Generator.git

The app features a clean, minimalistic interface where users can type simple descriptions like "baby in the hands of mother" and instantly get beautiful, kid-friendly coloring pages. The generated images maintain perfect coloring book aesthetics with bold outlines and no shading.

My Experience

This project completely blew my mind in terms of speed and precision. Going from idea to a fully deployed, working app took less than 30 minutes - and that includes the time spent crafting the perfect prompt!

What surprised me most:

Prompt engineering is an art: The way Google AI Studio helped me structure the initial prompt was incredible. It asked exactly the right clarifying questions about target audience, UI complexity, and technical requirements.
Automatic prompt enhancement: The genius move was having the app automatically enhance user prompts. When someone types "dinosaur," the API actually receives "coloring book page for kids, dinosaur, simple bold outlines, black and white, no shading, clean lines, white background." This consistency is what makes the results so reliably good.
Imagen API quality: I expected decent results, but the quality and speed of the Imagen API genuinely caught me off guard. Every single generation looks like it came from a professional coloring book.

Key takeaways:

Specificity matters: The more detailed and context-rich your initial prompt, the better your final product will be.
AI understands user experience: Google AI Studio didn't just generate code - it thought through the entire user journey, including loading states, error handling, and responsive design.
Modern web APIs are powerful: Implementing native sharing functionality with just a few lines of code shows how far web standards have come.

The most magical moment was seeing the first generated image - a perfect coloring page that any parent would be happy to print out for their kids. It reinforced my belief that we're living in an incredible time where complex, useful applications can go from concept to reality in minutes, not months.

The whole experience felt less like traditional coding and more like having a conversation with an incredibly skilled developer who just happens to work at superhuman speed!

This post was written with assistance from Claude AI to help structure and articulate my experience building with Google AI Studio.

AI Pair Programming Magic: Building an Advanced Blog System in One Session (And Why I Chose Complexity Over Simplicity)

Dishank Gupta — Fri, 25 Jul 2025 10:31:00 +0000

Following up on my journey from zero to portfolio developer, this is the story of how AI assistance transformed a simple "add a blog section" request into a sophisticated, future-proof system—all in a single conversation.

The Setup: A Portfolio That Needed Something More

Remember my first post about going from zero to portfolio in one week? Well, that portfolio was working great, but something was missing. I had this beautiful website showcasing my projects, but no way to share my learning journey or connect with fellow developers through content.

The obvious solution? Add a blog section. Simple, right?

But here's where my ENTP personality kicked in. As a "perfectionistic type and thrill seeker," I couldn't just settle for basic blog links. I wanted something that would grow with me, something sophisticated, something... more.

Enter AI Pair Programming

I opened up Claude Projects with my GitHub repo connected, and what happened next was pure magic. The AI had instant access to my entire project—my themes, styles, component structure, everything. No tedious explanation of my codebase, no copy-pasting chunks of CSS. Just seamless understanding.

"I want to add a blog section for my dev.to posts," I said.

What followed was the most elegant technical conversation I've ever had.

The Decision Point: Simple vs. Sophisticated

Claude presented me with three options:

Simple External Links (30 minutes) - Basic cards linking to dev.to
Dynamic API Integration (2-3 hours) - Automatic post fetching
Advanced Embedded System (4-5 hours) - Full modal previews, pagination, interactive features

Old me would have gone for option 1. Quick, functional, done.

But new me—armed with AI assistance and an ENTP's love for comprehensive solutions—saw the bigger picture. Why build for today when you can build for tomorrow?

"Let's go with Option 3," I said. "I love the advanced option."

The Implementation: When AI Just Gets It

Here's where things got incredible. Claude didn't just provide code—it provided a complete system that perfectly matched my existing design language:

Seamless Theme Integration

The new blog section automatically inherited my light/dark theme toggle, CSS custom properties, and responsive design patterns. No theme conflicts, no style inconsistencies. It was like the blog system had always been part of my portfolio.

Zero-Maintenance Architecture

The system automatically fetches posts from the dev.to API, scales from 1 post to unlimited posts, and handles loading states gracefully. Publish a new post on dev.to? It appears on my portfolio automatically.

Future-Proof Design

1 post: Clean, featured display
3 posts: Responsive grid layout
6+ posts: Automatic "Load More" functionality
12+ posts: Full pagination system

The "Aha!" Moment: It Worked in One Go

I was expecting iterations, debugging sessions, style conflicts. Instead? It worked perfectly on the first try.

The HTML slotted seamlessly into my existing structure. The CSS extended my design system flawlessly. The JavaScript integrated with my existing classes without conflicts.

Seeing my first blog post display with that beautiful preview modal, complete with reading time, engagement metrics, and my exact color scheme—that was my aha moment. This wasn't just adding a feature; this was elevating my entire portfolio.

The Tools That Made It Possible

This success story wouldn't exist without the right AI development stack:

Cursor IDE

My go-to for "vibe coding," but I discovered it has limitations with UI/UX design decisions. Great for code implementation, not as strong for design aesthetics.

Claude Projects

The UI/UX genius in this partnership. With my GitHub repo connected, Claude understood my design language and created components that felt native to my existing system.

GitHub Integration

This was the secret sauce. By connecting my repository, Claude had complete context about my project structure, naming conventions, and design patterns.

Replit

Where my original portfolio was born, providing the foundation that made this upgrade possible.

Performance & Maintenance: The Numbers

The resulting system is surprisingly efficient:

Loading time: Blog section loads in ~200ms
API calls: Cached for performance, only fetches when needed
Bundle size: Added minimal JavaScript footprint
Maintenance: Literally zero—posts update automatically

Compare this to manual blog management where I'd need to:

Manually add each new post
Update engagement metrics
Manage responsive layouts
Handle edge cases

The advanced system eliminates all of this while providing a better user experience.

Lessons for Fellow AI-Assisted Developers

1. Context is Everything

Don't underestimate the power of giving AI full project context. The GitHub integration made the difference between generic code and perfectly integrated features.

2. Choose Your AI Tools Strategically

Cursor: Implementation and coding
Claude: Design decisions and architecture
Together: Unstoppable

3. Don't Fear Complexity

With AI assistance, the time difference between "simple" and "sophisticated" isn't what it used to be. Sometimes the advanced solution is worth it.

4. Build for Growth

Your blog section should handle your future success. If you write 50 posts next year, will your system still work elegantly?

The ENTP Advantage: Why I Love Building This Way

As someone who thrives on variety and big-picture thinking, AI-assisted development feels like coming home. I can focus on the creative decisions—the "what" and "why"—while AI handles the implementation details.

The perfectionist in me loves that we built something genuinely excellent, not just functional. The thrill-seeker loves that we pushed boundaries instead of settling for basic.

What's Next?

This blog system is just the beginning. With this foundation, I can:

Add content filtering by topic
Implement search functionality
Create series groupings
Add newsletter integration

But more importantly, I can focus on what matters most: creating great content and sharing my development journey.

For Fellow Career Changers: The Takeaway

Six months ago, building a dynamic, API-integrated blog system would have felt impossible. Today, it happened in a single conversation.

The future of development isn't about replacing human creativity—it's about amplifying it. AI doesn't make the decisions; it makes your decisions possible.

Whether you're week one or year one in your development journey, don't limit yourself to "beginner" solutions. With the right AI assistance, you can build professional-grade features from day one.

Ready to Build Something Amazing?

Here's your AI-assisted development toolkit:

Essential Tools:

Cursor IDE - AI-powered coding
Claude Projects - Design and architecture decisions
GitHub - Version control and AI context
dev.to API - Content integration

Framework:

Connect your AI to your full project context
Think bigger than your initial request
Choose tools that complement each other
Build for your future self, not just today

My Advanced Blog Implementation:
Check out the live result on my portfolio, or follow along as I continue documenting this AI-assisted development journey.

This post was created with assistance from Claude Projects, which had full access to my GitHub repository and helped architect the perfect solution for my specific needs. This is post #2 in my series documenting the journey from zero to software developer using AI-assisted learning and development.

What's your experience with AI pair programming? Have you tried building something more advanced than you thought possible? Drop a comment below—I'd love to connect with fellow AI-assisted developers!

Tags: #AI #WebDev #Career #Learning #Portfolio #DevTo #Beginners #Programming

From Zero to Portfolio in One Week: How AI-Powered Personality Analysis Transformed My Coding Journey

Dishank Gupta — Thu, 24 Jul 2025 10:51:45 +0000

The Spark That Started Everything

At 35, I never thought software development was an option for me. Traditional coding bootcamps? Too rigid. Computer science degree? Too late. But one day, scrolling through my Google feed, I stumbled across an article about something called "Vibe Coding" - using AI tools to learn programming in a completely different way.

Curiosity got the better of me. What did I have to lose?

The Game-Changing Video

While exploring Vibe Coding, I discovered this incredible video by Rick Mulready: [9 Mind-Blowing Use Cases of Perplexity Labs]

(https://youtu.be/9u9jAIl80ac?si=W4TI7eBlhhD0dZO0).

Among the various use cases he demonstrated, one particularly caught my attention - using Perplexity Labs to get a comprehensive personality analysis that goes way beyond those basic online quizzes.

I thought, "Why not?" and followed along.

The Revelation: Understanding My "Laziness"

The personality analysis hit me like a lightning bolt. For years, I'd labeled myself as "lazy" because I couldn't stick to one type of work continuously. I'd jump from project to project, lose interest in things that once excited me, and felt like something was fundamentally wrong with my work ethic.

The analysis revealed I'm an ENTP (The Innovative Problem Solver) with these key traits:

Intellectual Strengths:

Exceptional curiosity and openness to new experiences
Strong logical reasoning and analytical thinking
Natural pattern recognition and ability to see connections others miss
Innovative problem-solving that combines logic with creativity
Quick learning ability, especially through trial and error

The Breakthrough Insight:
I wasn't lazy - I was wired for variety! My brain thrives on:

Multiple projects simultaneously
Novel approaches to problem-solving
Intellectual challenges that require creativity
Learning through hands-on experimentation

Suddenly, everything made sense.

From Analysis to Action Plan

Energized by this self-discovery, I used Perplexity Labs again - this time to create a personalized career development plan. The AI analyzed my ENTP personality and crafted a 24-month software development roadmap that actually works with my natural tendencies instead of against them.

The plan included:

Weekly 24-hour learning commitment (manageable for my lifestyle)
Project variety to maintain interest
AI-assisted learning through tools like Cursor and Claude
Focus on building while learning, not just studying theory

Week One Results: The Portfolio Website

The spark I felt was incredible. It made me hungry for more and more and MORE.

Instead of starting with endless tutorials, I dove straight into building. Using Cursor (an AI-powered IDE), Replit and guidance from Claude, I created my first portfolio website in just one week.

What I learned:

HTML fundamentals through building, not reading
CSS styling with AI assistance
How to deploy a live website
Git basics for version control
Most importantly: I CAN actually do this!

The Power of AI-Assisted Learning

Traditional coding education tells you to master theory first, then build. But my ENTP brain works differently - I learn best through:

Hands-on experimentation - Start building immediately
AI pair programming - Tools like Cursor and Claude explain concepts as I encounter them
Pattern recognition - Seeing how code structures connect across different projects
Immediate feedback loops - Deploy early, iterate quickly

What's Next?

This is just the beginning of my journey. My roadmap has me building increasingly complex projects over the next 24 months, from simple web apps to full-stack applications.

But more importantly, I've discovered that career change at 35 isn't just possible - it can be the perfect time when you finally understand how your brain actually works.

For Fellow Career Changers

If you're considering a career change but traditional learning paths feel overwhelming or boring, consider this:

Understand your personality first - Use AI tools to get real insights about how you learn best
Embrace AI-assisted learning - Don't let anyone shame you for using modern tools
Start building immediately - Theory can come later
Work with your nature, not against it - Your "quirks" might be your superpowers

The future of learning is here, and it's personalized, AI-powered, and incredibly exciting.

This post was created with assistance from Claude Projects, which helped structure my thoughts and experiences into this narrative. This is my first dev.to post and the start of documenting my journey from zero to software developer. Follow along as I share the ups, downs, and everything I learn using AI-powered development tools!

What's your experience with AI-assisted learning? Drop a comment below - I'd love to connect with fellow learners and career changers!