Docs.

Prepared 2026-06-11 for external operations review. Self-contained: no codebase access is assumed. Where a software surface matters operationally it is named by its URL (e.g. /office/reservations). Everything described as "live" is built and deployed; gaps and manual steps are called out explicitly in §15.

1. What the business is

studio.chat S.A.S. is an audiovisual production company in Medellín, Colombia. Production is the identity; everything else exists to monetize the gear, space, and skills the production work already requires. The company operates bilingually (English and Spanish) with the same weight given to both — site, emails, and contracts all render in the client's language.

Revenue comes from four lines, deliberately unequal in maturity:

Studio space rental rides along with gear: two rentable spaces in Medellín — a cyclorama (US$200/day, US$300 deposit) and a lounge (US$180/day, US$200 deposit) — bookable as line items on the same reservation as gear.

Positioning for rentals (verbatim from the operating docs): "We rent select gear from our production kit — when it's not on set." This is not a rental house competing with volume dry-hire operations. The catalog is small and curated (currently ~138 items, ~121 published, backed by ~217 physical units), rented to producers rather than the general public, and the studio's own shoots always have first claim on the gear — enforced by booking it out (see §4 blackouts), not by recall.

2. Current status: pre-launch

The site is live but gated: every public URL shows a countdown holding page. Launch is scheduled for June 26, 2026, 20:26 Bogotá time, at which point the gate lifts automatically. There are no clients yet; all reservation data in the system is synthetic test fixture. This means the operation described below is fully built but essentially unexercised — an important framing for any process review: the costs are real, the workflows are real, but no throughput data exists yet.

A small pre-launch checklist (arming scheduled jobs, proofing the first production email, dropping the gate) is maintained in the repository.

3. How a rental runs, end to end

The funnel is quote-first: there is no online checkout, no public real-time availability, and no instant booking. Clients browse the public catalog, send dates and a kit list, and the desk replies with a quote. This is a deliberate v1 choice — graduate to instant checkout only if volume justifies it.

Every rental is a reservation moving through a seven-stage lifecycle, with two branch states:

inquired → quoted → held → confirmed → returned → settled → closed
                                  (cancelled and disputed branch off)

• inquired — a request exists (desk-entered today; the public form feeds the same pipeline).
• quoted — the desk priced it. Quoting is automatic from the pricing engine (§5): the desk picks gear and dates, and the system computes the rental fee, IVA, and deposit. The client is emailed the quote automatically at this moment.
• held — the dates are reserved while payment/paperwork completes. A hold expires after one week if not confirmed; an hourly automated job cancels lapsed holds.
• confirmed — the booking is locked. The client is emailed a confirmation automatically. The system hard-blocks confirmation if the reservation's window over-demands any item (other holds/confirmed bookings plus maintenance blackouts exceed the units owned) or double-books a space — the desk must resolve the conflict first.
• Gear out is not a stage. Physical handoff is scan state: at pickup, staff scan each unit out (binding specific serial numbers to the reservation); the first scan stamps the actual pickup time. The reservation stays "confirmed" while gear is in the field. A confirmed reservation past its return time is overdue (flagged daily by an automated job, with an advisory late-fee calculation — never charged automatically).
• returned — the last unit scanned back in flips the reservation. Inspection happens here (see below).
• settled — money squared: deposit released (target: within 3 business days of a clean return) or deductions agreed. The client is emailed a receipt automatically.
• closed — archival end state. cancelled can occur up to confirmation; disputed branches from returned/settled when the client contests deductions, and resolves back to settled or closed.

Pickup and return windows are one-hour blocks constrained to the studio's operating schedule (§9) — clients can't be offered a 7 a.m. pickup on a day the studio opens at 9.

Inspections. Policy requires a documented condition walkthrough at pickup and at return — per-item category checklists (camera body, lens, audio, lighting, grip, general), photos, and a client signature both directions. Return discrepancies become claims (damage, loss, late, cleaning) assessed against the deposit at settlement. Current state: the checklists exist as policy documents; the digital inspection UI is designed and queued to build, including hard rules that gear cannot leave without a signed pickup report and a reservation cannot settle without a signed return report. Until it ships, inspections are paper/manual.

Blackouts (production-always-wins, with a catch). Internal shoots reserve gear by entering blackouts — per-unit, date-ranged "out of service" windows that subtract from rentable supply. The precedence rule is honest: a confirmed client booking wins over a later internal need; there are no recalls. The studio protects itself by blacking out before conflicting bookings confirm. Specific units can also be removed from supply indefinitely via condition states (in service, retired, lost).

4. The rental gate (who may rent)

Three requirements, nothing else: a 100% replacement-value deposit, a government ID for the responsible party, and a verified contact phone and email. There are no vetting tiers, no insurance requirement, and no certificates of insurance — all removed as policy. The deposit is the protection model (§6).

