I Vibe Coded the Entire Vibe with Fynd Platform. Here Is What I Learned

Last week, I published a piece called Clock Speed arguing that AI transformation is not a migration — it is a complete rebuild. That organisations need to die at their old tempo and be reborn at AI speed. I meant every word.

So when it came time to build the platform for Vibe with Fynd — our new AI-native mentorship initiative — I decided to practise what I preach. I did not hand it to a product team. I did not write a PRD and wait for sprints. I sat down and vibe coded the entire thing end to end. Frontend. Backend. Database. Admin dashboard. AI-powered deep research. Email notifications. Push notifications. Referral system. Calendar integration. FaceID authentication. The works.

This is the behind-the-scenes story of how that happened.

What Is Vibe Coding?

The term was coined by Andrej Karpathy in February 2025:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Collins Dictionary named it Word of the Year for 2025. By 2026, it has gone from a meme to a legitimate development methodology. The core idea is simple: instead of writing code line by line, you describe what you want in natural language, and AI generates the implementation. You review, iterate, and direct — but you are no longer the one typing semicolons.

I have been building software for over 14 years. I co-founded Fynd, an AI-native commerce platform with 1,200+ people that powers 20,000+ stores across India and beyond. I am not new to code. But vibe coding is something fundamentally different. It is not about whether you can code. It is about whether you should — when AI can do it faster, and often better, than you can.

The Platform I Built

Let me walk you through what the Vibe with Fynd platform actually does, because this is not a landing page with a contact form. It is a full-stack application with serious backend logic.

The public-facing site is designed to match Fynd's corporate design language — clean, white, minimal, with the kind of typographic precision you would expect from a company that obsesses over design. It includes a landing page with animated sections, a detailed page about the Fynd Foundation, session tier cards, thought leadership content, and an inquiry form with LinkedIn URL validation, honeypot spam detection, and IP-based rate limiting.

The admin dashboard is where the real complexity lives. It is a password-protected panel with an additional layer of FaceID/WebAuthn biometric authentication for mobile access. Inside, you get a full CRM-style pipeline view of all inquiries — filterable by status (new, contacted, qualified, proposal sent, accepted, scheduled, completed, deferred, archived), with inline notes, status transitions, and detailed inquiry cards.

The AI-powered deep research engine is perhaps the most interesting piece. When a new inquiry comes in, the system can automatically generate a comprehensive briefing document about the person and their company. It uses configurable LLM models (Gemini 2.5 Flash, GPT-4.1, Claude Opus 4, and others) to produce a multi-thousand-word research dossier — complete with executive summary, background, key talking points, and strategic recommendations. The admin can also ask follow-up questions against the research, creating an interactive Q&A layer on top of the briefing.

The referral system allows the admin to generate unique referral links for existing participants, track nominations, and manage the referral pipeline separately from direct inquiries.

Notifications are handled through multiple channels: email via Resend, push notifications via VAPID/Web Push, and in-app owner notifications through the Manus platform.

How I Actually Built It

Here is the part that matters. I did not write this code in VS Code over two weeks. I built it through a series of conversations with an AI agent on the Manus platform. The process looked something like this:

Phase 1: Design and Landing Page. I started by describing the design language I wanted — Fynd.com's aesthetic: white backgrounds, near-black text, light gray sections, pill-shaped buttons, rounded cards. I described the content sections: hero, stats, about Farooq, session tiers, who is this for, thought leadership, inquiry form, footer. The AI generated the entire landing page, complete with Framer Motion animations and responsive breakpoints.

Phase 2: Backend and Database. I described the data model — inquiries with status tracking, research results, notes, referral links, referrals, push subscriptions, calendar events. The AI generated the Drizzle schema, the tRPC routers, the database helpers, and the migration files. I reviewed, adjusted field names, and pushed the schema.

Phase 3: Admin Dashboard. This was the most iterative phase. I described the pipeline view I wanted — cards grouped by status, with click-to-expand detail views, inline notes, status transitions, and a settings panel. The AI built it, I tested it on my iPhone, found issues (date inputs invisible on iOS, FaceID not working with proxy domains), and we iterated until it was right.

Phase 4: AI Research Engine. I described the research flow — take an inquiry's name, company, role, and LinkedIn URL, and generate a comprehensive briefing document. The AI built the prompt engineering, the model configuration system, the research settings UI, and the follow-up Q&A system. I tested it with a real inquiry and refined the prompts until the output quality was genuinely useful.

Phase 5: Referral System, Notifications, and Polish. The final phase was about rounding out the feature set — referral links with tracking, email notifications, push notifications, the Fynd Foundation page, thought leadership PDFs, and dozens of small UX fixes.

The entire process took a fraction of the time it would have taken a traditional product team. Not because the AI is smarter than my engineers — it is not — but because the feedback loop is measured in seconds, not days.

