Go Local

Many Filipino vendors, artisans, and small-scale entrepreneurs still rely on physical selling locations, referrals, social media posts, and chat-based orders to reach customers. Those channels are familiar and accessible, but they do not always give sellers a structured way to present products, manage listings, or make their shop easy to discover beyond their immediate network.

For buyers, local products can be difficult to find in one place. Authentic food items, handmade goods, small-batch products, and community-based merchandise may be scattered across posts, pages, and conversations. A buyer may want to support local sellers but still need a clearer way to browse, compare, and purchase products.

Go Local was built around that gap. We treated the project as a local-first marketplace MVP, not just a generic e-commerce store. The goal was to create a platform where sellers can build a digital storefront and buyers can discover local Filipino products through a more organized marketplace experience.

The problem is fragmentation. Sellers may post products in different places, update availability manually, answer repeated questions through chat, and manage orders without a shared system. That makes it harder for small vendors to appear consistent and professional online even when their products are strong.

Buyers face the other side of the same problem. Product information may be incomplete, outdated, or spread across different channels. Browsing becomes slow, comparison becomes difficult, and checkout often depends on manual coordination. The lack of structure can make local buying feel less reliable than it should be.

The project also needed to account for different responsibilities inside a marketplace. Buyers, sellers, and administrators should not all see or manage the same things. Without clear role separation, a marketplace can become confusing, hard to moderate, and difficult to scale.

Go Local gives the local-commerce workflow a structured web platform. Sellers can register, manage their profile, create product listings, and present their items through a digital storefront. This gives small vendors a clearer product presence than scattered posts or informal chat selling alone.

Buyers can browse the product catalog, view product details, add items to cart, and move through a checkout flow. The marketplace experience gives users a more centralized way to discover authentic local products while keeping the product journey familiar: browse, inspect, add, and purchase.

Administrators have their own side of the system for user management, marketplace visibility, and analytics. This matters because a marketplace is not only a buyer-facing catalog; it also needs moderation, monitoring, and role-based control so sellers, buyers, and admins can each work inside the correct part of the platform.

Go Local was a four-member group project, and I served as the lead developer. My role was to guide the technical direction of the platform, help define the marketplace structure, and implement major parts of the full-stack system. I treated the project as a working MVP with real buyer, seller, and admin workflows.

I worked across the Next.js application, TypeScript structure, Tailwind interface, Supabase integration, PostgreSQL-backed data model, authentication, and role-based access. The most important part was making sure the marketplace did not feel like separate pages stitched together, but like one flow where sellers manage products, buyers shop, and administrators monitor the platform.

As lead developer, I also helped align the group around the product scope. A marketplace can grow quickly in many directions, so the MVP needed discipline: focus on registration, product listings, storefronts, cart and checkout behavior, admin analytics, and user management before adding heavier production concerns such as payment settlement, logistics, and vendor verification.

The workflow begins with role-based registration. A seller enters the platform to create a storefront and manage product listings, while a buyer enters to browse and purchase. Separating those paths early helps the app show the right actions to the right user instead of forcing one generic dashboard to serve everyone.

On the seller side, the workflow centers on product management. A seller can add products, update product information, organize listings, and build a shop presence that buyers can inspect. This turns the seller's inventory into structured marketplace records instead of leaving product details scattered across posts or messages.

On the buyer side, the workflow follows the shopping path: discover products, inspect details, add items to cart, and proceed through checkout. In the MVP, the checkout flow models the order path and product selection experience. From there, the platform can later mature into production payment handling, fulfillment tracking, and seller-side order management.

The admin workflow supports visibility across the marketplace. Admin users can monitor accounts, review activity, and use analytics to understand what is happening inside the platform. That gives Go Local an operational layer instead of making it only a storefront demo.

Go Local is built with TypeScript, Next.js, Tailwind CSS, Supabase, and PostgreSQL. Next.js provides the web application structure for the marketplace screens, seller flows, buyer flows, and admin views. Tailwind CSS supports fast, consistent interface development across the different role-based surfaces.

Supabase provides authentication and the PostgreSQL-backed data layer. The system is organized around marketplace records such as users, profiles, seller data, products, cart items, checkout or order records, and admin-facing activity. This keeps the product flow connected from account identity to storefront activity and buyer interaction.

Role-based access is a core architectural concern. Buyers, sellers, and administrators need different permissions, and Supabase Row Level Security helps enforce those boundaries at the data layer. That matters because marketplace safety is not only a UI concern; the backend also needs to protect who can read, create, or modify records.

The architecture follows the marketplace model. The frontend gives each role a usable workflow, Supabase Auth manages identity, PostgreSQL stores the commerce records, and RLS keeps access rules close to the data. That structure made Go Local a full-stack MVP rather than a static e-commerce mockup.

Go Local is a working MVP built by a four-member group. It is not positioned as a production marketplace with live public vendor adoption yet, but it includes the core structure needed to demonstrate the local-commerce workflow: buyer and seller registration, product catalog, seller dashboard, cart and checkout flow, admin analytics, user management, authentication, and database-backed records.

At this stage, the project is strongest as a full-stack marketplace proof of concept. It shows how local vendor visibility, buyer discovery, and administrative control can be connected in one platform. The MVP validates the product structure before heavier production concerns such as payment processing, logistics, dispute handling, and vendor verification are added.

The next level of maturity would involve testing the platform with real sellers and buyers, improving storefront customization, adding order management, integrating production payments, defining fulfillment rules, and expanding admin moderation tools.

The main outcome of Go Local is a working marketplace MVP that connects seller storefronts, product management, buyer browsing, cart behavior, checkout flow, admin analytics, and role-based access. It demonstrates an end-to-end local-commerce system instead of only a product listing page.

From an engineering perspective, the project strengthened my experience with full-stack development, Supabase Auth, PostgreSQL data modeling, Row Level Security, TypeScript, and role-based product design. It required thinking through how users, products, carts, orders, and admin records should relate inside one marketplace system.

From a product perspective, Go Local shows how small-vendor visibility can be supported through accessible digital infrastructure. The MVP gives local sellers a clearer online presence while giving buyers a more organized way to discover and purchase Filipino products.

Go Local taught me that a marketplace is more than a catalog. A catalog only shows products, but a marketplace has to support roles, trust, inventory, discovery, checkout, moderation, and operational visibility. Each role needs a different workflow, and the system has to keep those workflows connected without making them confusing.

The project also made role-based access feel practical. It is easy to think of permissions as a backend detail, but in a marketplace they shape the product itself. A buyer should not manage seller records, a seller should not see admin controls, and an admin needs enough visibility to keep the platform manageable. That is why Supabase Auth, PostgreSQL, and RLS were important parts of the system design.

As lead developer, I learned how important it is to keep a group-built MVP focused. Marketplace ideas can expand into payments, delivery, chat, verification, analytics, promotions, and more. The challenge was to build the core flow first: sellers create products, buyers shop, admins monitor, and the database keeps those actions organized.