Client identity is verification-driven: an account is "verified" when it holds active email, phone, and one government-ID verification record — tracked per-document with expiry support in the client file.

5. Pricing and the money model

Currency. All money is stored and quoted in USD; Colombian pesos are display-only, converted at a rate snapshot that is frozen onto each reservation so invoices reproduce exactly. 19% IVA applies to the quote total (not the per-day rate).

Day rates are formula-driven cost recovery, computed from each item's replacement value (not its purchase price) through six equipment classes (camera body, lens, lighting, support, electronics, accessory), each with tunable lifetime, residual value, maintenance+insurance+overhead load, target margin, and utilization assumptions:

AnnualCost = (RC − RC·residual)/life + RC·(maintenance + insurance + overhead)
NetDayRate = max(floor, AnnualCost / (365 · utilization · (1 − margin)))
             rounded to the nearest $5

Calibration anchors on the local market: at the default 5% billable utilization (~18 rental days/unit/year) the flagship Sony FX6 lands at $262/day with IVA against a competitor's published $264. Cost recovery is roughly linear with value while the market is regressive (charges cheap gear proportionally more), so inexpensive items deliberately price below market unless given a per-item override. All parameters are editable live in the office (/office/pricing); saving reprices the whole catalog instantly. Weekly rates and a weekend rule (three calendar days at day rate) follow the same engine. No discounts of any kind for now (owner-decided); a manual per-reservation adjustment field exists for desk judgment.

Payments are recorded, not processed. The system models deposits, captures, releases, balance charges, refunds, and damage charges across cash, transfer, Stripe, and Wompi — but no payment provider is integrated. The desk records each payment manually. The designed future split is Stripe for USD cards and Wompi for COP-native rails, with deposit-as-authorization-hold semantics; it is gated on opening those provider accounts.

6. The protection model: deposit-only

There is no gear-insurance market to speak of in Colombia, so the model is a refundable deposit equal to 100% of replacement value (an FX6 rental carries a $7,000 deposit). No insurance, no COI, no damage waiver — the deposit covers loss and damage entirely. Late returns accrue against a 60-minute grace window with a per-day late-fee formula (advisory calculation today; charged at desk discretion). Cleaning is a condition penalty, not a flat fee — assessed only if gear returns in worse condition than it left (percentage TBD; logged manually at settlement). This concentration of risk into the deposit is the single most important policy for an operations review to stress-test.

7. Clients and identity

One account record per human across every role — client, staff, or both. Clients extend the account with a commercial profile (company, tax ID, address, tags, internal notes), verification records, and standing (neutral / blacklist; "repeat" is derived from paid reservations, not stored). Sign-in is passwordless: Google OAuth for everyone, optional passkeys for returning clients, magic links for clients on non-Google email. First sign-in auto-creates a client account (open signup); clients land in a read-only portal showing their reservations.

The desk can create reservations for people with no online presence (email or phone only); live duplicate detection matches both fields as the desk types, and a merge tool combines duplicate accounts (the older account always wins; merges are audited and admin-gated unless names match).

8. Staffing, roles, and access control

Three office roles in ascending authority: staff (read-only), manager (writes to reservations, blackouts, spaces, links, clients), administrator (everything: inventory, pricing, schedules, copy, data console, team). Role grants — not email domain — define staff; contractors on personal Gmail are supported, flagged when outside the company Workspace (where 2-step verification is org-enforced). Lockout guards: the earliest administrator ("super administrator") and the last remaining administrator cannot be demoted. Office sessions idle out at 15 minutes and hard-cap at 12 hours. Every write across the system lands in an append-only audit log (/office/logs, admin-only) attributing actor, action, source (human / API / agent / automated), and before/after state.

Today the staff roster is effectively the owner; the tooling (guides, tooltips, role gates) is built so that desk staff can be onboarded without retraining the system.

9. Operating hours and scheduling

Weekly hours are configured in the office (/office/schedules) per day, in two flavors: open (walk-in pickup/return) and by reservation (staff present only for scheduled handoffs). Defaults: Tuesday–Friday open 9:00–12:00 and 13:00–17:00 plus by-reservation 17:00–21:00; weekends by-reservation 9:00–21:00; Mondays closed. The reservation form offers pickup/return blocks only inside these hours; closed days offer none.

10. Inventory operation

The database is the canonical inventory (a legacy Google Sheet pipeline was retired; a one-click CSV export now serves as the spreadsheet mirror). Two levels:

• Items — the catalog entry (name EN/ES, category, rates, replacement value, availability, published/private). Create/edit in the office.
• Assets — physical units of an item (serial, location MDE/LAS, condition, acquired cost/date, notes). Condition drives supply: like-new/good/fair units count as rentable; service/retired/lost units don't. Editable in place per unit.

Kits bundle items for fast quoting — picking a kit on the reservation form expands it into its member lines at normal per-item pricing (a kit is a shortcut, not a separately priced product; bundled-rate kit pricing is an explicit future decision). QR-coded short links (qr.studio.chat) on physical gear resolve to catalog pages with scan analytics.

