DevMatch — the spec

A two-sided marketplace where solo business owners post software needs and hire vetted developers. Buyers move from idea to signed contract without wading through unverified profiles; developers win work by showcasing real, confirmed output. The entire flow — post, filter, propose, pay — lives in one focused product.

---

Decisions locked

---

The core loop

1. Buyer posts a need — describes the project, budget range, and required skills.
2. Developers are surfaced — skill-based search and filtering show relevant developer profiles with verified work samples.
3. Developers submit proposals — each proposal references portfolio evidence matching the buyer's need.
4. Buyer reviews and selects — compares proposals side by side, clicks Hire.
5. Escrow is funded — buyer deposits payment into escrow before work begins; funds are held until delivery is accepted.
6. Work delivered, escrow released — buyer confirms delivery and funds transfer to the developer.

---

v1 scope

Developer Portfolio with Verified Work Samples
Each developer profile hosts uploaded work samples (images, files, URLs) that are flagged as verified by the platform before the profile goes live. Lives on the Developer Profile screen.

Escrow Payment Protection
Buyer funds are held in escrow at the point of hire and released only on buyer confirmation of delivery. Protects both sides from non-payment and non-delivery. Lives on the Checkout and Project Status screens.

Skill-Based Filtering and Search
Buyers filter the developer directory by skill tags (e.g., React, iOS, Shopify). Search returns ranked results based on tag match and profile completeness. Lives on the Browse Developers screen.

---

Deliberately later

• Project posting with scope templates — v1 validates demand with freeform posts; structured templates add value once common project types are known from real data.
• Milestone tracking and delivery verification — escrow covers a single release in v1; milestone splits are a natural upgrade once average project size is understood.
• Built-in messaging and file sharing — early buyers and developers can coordinate by email; native messaging justifies build cost once retention data proves repeat usage.
• Dispute resolution for project mismatches — escrow rules handle edge cases manually at this volume; a formal disputes workflow earns its complexity at scale.
• Ratings system with work portfolio proof — verified portfolio samples serve as trust signals in v1; a ratings layer becomes meaningful only after enough completed transactions exist to make scores credible.

---

Data model sketch

• users — id, name, email, phone, role (buyer | developer), created\_at
• developer_profiles — id, user\_id, bio, skill\_tags, portfolio\_verified (bool), verification\_date
• work_samples — id, developer\_profile\_id, file\_url, title, description, verified (bool)
• projects — id, buyer\_user\_id, title, description, budget\_min, budget\_max, required\_skill\_tags, status, created\_at
• proposals — id, project\_id, developer\_user\_id, cover\_note, quoted\_price, status, created\_at
• escrow_payments — id, project\_id, proposal\_id, amount, status (held | released | refunded), funded\_at, released\_at
• notifications — id, user\_id, channel (email | sms), event\_type, sent\_at, payload

---

Screens

• Home / Landing — explains the value proposition and routes buyers to post and developers to apply.
• Browse Developers — searchable, filterable directory of verified developer profiles.
• Developer Profile — full profile with skill tags, bio, and verified work samples.
• Post a Project — freeform form for buyer to describe need, budget, and required skills.
• Project Detail / Proposals — buyer reviews incoming proposals and selects a developer.
• Checkout / Escrow Funding — buyer deposits funds into escrow to activate the engagement.
• Project Status — tracks escrow state and surfaces the delivery confirmation action for the buyer.

---

How to use this document

• Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build the product with you step by step.
• Hand it to a developer as the complete v1 brief — scope, data model, and screen list are all here.
• Keep it as the single source of truth while you build, so every decision stays anchored to the 30-day goal of 5 paying customers.