Acts — Clickable Prototype Estimate

Prepared by Bryan S. Holland for Steve / Acts Ventures · July 22, 2026

What this is

Phase 1 is delivered and signed off: the core metaphor, the taxonomy, and 13 wireframed screens. The clickable prototype was deliberately pulled out of Phase 1 so it could be priced on its own, with eyes open, once the design direction was locked. This document is that number.

The prototype is a working, clickable model of the redesigned Acts app — something you open in a browser on your phone and click through like the real thing. It is built directly from the approved wireframes and the 16 designed .dc.html files already produced in the design pass, so most screens are adapted and stitched together rather than built from zero.

There are two ways to build it, priced separately below. Both produce the same front-end and the same on-phone experience. They differ in what happens underneath.

• Option A — Standalone HTML. A static, self-contained prototype with mock data held in memory. Shareable as a single link on a static host. No backend, nothing to sign into, nothing to keep running.
• Option B — Vercel + Supabase. The same front-end, but with real persistence underneath: acts, prayers, and comments are stored; guest sessions work without a login; seeded demo content survives a reload and is shared across everyone who opens the link.

A short recommendation on which to choose is at the end.

Option A — Standalone HTML

A single shareable link. Mock data lives in the page, so anything a viewer does resets on reload — which is exactly right for a walkthrough in a partner or investor meeting.

| Module | Hours (low – high) | |---|---| | Project setup + tokens/fonts + shell nav | 4 – 7 | | Feed (3 views incl. map) | 9 – 16 | | Act detail ×2 + share/invite | 5 – 8 | | Request flow ("I Need an Act") | 5 – 9 | | Completion ×4 (incl. live timer) | 7 – 12 | | Story card + instant act page | 5 – 8 | | Comments + report UI | 4 – 6 | | Donate pages (excl. Stripe test) | 3 – 5 | | Pastor broadcast + QR | 3 – 5 | | Skin A pass (older-adult skin) | 5 – 9 | | Seed content + polish + mobile QA (incl. widget mock) | 6 – 11 | | Total | 56 – 96 hrs | | *Optional line item: Stripe test-mode donate buttons* | *+3 – 5* |

Total range: 56 – 96 hrs (59 – 101 with the Stripe test-mode line item).

Timeline: roughly 1.5 – 2.5 weeks, running back-to-back after sign-off. Working checkpoints along the way, not a black box.

What each module covers (Option A)