Replacement values are maintained against current retail (B&H as the reference), priced per-item so identical units rent identically while per-unit purchase prices feed ROI separately.

11. The desk's daily tooling (office map)

Everything operational happens in /office (dark-themed admin, gated by role):

A plain-language staff guide with annotated screenshots teaches the reservation system; in-product tooltips explain every lifecycle stage at the point of use.

12. Automation

• Client emails (bilingual, automatic, audited): quote on quoting, confirmation on confirming, receipt on settling, pickup/return reminders the day before. Failures never block desk operations; every send/skip/failure is in the audit log.
• Scheduled jobs: hourly hold-expiry (cancels week-old unconfirmed holds), daily reminders (8:00 Bogotá), daily overdue flagging (13:00 Bogotá) with advisory late-fee math. Armed at launch via a secret; harmless until then.
• Hard guards in software: the double-booking block at confirmation; quantity caps at creation (can't reserve more units than exist); hold state machine (no skipping stages); audit on everything.

13. The public site and client surfaces

The marketing site (EN/ES) carries the production-studio identity first — home, projects, stills, team, services hub (cinematography → contact; podcasts; rentals; stills), contact, FAQs, blog, privacy/terms. The rentals section is deliberately secondary: an overview ("how it works" in four steps), the curated catalog with category filters and per-item detail pages (specs, included accessories, unit availability count), and a request-a-quote CTA — no prices shown without a quote, no checkout. A/B copy variants are testable from the office. The portal gives clients read-only reservation status; a future phase 2 (designed, not built) adds pay-a-deposit-to-confirm once a payment provider exists.

Contracts today: rental terms are finalized per-reservation, signed manually (Google Docs flow as designed stopgap), and the executed PDF is uploaded to the reservation; an in-office template system with merge-field rendering and a searchable executed-contract archive is landing now. The public terms page notes that standing terms of service are still being finalized — a legal gap worth closing before launch. Digital signing is deliberately staged: at-the-counter signatures will be captured in-house with the inspection UI; a remote e-sign API (Documenso or similar) is penciled in for contracts once volume justifies it.

14. Infrastructure, in operational terms

Hosted on managed platforms (Vercel for the application, Supabase for database/storage/auth) with three environments: production, a development preview at dev.studio.chat, and local development. Releases ship multiple times per week behind automated test gates (typecheck, lint, unit suite with a 100%-coverage money-path gate, and an end-to-end suite against a real database — ~196 unit and ~46 integration tests today). Database backups are daily with 7-day retention; point-in-time recovery is not enabled (a deliberate cost choice worth revisiting at real volume). Media and documents live in cloud storage — public for catalog imagery, private with signed links for contracts (and, soon, inspection photos). Errors report to Sentry. One operational quirk is documented and routine: database schema changes are applied to each environment manually at release time.

15. Gaps, manual steps, and honest risks (for the review)

1. Payments are manual. No provider integration; deposits and charges are recorded by hand. The deposit hold is therefore a real money transfer or a promise — not a card authorization. Biggest process gap.
2. Inspections are paper. The digital checklist/signature flow with its hard gates (no gear out unsigned, no settlement unsigned) is designed but not yet built. Until then the deposit's evidentiary support is manual photos and signed paper.
3. Deposit-only protection. 100% replacement deposits are unusual and create sticker shock ($7,000 to rent a $7,000 camera); conversion impact is unknown pre-launch. The alternative (insurance) genuinely doesn't exist locally — but expect this to be the most negotiated policy.
4. Standing legal terms are unfinished (the terms page says so publicly). Per-reservation contracts carry the load.
5. Single-person operation today. All roles, knowledge, and approvals concentrate in the owner; the tooling is built for delegation but no delegation has happened.
6. No real-time availability for clients — by design, but it puts the desk's response latency directly in the conversion path. The quote target is same-day; reminders and expiries are automated, but the first reply is human.
7. Cleaning-fee percentage and a few pricing details are TBD; the late-fee is advisory-only pending a charging decision.
8. Cinematography capacity — the strategic line is gated on hiring; the site deliberately under-sells it.
9. No PITR on the database; 7-day backup window only.
10. Pre-launch unknowns: utilization (priced at 5%), demand mix (gear vs. space vs. podcasts), and the ≥4 paid rentals/month target by three months post-launch are all assumptions awaiting contact with reality.

16. Success criteria (as written before build)

• Operationally: zero double-bookings against production shoots; every rental tracked quote → return → settlement in one system. (The double-booking guard and the lifecycle tracking are now enforced in software.)
• Commercially: each rental covers insurance-equivalent risk loading, depreciation, and handling; ≥4 paid rentals/month within 3 months of launch.
• Brand: rentals convert without diluting the production-studio positioning.