Build spec · beta

Request access: how to build it

The page at getarca.co/private asks what the creator wants, collects goal details then financial context, shows a preliminary answer, and asks for contact last. Live booking is Cal.com with an ARCA reference code (no figures in the URL). The Prototype tab is the working reference.

1. Principles

• Desire first, data second, contact last. No name, email or phone before the first answer is shown.
• A human path (Jada) exists on the first screen and stays available on the answer, contact and success screens.
• Never a dead end. Any failed lookup, unusual goal or incalculable result falls back to "Tell us in your own words" or to the Jada path.
• Do not fabricate precision. If ARCA cannot answer well, it says so.
• Self-reported numbers are never presented or stored as verified.

2. Screen map

3. Session model

A server-side session is created on the first goal selection and referenced by an httpOnly cookie (arca_sid, 24 hour sliding expiry). Save on every step with a debounced PATCH, so a refresh or a return visit resumes where the user left off.

intake_session {
  session_id            text pk            // "sess_" + random
  created_at, updated_at, last_step
  goal_type             enum               // see section 4
  goal_details          jsonb              // per goal, see prototype fields
  financial_inputs      jsonb              // integers in dollars, enums for ranges
  preliminary_result    jsonb null         // see section 5
  result_status         enum null          // user_reported_estimate | plaid_derived | verified
  contact               { first_name, email, phone? } null
  converted_at          timestamptz null   // set when email is captured
  jada                  { note?, slot?, booking_id? } null
  utm, referrer, user_agent_hash
}

4. Goal types

Enum: apartment, home, car, quit_job, savings, grow_business, custom. Changing goal after Back clears goal_details and financial_inputs.

5. Calculation layer

Run on the server (POST /api/intake/sessions/:id/result) so formulas and constants can change without a front-end release. The prototype contains a client-side copy of the same rules so the flow can be tried end to end.

result {
  label            "Your apartment"
  headline         "You’re close."              // human answer, shown largest
  metric           "You make about 2.9× the monthly rent."
  explanation      string
  helping[]        string[]                      // only when we can name them
  holding_back[]   string[]
  next             "ARCA can help you …"
  calc             { formula, inputs, value, assumptions }   // never shown as the headline
  confidence       "estimate" | "none"
}

6. Goal details input

• Goal details are typed or chosen from options. There is no listing URL field, no image upload and no extraction anywhere in this flow.
• Every field is a plain input (money, text or option chips). Optional fields are tagged "optional" and never block Continue.
• If listing or image support is added later, it may only suggest values that the user then confirms. It should not become a dependency of the first answer.

7. Email capture and conversion

• No account before screen 6 unless technically required. Flow: temporary session → preliminary result → email → convert session into lead/user.
• Conversion is a single transaction: write contact, set converted_at, create or upsert the lead by email, link the session. Idempotent on (session_id, email).
• Preserve every prior answer. The user never re-enters anything.
• Validate email client-side and server-side. Phone is optional and never required.
• Bot protection on session creation and on submit (invisible challenge plus rate limit per IP).

8. Jada scheduling

Three entry points open the same scheduling flow: goal ("Talk it through with Jada"), answer and contact ("Rather talk it through? Schedule time with Jada"), and success ("Schedule time with Jada"). The optional note ("Anything you want Jada to know?") is stored as jada.note.

• No financial questions before scheduling on this path.
• If the user has not given an email, the scheduling tool captures name and email. Create a lead from the booking webhook and link it to the session.
• If the session has goal data, include it in the booking notes and in Slack so Jada has context.
• Tool choice is open (Cal.com, Calendly or similar). It must offer a webhook for booking.created and prefill of name and email.

9. Beta Slack handoff

On email_submitted (and on jada_call_scheduled when no email was captured earlier), post one message to the beta intake channel through the existing failsafe workflow. The Slack tab in the prototype renders this message from the live session.

Actions are Slack interactive buttons that call the internal API with the session_id. "Correct financial inputs" and "Recalculate" must write a new result with its own timestamp and keep the previous one.

10. Analytics

Primary funnel: visitors → reached a meaningful answer (preliminary_answer_shown) → chose to book or email the result (email_submitted or jada_call_scheduled after an answer). Email conversion by itself is not the headline metric. Fallback answers do not count as "reached an answer".

11. Failsafes

12. Open questions

• Scheduling tool and its webhook (Cal.com, Calendly or other).
• Retention for anonymous sessions. Suggested 30 days if never converted, then delete.
• Calculation constants (10% down, 20% savings rate, 7% APR, 15% revenue set-aside) are placeholders and need sign-off before the answers are shown to real users.
• Whether "Close" should offer to save and resume by email once the user has seen an answer.