# Build brief — a focused alternative to KFA Marketplace

> **Verdict:** Not faithfully · **Buildability:** 8/100 · **Category:** Commerce
> **Source:** https://www.canitbevibecoded.com/kfa-marketplace
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from KFA Marketplace. Verify current pricing and capabilities before acting.

## Context

**KFA Marketplace** — Run a small used-keyboard market for a community you already have.

The software is the vibe-codeable part: listings, cart, Stripe checkout, shipping labels, seller payouts. An agent can stand all of that up in a focused implementation, and the consolation prompt below does. What it cannot stand up is the market. KFA is a two-sided used-keyboard exchange where every board passes through a warehouse for inspection and PCB testing before the buyer sees it, and the fee pays for that inspection and for the crowd on both sides. A clone launches empty.

This brief describes a focused, single-operator replacement for the part of KFA Marketplace that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

List used keyboards with photos and condition notes, take Stripe Checkout payments, buy shipping labels for sellers, and track each board from sold to delivered.

- Manage a small catalogue and checkout flow for products you fulfil yourself.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Stripe account.
- EasyPost account.
- Public HTTPS deployment.
- Email provider.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build me a small two-sided marketplace for used mechanical keyboards like KFA Marketplace, for a community I
  already have. Requirements:

- Django + SQLite, server-rendered templates with vanilla JS, no frontend framework, one process.
- Sellers post listings: board name, condition notes, up to 8 photos, a fixed price, and a shipped weight in
  pounds. Single quantity, sold means gone.
- A /moderate queue: new listings stay hidden until I approve them.
- Stripe Checkout for purchase; verify the webhook signature and mark a listing sold only when the payment
  event lands, not on redirect.
- On sale, buy a label through the EasyPost API from the seller's address and the listing weight, then email
  both sides the tracking link.
- A seller ledger: each sale credits the seller's balance minus a fee percentage from .env; a /payouts page
  shows what I owe whom, paid out by hand and recorded manually.
- Stripe and EasyPost keys in .env; Django's built-in auth for buyers and sellers, no telemetry, everything
  on my own server.
- Out of scope: escrow, buyer protection, dispute flows, and inspecting anything. Trust between strangers is
  my problem, not the app's.
- README with setup, stripe listen webhook config for local testing, and the fee math.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Liquidity: buyers and sellers who are already there, which is the product.
- Warehouse QC: every board is inspected and its PCB tested before delivery.
- Buyer protection backed by that inspection instead of a seller's photos.
- Payout operations: KYC, earnings ledgers, and withdrawal handling.
- Fraud and dispute handling when a deal goes sideways.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Manageable.** A personal version is realistic if you test the critical journey and keep reliable backups.

Editorial confidence in this assessment: high. No reviewed project implementation is linked yet.

## Existing alternatives

Before building, compare these checked options:

- [r/mechmarket](https://www.reddit.com/r/mechmarket/) — Where used keyboards already trade for free; protection is seller flair, PayPal G&S, and your own skepticism
- [Mercur](https://www.mercurjs.com) — Multi-vendor marketplace software you deploy yourself; vendors, buyers, and the warehouse remain your problem

## Prior art

Working open-source software you can read, fork, or borrow from before starting:

- [Medusa](https://github.com/medusajs/medusa) — Active open-source commerce platform with modular checkout and fulfillment primitives
- [django-oscar](https://github.com/django-oscar/django-oscar) — Domain-driven e-commerce framework for Django, the stack KFA itself runs on

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/kfa-marketplace