LabBridge — the spec

A two-sided marketplace connecting researchers, students, and independent scientists who need specialized lab equipment or expertise with labs and professionals willing to rent access and time. The platform handles discovery, scheduling, and payment in one flow — removing the cold-email friction that currently makes ad-hoc lab access nearly impossible.

---

Decisions locked

---

The core loop

1. A researcher signs up, builds a profile listing their field and past projects.
2. They search for equipment by type and location, filtering by availability window.
3. They select a lab, pick an open time slot, and submit a booking — either confirmed instantly or sent for host approval.
4. The lab host reviews the request (if approval-gated), accepts, and the researcher receives email or SMS confirmation.
5. Payment is captured at confirmation; the researcher shows up and completes their session.
6. The booking closes and the slot returns to available inventory.

---

v1 scope

Researcher profiles — Stores name, institution, specialization tags, and a list of past projects. Lives on the public-facing profile page and acts as the trust signal that hosts evaluate before approving a booking.

Equipment search with location and availability filters — Full-text and category search across all listed equipment, filterable by distance, equipment type, and open time windows. Lives on the main discovery page and is the entry point for every booking.

Calendar booking with instant or approval-gated confirmation — Researchers pick a slot from the host's live calendar. Hosts toggle between instant-confirm and manual-approval per listing. Confirmation triggers an email or SMS to both parties. Lives on the listing detail page.

Lab host dashboard — Hosts set per-session pricing, block or open availability, and action incoming booking requests (approve / decline) from a single view. Lives behind host authentication as the primary management screen.

---

Deliberately later

• Messaging before booking — in-app chat adds trust but also adds surface area; email handles pre-booking questions well enough for v1 volume.
• Session feedback and safety compliance tracking — meaningful once there is enough booking history to benchmark; building it now risks scope bloat before product-market fit.
• Recurring bookings with discounts — valuable for ongoing projects but requires subscription billing logic; a clean v2 addition once the single-session flow is proven.
• Equipment insurance and liability waiver management — high legal and integration complexity; should follow a clear signal that liability is blocking bookings, not precede it.

---

Data model sketch

• users — id, name, email, phone, role (researcher | host), hashed password, created_at
• researcher_profiles — user_id, institution, specialization_tags[], past_projects[]
• lab_listings — id, host_user_id, name, location (lat/lng + address), description, equipment_ids[], pricing, approval_mode (instant | manual), active
• equipment — id, lab_listing_id, name, type/category, specs
• availability_blocks — id, lab_listing_id, start_datetime, end_datetime, status (open | booked | blocked)
• bookings — id, researcher_user_id, lab_listing_id, availability_block_id, status (pending | confirmed | declined | completed), confirmed_at
• payments — id, booking_id, amount, currency, payment_status, provider_reference

---

Screens

• Discovery / Search — entry point; equipment search with location, type, and availability filters surfaced as primary controls.
• Lab listing detail — full equipment list, pricing, host profile summary, and the live calendar slot picker.
• Booking confirmation — shows booking summary, captures payment, and displays confirmation status (instant or pending approval).
• Researcher profile — public page showing specialization, tags, and past projects; linked from booking requests so hosts can evaluate.
• Host dashboard — manage listings, set pricing and availability, action pending booking requests.
• Booking history — shared view for both roles showing past and upcoming sessions with status.
• Auth screens — sign-up and login with role selection (researcher or host).

---

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 feature decision can be checked against locked decisions and stated scope.