Dec 2025/Fullstack/course

Warungpedia

Built as a software-project coursework artefact, Warungpedia translates marketplace roles, discovery, verification, and monitoring into a typed Next.js application backed by Supabase services.

project links
Domain
Fullstack
Role
Fullstack Product Engineer
Output
Web App
Category
UMKM Marketplace
Project Framing

A source-backed case study built for recruiter review

This reading path makes the problem choice, evidence quality, user framing, execution decisions, and proof trail visible without overstating what the sources support.

Project Type
course

Marketplace web app project that models buyer, seller, and admin workflows for local UMKM commerce.

Orientation
Hybrid

Demonstrates product-oriented fullstack thinking by turning a marketplace domain into explicit roles, setup documentation, and maintainable application boundaries.

Core Stack
Next.js · TypeScript · Tailwind CSS · Supabase

Next.js App Router application using React views, API route handlers for backend logic, Tailwind CSS for UI, and Supabase for PostgreSQL, auth, and storage concerns.

Why This Problem Mattered

Problem framing before execution

The case-study layer starts with why this problem was selected and how the context justified investment.

Problem Framing Map

Issue

UMKM marketplace workflows require different paths for sellers, buyers, and administrators, making role clarity and data integration central to implementation quality.

Context

Warungpedia is positioned as a software-project coursework artefact built around explicit role modeling, setup documentation, and fullstack application boundaries using Next.js and Supabase.

Why Selected

It is useful for Wave 2 because it adds a practical commerce-oriented fullstack narrative with stronger source-backed implementation detail than a recovered-source candidate.

Problem statement

UMKM marketplace workflows require different paths for sellers, buyers, and administrators, making role clarity and data integration central to implementation quality.

Solution thesis

Structured the project around role-aware marketplace flows, Next.js app routes, API handlers, and Supabase-backed data/auth/storage integration.

Research and Evidence

What supports the narrative

Evidence is surfaced with its source type and credibility note so the recruiter can quickly see what is directly backed versus intentionally constrained.

Role-backed marketplace framing
local

The README documents buyer, seller, and admin marketplace roles as part of the product scope.

Credibility: Supported by the current metrics and README-backed source references.
Typed fullstack baseline
local

The package metadata confirms Next.js, TypeScript, Tailwind CSS, React, and Supabase dependencies.

Credibility: The source package directly supports the architecture and stack claims already present in the record.

Credibility Notes

  • Warungpedia should be presented as a role-aware marketplace implementation artefact, not as a live UMKM platform with verified seller or buyer traction.
  • No GMV, transaction, retention, or production-operations claim is introduced without stronger evidence.
Who The User Was

User framing stays explicit

When formal research artefacts are not available, the page still explains who the work served and why that user framing is justified by the existing sources.

Primary user
Marketplace participants who need different flows depending on whether they are buyers, sellers, or administrators.

The clearest source-backed differentiation in this project is the explicit role modeling across marketplace responsibilities.

Reviewer stakeholder
Technical reviewers checking whether the fullstack architecture meaningfully reflects marketplace complexity.

The project's value for the portfolio is in how it translates role requirements into typed app structure and setup guidance.

Decision Flow

How design thinking translated into decisions

The goal is to show the trace from research and insight to concrete product or system decisions, then to the outcomes those decisions supported.

Design Thinking Flow

Each step keeps the movement from evidence to action explicit before the rationale expands it.

  1. Step 1
    Role clarity first

    Started by framing the marketplace around distinct actor responsibilities rather than building generic screens.

    Signal: Buyer, seller, and admin pathways became the organizing model.
  2. Step 2
    Unified app boundary

    Used one Next.js App Router application to keep UI and API route handling close to the same domain logic.

    Signal: Fullstack reasoning stays understandable for a coursework-sized implementation.
  3. Step 3
    Setup-aware delivery

    Included Supabase environment and onboarding guidance as part of the implementation story.

    Signal: The project is easier to review as a real fullstack artefact, not only a code snapshot.

Decision Rationale

Each decision keeps the path from insight to execution visible before ending on the outcome signal.

Role-aware structure
Insight

Marketplace apps become confusing when multiple actor journeys are collapsed into one generic flow.

Decision

Structured the application around buyer, seller, and admin marketplace workflows.

Outcome

The project demonstrates product-oriented fullstack thinking through clearer role boundaries.

Supabase-backed completeness
Insight

A commerce-flavoured learning artefact becomes more convincing when auth, database, and storage concerns are treated together.

Decision

Used Supabase for PostgreSQL, auth, and storage integration inside the application narrative.

Outcome

The implementation reads as a more complete fullstack system without overstating production maturity.

Solution and System Execution

Execution choices and delivery details

This section preserves the technical and operational substance: architecture, responsibilities, trade-offs, and implementation quality signals.

System Design

Next.js App Router application using React views, API route handlers for backend logic, Tailwind CSS for UI, and Supabase for PostgreSQL, auth, and storage concerns.

Source-backed Impact

Demonstrates product-oriented fullstack thinking by turning a marketplace domain into explicit roles, setup documentation, and maintainable application boundaries.

Responsibilities

  • Translated marketplace role requirements into application structure
  • Prepared Supabase environment and database setup guidance in project documentation
  • Organized frontend and API implementation around role-specific marketplace workflows

Stack Decisions

  • Used Next.js App Router to keep UI and API route handling in one application boundary
  • Used Supabase to cover database, authentication, and storage integration needs
  • Used TypeScript and Tailwind CSS to keep implementation typed and UI iteration consistent

Trade-offs

  • Accepted Supabase environment setup dependency for a more complete fullstack learning artefact
  • Kept the public portfolio framing focused on source-backed structure instead of unsupported production claims

Challenges

  • Keeping buyer, seller, and admin concerns understandable in one coursework-sized codebase
  • Documenting environment setup without exposing secrets or implying a live production deployment
Outcomes and Proof

What was delivered and what can be verified

Outcome claims remain conservative and source-backed, while proof records and recruiter-safe links surface the strongest verification trail available.

Validation Signals

  • README documents buyer, seller, and admin marketplace roles.
  • Local archive includes README and package metadata for reviewer onboarding.

Source-backed Outcomes

  • README documents buyer, seller, and admin marketplace roles
  • Source package uses Next.js, TypeScript, Tailwind CSS, React, and Supabase dependencies
  • Local archive includes README and package metadata for reviewer onboarding
Retrospective and Limits

What the project proves, and what it does not

Strong case studies show both what was learned and where the current evidence stops.

Retrospective

Next iteration should add request-flow diagrams, test evidence, and clearer database migration instructions before claiming operational readiness.

Evidence Limits

  • Current sources do not provide live marketplace usage, transaction validation, or production deployment proof.
  • The project should remain framed as a source-backed fullstack artefact for marketplace workflows.

Lessons

  • Marketplace products benefit from explicit role modeling before UI implementation
  • Reviewer-friendly setup documentation increases the value of a fullstack portfolio artefact