World Vibe Web
The distributed app store for vibe-coded projects. Browse, discover, and install open-source apps from across GitHub.
Late-night home delivery of snacks, cigarettes, and daily essentials in Badda.
Translation pending
CommerceTypeScript · JavaScriptGitHub @farhansadikgalibOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
GitHub star growth between the latest completed 8-hour observations
The distributed app store for vibe-coded projects. Browse, discover, and install open-source apps from across GitHub.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Verify in one minuteAsk about other verification options
Loading the full README. The saved excerpt is shown below.
KichuLagbe is a production-grade, e-commerce-focused web application.
From this point forward, treat KichuLagbe as a production-grade application — not a prototype or a temporary project. Every implementation should strengthen the four core principles: Consistency, Reusability, Scalability, and Maintainability.
• Clean and maintainable architecture
• Scalability
• Consistency
• Reusability
• Performance
• Accessibility
• Type safety
• Strong UX
• Production-grade code quality
• Minimal code duplication
• Easy long-term maintenanceRead the full README ↗KichuLagbe is a production-grade, e-commerce-focused web application.
From this point forward, treat KichuLagbe as a production-grade application — not a prototype or a temporary project. Every implementation should strengthen the four core principles: Consistency, Reusability, Scalability, and Maintainability.
KichuLagbe follows the module structure of the reference product (https://deliverylagbe-xyz.web.app/) — a late-night food, cigarettes, and daily-essentials delivery service for Badda, Dhaka.
app_settings.homeLayout (see src/lib/home/schema.ts) and falls back to the shipped defaultsproduct_variants); the card shows a "from" price and an option picker/admin/home): reorder, show/hide, add and edit sections with a live preview of the real storefront (/preview/home in an iframe, fed by postMessage); publishing revalidates /media table) and served from /api/media/[id] with immutable caching — no extra storage service requiredEach module should be implemented as a clearly separated, reusable feature area following the architecture, consistency, and reusability standards defined below.
Before making major architectural or implementation decisions, study and follow the official documentation for the technologies used in this project. Use these as the primary technical references:
| Technology | Documentation |
|---|---|
| Next.js | https://nextjs.org/docs |
| GSAP | https://gsap.com/docs/v3/ |
| Tailwind CSS | https://tailwindcss.com/docs/installation/using-vite |
| shadcn/ui | https://ui.shadcn.com/docs/installation |
| Motion | https://motion.dev/docs |
| Lenis | https://github.com/darkroomengineering/lenis/blob/main/README.md |
| Zustand | https://zustand.docs.pmnd.rs/ |
| SWR | https://swr.vercel.app/docs/getting-started |
Always prefer official documentation and current recommended patterns over outdated tutorials, deprecated APIs, or arbitrary implementation patterns. If a technology's recommended architecture or API changes, follow the current official recommendation.
Create and maintain project-level documentation that enforces these standards. When appropriate, create or update:
AGENTS.mdCONTRIBUTING.mdThese documents act as a source of truth for future development. Do not create documentation just for the sake of creating files — documentation should be useful, concise, and actionable. Whenever an important architectural decision is made, document it so future development stays consistent.
Use a production-grade, scalable folder structure that:
Do not introduce a folder structure simply because it is popular. Choose the structure based on the actual needs of KichuLagbe. Before introducing a new architectural pattern, check whether an existing project pattern already solves the problem.
Reusability is a core requirement. Do not duplicate code unnecessarily. Before creating a new component, hook, utility, or helper:
Only create something new when it provides a clear architectural benefit.
Reusable abstractions include: UI components, layout components, section components, cards, buttons, forms, modals, navigation elements, animation wrappers, custom hooks, API utilities, validation utilities, formatting utilities, constants, types, and data-fetching helpers.
Build components to be reusable without turning simple components into unnecessarily complex abstractions.
The same design or functionality should not be implemented differently across the project without a valid reason. Maintain consistency in:
If an established project pattern exists, follow it instead of introducing another approach.
Maintain centralized design tokens for: colors, typography, spacing, border radius, shadows, transitions, and layout constraints. The UI should feel like one coherent product — an e-commerce storefront where every page, from catalog to checkout, shares the same visual language.
Use the correct animation library for the use case.
GSAP — complex timelines, scroll-driven animations, cinematic animations, advanced sequencing, high-control animations.
Motion — component animations, micro-interactions, enter/exit animations, layout animations, UI state transitions.
Lenis — smooth scrolling and scroll-related experiences where appropriate.
Do not use multiple animation libraries for the same simple interaction without a clear reason. Animations must never compromise performance, accessibility, responsiveness, user interaction, or maintainability. Respect prefers-reduced-motion where appropriate.
Use Zustand for genuinely shared client-side global state — and only when global state is actually required. Do not put everything into Zustand.
Keep stores modular and focused. Avoid a single massive global store.
Use SWR as the standard data-fetching solution for client-side / server-state fetching. Follow SWR's recommended patterns for fetching, caching, revalidation, error handling, loading states, mutations, and optimistic updates where appropriate.
Do not build a custom data-fetching abstraction when SWR already provides the functionality. Keep API-related logic organized and reusable — avoid scattering raw fetch() calls throughout UI components (product listings, cart, orders, and checkout should all consume shared data hooks).
Use TypeScript strictly and properly:
any unless genuinely unavoidable.Treat type safety as part of the architecture, not an afterthought.
Follow current Next.js App Router best practices, paying particular attention to:
Do not add "use client" unless the component actually requires client-side functionality. Keep the client bundle as small as reasonably possible.
Performance is a first-class requirement. Always consider: bundle size, client JavaScript, image optimization, lazy loading, code splitting, rendering strategy, animation performance, layout shifts, unnecessary re-renders, expensive computations, network requests, and caching.
Do not optimize prematurely — but do not introduce obvious performance problems.
Accessibility must be considered during implementation, not added later. Follow appropriate practices for: semantic HTML, keyboard navigation, focus management, ARIA where necessary, color contrast, form labels, interactive elements, modals/dialogs, navigation, and reduced motion.
Prefer shadcn/ui primitives where they provide the required accessible behavior.
Every data-driven or asynchronous UI must properly consider loading, error, empty, and success states. Do not leave users with blank screens or broken UI when data is loading or unavailable (empty carts, no search results, failed checkout, etc.). Create reusable patterns for common states instead of reimplementing them on every page.
Write code another professional developer can understand and maintain.
Avoid: duplicate logic, giant components/hooks/stores, hardcoded repeated values, magic numbers, unnecessary abstractions, deeply coupled components, dead code, unused imports, deprecated APIs, temporary hacks, and copy-pasted implementations.
Prefer: small focused components, clear naming, single responsibility, composition, reusable utilities, strong typing, predictable data flow, and explicit boundaries.
Before implementing or modifying a feature:
Do not blindly create new files or abstractions.
If existing code does not follow these standards, do not automatically rewrite the entire project. Instead:
Always think beyond "make it work." For every implementation ask:
"Would this still be a good solution if KichuLagbe grows significantly?"
Consider maintainability, scalability, reusability, performance, accessibility, developer experience, future feature requirements, and long-term consistency. Do not over-engineer simple requirements — but do not take shortcuts that create unnecessary technical debt.
When making implementation decisions, prioritize in this order:
Consistency + Reusability + Scalability + Maintainability
Every implementation in KichuLagbe should strengthen these four principles rather than work against them.
From now on, treat these guidelines and the official documentation above as the project's development standards, and apply them consistently to every future task.