What Surprised Me

The quality of the first pass. I expected to spend most of my time fixing AI-generated code. Instead, I spent most of my time refining design decisions and business logic. The structural code (routing, database queries, API endpoints, form validation) was consistently solid on the first attempt.

The depth of the backend. Vibe coding is often associated with simple frontends: landing pages, portfolios, basic CRUD apps. But this platform has real backend complexity: rate limiting with IP tracking, constant-time password comparison for security, WebAuthn credential management, JWT session tokens for biometric auth, S3 file storage, multi-model AI orchestration with streaming, and a configurable research pipeline. All of it was vibe coded.

The iteration speed on mobile UX. Some of the hardest bugs were mobile-specific. Date inputs being invisible on iOS Safari, FaceID failing because the WebAuthn RP ID did not match the production domain behind a proxy. These are the kinds of issues that would take a traditional team days to diagnose and fix. In vibe coding, I described the symptom, the AI diagnosed the root cause, and we shipped the fix in minutes.

The test suite. The AI did not just write the features. It wrote 136 tests across 14 test files. Unit tests for every router, validation tests for LinkedIn URLs, security tests for input sanitisation and rate limiting, research tests with mocked AI responses. When I found that one test file was accidentally inserting test data into the production database (because it was not mocking the database module), the AI identified the root cause and fixed it in a single iteration.

What This Means for Clock Speed

In my Clock Speed piece, I argued that AI collapses "the work behind work." Vibe coding is the most visceral proof of that argument I have experienced.

Consider what "the work behind work" looks like for a traditional product build: writing a PRD, getting alignment from stakeholders, breaking it into tickets, estimating story points, assigning to sprints, writing the code, writing the tests, code review, QA, staging deployment, bug fixes, production deployment. Each step has its own clock speed, its own latency, its own institutional friction.

With vibe coding, most of that collapses. The PRD is the conversation. The alignment is immediate because there is one decision-maker. The code and tests are generated together. The review happens in real-time. The deployment is continuous. The entire feedback loop, from intent to production, is compressed from weeks to hours.

This is not about replacing engineers. Fynd has brilliant engineers, and they build things I could never vibe code: distributed systems, real-time inventory management, enterprise-grade commerce infrastructure. But for a focused product like Vibe with Fynd — a self-contained application with clear requirements and a single stakeholder — vibe coding is not just faster. It is a fundamentally different way of working.

The Meta Point

Here is the thing that makes this story recursive: I vibe coded a platform about vibing with Fynd. The medium is the message.

When a founder comes to a Vibe with Fynd session and asks me, "How do I make my organisation AI-native?", I can now point to the very platform they booked through and say: "I built this. Not my team. Me. Using AI. In a fraction of the time it would have taken traditionally. And it has a full backend, an AI research engine, biometric authentication, push notifications, email integration, a referral system, and 136 passing tests."

That is not a slide deck. That is not a case study. That is proof.

The fastest way to convince someone that the clock speed has changed is to show them something that should not exist yet, but does. Vibe with Fynd is that proof. The platform itself is the argument.

Practical Takeaways

For founders and leaders considering vibe coding for their own projects, here is what I would suggest:

Start with something real. Do not vibe code a to-do app. Build something your business actually needs. The constraints of a real project (real users, real data, real edge cases) are what make vibe coding genuinely useful rather than a parlour trick.

Be specific about design. The AI is remarkably good at generating code, but it needs clear design direction. "Make it look modern" produces generic output. "Match Fynd.com's design language: white backgrounds, near-black text, Inter font, pill-shaped buttons, 2xl rounded corners" produces something distinctive.

Test on real devices early. The gap between desktop preview and mobile reality is where most vibe-coded projects fall apart. I caught critical bugs (invisible date inputs, broken biometric auth) only because I tested on my actual iPhone throughout the process.

Do not skip the backend. Vibe coding is not just for frontends. The most valuable parts of the Vibe with Fynd platform (the AI research engine, the referral tracking, the notification system) are all backend logic. If you are only vibe coding landing pages, you are leaving most of the value on the table.

Treat it as directing, not delegating. Vibe coding is not "tell the AI what to build and walk away." It is a continuous conversation where you are the product manager, the designer, and the QA engineer, and the AI is the developer. The quality of the output is directly proportional to the quality of your direction.

What Comes Next

The Vibe with Fynd platform is live at vibe.fynd.academy. It is serving real inquiries, generating real research briefings, and managing a real pipeline. Every rupee it generates goes to the Fynd Foundation.

But more importantly, it is a living example of what happens when you take the clock speed argument seriously. When you stop talking about AI transformation and start living it. When you sit down, open a conversation with an AI, and build something that would have taken a team weeks, in hours.

The code exists. The tests pass. The platform works. And I vibed the whole thing.