# Room: launch and learning plan

**Five-second hook:** “One more thing” doesn’t have to mean free work.

**Initial audience:** Independent brand and identity designers delivering fixed-price identity packages for small businesses, with an active client request outside the agreed scope. The app supports other design fields through discipline-specific examples and free-form input, but the first pilot stays narrow. Start with this moment, not everyone who freelances.

**Urgent need:** Protect a project’s budget and launch date without damaging the client relationship. The broad underlying need is agreeing on tradeoffs when someone asks for more. The narrow entry point is another concept, a new deliverable, or a late revision.

## What makes this worth trying

The product’s unit of value is a client-ready decision: add the work for a stated fee and time change; substitute a named deliverable at the same budget and timeline; or defer it while preserving the current plan. A concrete substitute makes “no” less confrontational. No onboarding, account, AI generation, or full project-management setup comes before the result.

This is a positioning hypothesis, not an invention claim or validated demand. Existing tools already cover scope creep and formal change requests. ScopeDue, for example, describes priced change requests and approval tracking; Room deliberately tests a lightweight three-choice conversation with an explicit scope swap. The broader freelancermap freelancer guide also discusses difficulty pricing work and handling scope conversations. These sources support the problem context, not willingness to use this particular product.

Primary sources reviewed October 13, 2026:

- [ScopeDue: freelance change requests](https://scopedue.com/freelance-change-requests/)
- [freelancermap: freelancer guide](https://www.freelancermap.com/blog/freelancer-guide/)

**Why this could earn attention:** a recognizable client phrase gets attention, a usable reply earns trust, and a card gives a second person a real benefit. Sharing is part of completing the work, not a requirement to unlock it. This is a modest distribution mechanism to test, not a promise of virality.

## Working MVP

- Responsive landing page and builder with 13 design disciplines, relevant examples, and a custom path for other work.
- User-supplied project, request, baseline scope, hours, rate, currency, schedule impact, and an explicit scope swap.
- Deterministic extra-fee calculation; the user confirms the swap fits the original budget and timeline.
- Three-option client card and complete copyable client message.
- Shareable card snapshots encoded in the URL fragment; shared data excludes hourly rate and hours.
- Client view with three selectable directions and an editable, copyable reply.
- Local draft persistence, a clear-draft action, malformed-link handling, and clipboard fallback.
- Local event instrumentation and a test-event inspector/export on the prototype notes page.
- Question and suggestion form emailed to the maker through FormSubmit after one-time inbox confirmation.

**Time-to-value target:** under 60 seconds for a designer to create a usable card; measure it in observed sessions. The filled example demonstrates the output immediately but must not count as genuine activation.

## Limits to make explicit

The deployment is public. Anyone with a card link can open it. The copyable message is usable immediately in any existing conversation.

There is no multi-user database, account system, hosted approval record, e-signature, payment collection, automatic client notification, live card updates, or server-side analytics. Choosing a card option prepares a reply; it does not approve or send anything. Keep final agreement in the existing client conversation.

Links are fixed snapshots. Anyone with a link and site access can read and forward the included details. They cannot be revoked, updated, or expired. Do not include confidential client information. For a production release involving sensitive projects, add opaque, expiring, revocable links and access controls before collecting that data.

The app stores the draft in local browser storage, not on an app server. Event data is stored only in the current tab session, capped at 500 records. Feedback form fields are sent to FormSubmit for email delivery and are not mixed with these local events. No aggregate reporting or cross-person attribution exists yet. Google Fonts and the hosting platform receive ordinary asset/page requests; form contents are not sent to them by the application.

## Useful sharing loops

1. **Designer → client:** the designer shares concrete options to resolve a real request. The client receives a clear decision, not a sales pitch. The message works even if the client never opens Room.
2. **Client → their own project:** a quiet, optional “Have a project of your own? Make a card” link appears after the decision flow. No referral gate, reward, forced branding in the copied message, or contact scraping.
3. **Designer → peer:** with explicit permission, share a redacted before/after example that shows how a scope conversation changed. Let readers use a complete free template without visiting the app.

The client and maker audiences only partly overlap. Do not assume every recipient becomes a creator. Peer recommendations may be a stronger loop; validate both.

## Instrumentation already in the prototype

| Event | Meaning | Allowed properties |
| --- | --- | --- |
| landing_view | Builder page opened | source: direct or client-card |
| builder_started | First manual input in the visit | none |
| discipline_selected | Designer changed the example field | discipline enum |
| example_selected | An example loaded | example enum; discipline enum |
| card_created | Valid three-option card produced | draft_type: example/custom; discipline enum; elapsed_ms since page load |
| message_copied | Clipboard write succeeded | none |
| share_dialog_opened | User reviewed disclosure and link | none |
| share_link_copied | Card link clipboard write succeeded | none |
| recipient_view | Valid shared card opened, excluding explicit preview | none |
| option_selected | Recipient prepared a reply | option enum |
| reply_copied | Recipient reply clipboard write succeeded | option enum |
| recipient_to_builder | Maker page opened from client-card CTA | none |
| client_preview | Maker preview opened or its reply copied | optional option enum |
| draft_cleared | User cleared the saved draft | none |

The prototype records no project text, money, rates, hours, names, full URLs, referrers, IP addresses, or user identifiers in these events. Clipboard failure does not falsely log a successful copy. Link copies are intent signals, not evidence of delivery. Repeat events are raw actions, not unique users.

## Production measurement plan — not yet connected

For a consensual public pilot, attach a first-party collection endpoint to the existing event adapter. Minimize collection, disclose it, honor an opt-out, and avoid fingerprinting. Use an ephemeral session identifier to deduplicate sessions, an opaque card ID with no client data for confirmed opens, and a bounded acquisition-source enum. Do not log URL fragments, form content, copied text, or raw referrers. Set raw-event retention to 30 days and publish a deletion process. Avoid durable person tracking until it is necessary and consented to.

**Primary outcome:** weekly real project conversations resolved with Room, verified by an opt-in follow-up. Count a resolution only when the designer reports an agreed direction. Card creation, option selection, and copied replies are proxies.

**Funnel (unique pilot sessions/cards, once collection exists):** qualified landing → custom card created → message/link copied → client viewed (link path only) → reply copied → designer confirms resolution. Report copy-message and link paths separately; message-only use will not create a recipient-view event.

**Secondary metrics:** custom-card creation and copied-message rate by selected discipline (including Other); median custom-card time; useful-card rate; client comprehension; actual scope decisions; seven-day repeat use among designers who received another qualifying request; recipient-to-creator conversion; peer referrals reported voluntarily.

**Guardrails:** confusing or accidentally sent prices, invalid swaps, client discomfort, confidential details in links, and pressure to grant unpaid work. Any material accidental disclosure pauses the link pilot. Do not interpret zero complaints in a tiny sample as proof of safety.

## Launch experiments

All thresholds below are predeclared pilot decision rules, not claimed results or industry benchmarks.

| Experiment | Method and sample | Decision rule |
| --- | --- | --- |
| Problem + usability | Recruit 8 independent brand and identity designers with a recent real scope change. Observe them create a redacted card without coaching. Ask what they use now and whether it is faster. | Continue if at least 6/8 produce an accurate card within 90 seconds, and at least 5/8 say they would use it for the actual request. Repair comprehension before promotion if not. |
| Hook comprehension | Show the landing hero for 5 seconds to 10 target designers. Ask who it is for, what it does, and what happens next. | At least 8/10 identify extra client work and a concrete next step. If not, revise the headline before testing reach. |
| Utility-led distribution | With moderator permission, post one complete scope-swap template and clearly labeled demo in each of two relevant design communities. Invite voluntary feedback; no bulk DMs. | Among at least 30 qualified visits, aim for 30% custom-card creation and 20% message/link copy. Below target: interview drop-offs; do not add features to compensate blindly. |
| Real client loop | Recruit 10 consenting designers with live requests. They decide whether to send a redacted card or message. Follow up once with permission. | At least 6/10 report a clear next step, 5/10 get an explicit direction, and no serious disclosure or mispricing issue. Record client confusion and refusals. |
| Repeat usefulness | Follow the same participants for 14 days. Denominator is only designers who actually receive another qualifying request. | At least 40% use Room again when the situation recurs. If the eligible sample is below 5, collect more observations rather than infer retention. |
| Peer usefulness | Offer 5 pilot designers a permission-based, anonymized before/after they can share with peers, or a plain template with no app branding. | Look for at least 3 voluntary peer introductions and ask newcomers why they tried it. No reward, forced post, or referral requirement. |

Use one landing hook during the first pilot. Small traffic does not justify an A/B winner claim. After 100 qualified visits and qualitative feedback, compare “protect your time” against “give your client a choice” using a fixed-duration, preplanned test; report uncertainty rather than declare significance from a few conversions.

## Fourteen-day launch sequence

- **Days 1–2:** recruit 8 designers who consent to research; verify the actual trigger and current workaround. Run five-second and task tests. Fix only repeated friction.
- **Days 3–4:** prepare two permissioned, redacted examples; finalize privacy disclosures and check that the public prototype is ready for external visitors. Add first-party aggregate analytics only if needed for the pilot.
- **Days 5–7:** publish a useful free template in two moderator-approved communities. Offer one short, opt-in walkthrough. Disclose that you built the tool. Ask for problems and outcomes, not upvotes.
- **Days 8–10:** observe the first ten real scope conversations. Ask clients, through the designer and with consent, what felt unclear. Track agreements manually with redacted notes.
- **Days 11–14:** measure eligible repeat use and voluntary referrals. Publish the learnings, including where the tool failed. Decide whether to refine the tradeoff interaction, reposition toward a different trigger, or stop.

No outreach, community posting, or analytics enrollment has been performed by this build. The prototype is already public.

## Suggested public introduction

“I’m a builder testing a small tool for independent brand and identity designers. When a client asks for extra work, it helps you offer three options: add it for a clear fee, swap a planned item, or save it for later. Here’s a free example you can copy without signing up. If you’ve handled this recently, what would make the response useful—or uncomfortable—to send?”

## What to build only after evidence

If people send the cards and resolve real requests, next add revocable hosted links and a simple history of explicitly confirmed decisions. Test willingness to pay for reusable project baselines and recurring usage, not for unlocking the first useful reply. Do not add AI, an all-in-one freelancer suite, or automated outreach until user behavior demonstrates a need.