• Setup + tokens/fonts + shell nav. Project skeleton, the locked light palette (paper #f7f5ef, accent #ec612b, ink #111), the two brand fonts (Cormorant Garamond Italic for display, Instrument Sans for UI) wired from the provided TTFs, and the thumb-zone bottom nav — the white Give · Receive · Donate slider. Mobile-first, and checked in the Facebook and Instagram in-app browsers since that is where Steve opens it first.
• Feed (3 views). Cards as the default, an immersive full-screen swipe view (the 18–25 skin), and a Map view defaulting to Oakland with a changeable center, the selected pin rendered big/bold/red, and the Nearby · Completed · Requests filters. The map may be static/mocked here, or a Leaflet / Google Maps embed if a live map reads better.
• Act detail ×2 + share/invite. The open act and the geographic act as two visibly distinct layouts, each with Share (native share sheet / copy link) and Invite.
• Request flow. The "I Need an Act" path: PRAY dominant, then layer (me / another / parish / world), then ask (prayer / candle / visit), then mode (once / group), with the other act types behind a smaller secondary list.
• Completion ×4. All four completion variants, each demonstrable: SMS (the thread UI simulated in-prototype), two-tap, trust, and a live 5:00 timer that actually counts down.
• Story card + instant act page. The auto-generated story card on completion ("Susie prayed for Linda's mom") with a share action, and the instant act page that a QR or link lands on — no login, one-tap pray, then the "20% — save your act?" prompt.
• Comments + report UI. Encouragement comments with a flag → report sheet, plus a mocked moderation-queue view. Interface only.
• Donate pages. The in-app pointer page and the separate donate web page ($10 / $20 / $50 / $100 / custom). Buttons non-functional by default; a Stripe test-mode version is the optional line item above.
• Pastor broadcast + QR. Pick a need, then a QR code plus copy-link. QR generation is real.
• Skin A pass. A second audience skin for older adults — card-first, larger type, higher contrast — kept as a separate line item so it can be cut without touching the base build.
• Seed content + polish + mobile QA. About 12 acts seeded across all four layers, including one world event whose helpers read like people, not a number ("4,218 praying at noon" shown as faces and notes). The widget appears as a static framed mock. Final polish and a mobile pass across the target browsers.

Assumptions (Option A)

• The 16 designed .dc.html files, approved wireframes (w1–w16), the Phase 1 PDF as the copy source of truth, brand font TTFs, and the real photography are provided and usable as-is; most screens are adapted from them rather than authored fresh.
• Copy and imagery come from Acts Ventures; the prototype uses the Phase 1 PDF as the reference for wording.
• One consolidated feedback round is assumed. Large scope changes are re-estimated before proceeding, not absorbed silently.
• Light backgrounds only, no dark mode, no emoji, no login walls anywhere.
• Hosting is a static host with a single shareable link.

Exclusions (Option A)

• No backend, no database, no accounts, no stored data — every session is fresh on reload.
• No real payments (the Stripe test-mode buttons, if selected, run in test mode only and move no money).
• No real OS widget, no push notifications, no SMS delivery — the SMS thread is a simulated UI.
• Not the existing v1 React Native / Expo app; no RN work is included.
• Third-party running costs (hosting, map tiles if a live map is chosen) are billed at cost by those providers, separate from these hours.

Option B — Vercel + Supabase

The same front-end as Option A, deployed on Vercel with a Supabase backend, so the prototype behaves like a shared, living space. Acts, prayers, and comments persist; guest sessions let people act without an account; seeded content survives reloads and is the same for every viewer. This version doubles as the seed of the real build — the schema and components carry straight into Phase 2.

| Module | Hours (low – high) | |---|---| | Project setup + tokens/fonts + shell nav | 5 – 8 | | Feed (3 views incl. map) | 11 – 18 | | Act detail ×2 + share/invite | 6 – 10 | | Request flow ("I Need an Act") | 8 – 13 | | Completion ×4 (incl. live timer) | 9 – 15 | | Story card + instant act page | 7 – 12 | | Comments + report UI | 6 – 10 | | Donate pages (excl. Stripe test) | 3 – 5 | | Pastor broadcast + QR | 4 – 6 | | Skin A pass (older-adult skin) | 5 – 9 | | Seed content + polish + mobile QA (incl. widget mock) | 7 – 13 | | Supabase schema + wiring + deploy | 10 – 18 | | Total | 81 – 137 hrs | | *Optional line item: Stripe test-mode donate buttons* | *+3 – 5* |

Total range: 81 – 137 hrs (84 – 142 with the Stripe test-mode line item).

Timeline: roughly 2.5 – 4 weeks, running back-to-back after sign-off.

What differs from Option A

The per-screen hours are higher than Option A because each screen that reads or writes data is wired to the live backend rather than to in-memory mock data — the Feed reads real acts, the Request flow writes a new act, Completion persists the completed act and its story, and Comments store and flag against the database.

The final row — Supabase schema + wiring + deploy — is the backend foundation that Option A does not have:

• Schema: tables for acts, prayers, comments, and flags/reports, across all four layers (me / another / parish / world).
• Guest sessions: anonymous sessions so anyone can act without a login, with row-level security shaped around that.
• Data layer: a shared client and the read/write plumbing the screens call into.
• Seed migration: the ~12 demo acts loaded server-side so they are the same for every viewer and survive reloads.
• Deploy: Vercel + Supabase on their free tiers, with environment configuration.

Per-screen wiring is counted inside each module above; this row is the schema, guest-session auth, shared data layer, seed migration, and deploy that they all sit on.

Assumptions (Option B)

• Everything under Option A's assumptions, plus:
• Vercel and Supabase free tiers are the deployment target and are sufficient for a demo-scale prototype.
• Anonymous / guest sessions are acceptable in place of full accounts for the prototype; no email/password sign-up is built.
• Demo-scale data volumes (dozens of acts, not production traffic).

Exclusions (Option B)

• No full user accounts, profiles, or authenticated sign-up — guest sessions only.
• No real payments (Stripe test-mode line item, if selected, moves no money).
• No push notifications, no real SMS delivery, no real OS widget.
• No moderation backend beyond the mocked queue UI — the admin panel is a separate later phase.
• Not the existing v1 React Native / Expo app; no RN work is included.
• Third-party running costs (hosting, database, map tiles) are billed at cost by those providers, separate from these hours.

Which to choose

Option A is the fastest route to something real in front of people. It is a single link, nothing to keep running, and it resets clean every time — ideal for partner and investor meetings where the point is to feel the loop, not to store anything.

Option B costs more and takes longer, but the extra time is not throwaway: it doubles as the seed of the real build. The Supabase schema, the guest-session model, and the wired components carry directly into Phase 2, so a good part of Option B is work you would do anyway. If the prototype is mainly a demo, Option A is the lean choice. If it is a demo that should also give the real build a running start, Option B is the one that keeps paying off.

A reasonable path is to start with Option A for the nearest meetings and move to Option B when the build is greenlit — the front-end built in A transfers into B, so little is lost.

What's included — and what's not

• Hours cover design and engineering time. Third-party running costs — hosting, database, map tiles, and payment-processing fees if the Stripe test line item is chosen — are billed at cost by those providers, separate from these hours.
• Content — copy and imagery — is provided by Acts Ventures; the prototype follows the Phase 1 PDF for wording.
• One consolidated feedback round is assumed. Large scope changes are re-estimated before we proceed, never absorbed silently.
• Billed at the agreed hourly rate. Each option is a self-contained step; you approve one before it starts.

*Carry-forward note: Option B's Supabase schema and wired components are built to seed Phase 2. Choosing B is partly pre-paying for the real build, not spending twice.*