PROJECT / NEEED
Neeed
Neeed got interesting when the product stopped asking which category a provider belongs to and started asking what the provider can actually do.
An AI-adaptive service marketplace that moved away from category-first UI toward any-provider, any-request matching.
ACTUAL PROMPT / THREAD TRACE
understand the whole new concept of the app and with any kind of service, any kind of request
WHY IT MATTERS
It is a marketplace architecture story: AI onboarding, structured match profiles, public safety, and request routing all have to agree.
HOW TO READ THIS
Each entry is a dated design decision: the pain point, the response, the proof source, and the visual artifact when the archive had one.
DATED JOURNEY
DATE INDEXAny service meant AI-generic first
The old mistake would be building a bespoke UI for every service category.
Varun locked the product direction: providers describe any service, AI turns that into typed capability data, and matching decides compatibility.
The important phrase is not 'AI marketplace.' It is 'no provider wins until the customer accepts a specific quote.'
Neeed should be treated as an AI-adaptive, bilingual service marketplace for any provider and any customer request.
Neeed any-service plan thread and knowledge brief.
Unknown services stopped falling into events
A broad category is a bad hiding place for a specific request.
The resolver still sent unresolved requests into `events`. That violated the product model because unknown services needed exact custom buckets.
The fix protected the long tail: if the system cannot name the category, it should preserve intent instead of pretending the request is generic events.
request-service-matching.ts regression slice in the Neeed thread.
Raw request text could not leak into public surfaces
A request card is public. A customer transcript is not.
The product boundary became explicit: public cards use generated safe labels and summaries, not exact addresses, contact details, uploads, or raw first-person request text.
This is the kind of UX/security detail that decides whether an AI product feels trustworthy.
Neeed public request flow contract and request runtime notes.
AI profiles needed craft-specific proof
Generated profile data is useless if it looks like a placeholder.
Body-art, digital design, cakes, cleaning, and entertainment scenarios forced the generic public profile to become service-aware.
The UI had to carry capability, style, audience, pricing, geography, proof, and matching evidence without exposing raw intake fragments.
Neeed profile screenshot outputs and public-profile wiki.
The matrix became the product memory
If a service passes only in theory, it has not passed.
Signup, Services settings, public profile rendering, request matching, and inbox visibility were wired into browser and test gates.
This is why Neeed reads like serious product work: every broad claim gets narrowed into a checkable scenario.
Knowledge brief verification commands and output screenshots.