Discussion Deck

Weeve Repository Assessment

The current product setup has real promise, but it needs consolidation, backend hardening, and cost controls before consumer growth.

Core recommendation

Consolidate authenticated web and mobile into one member client, backed by a hardened API.

The formal write-up remains the evidence base; this deck is the walkthrough.

Current Product Space

The architecture has the right conceptual split, but too many product implementations.

Backend

API, auth, queues, extraction, images, data model.

Web app

Current mature member experience and UX reference.

Flutter app

Native behavior reference: share, push, storage, lifecycle.

Landing

Public marketing site; should remain separate.

The consolidation path is not being graded as finished here; it is positioned as the remedy for this split.

Findings

Seven issues matter most.

  • Current auth/session boundaries are not ready for a broader audience pilot.
  • Cookie, HTTPS, CSRF, and session-expiration behavior need a production security pass.
  • Scraping and debug endpoints need production boundary review.
  • Save-link extraction has real variable cost exposure.
  • Current web/mobile split increases product drift and delivery cost.
  • Test coverage is not yet strong enough around risky flows.
  • Developer onboarding still depends on scattered knowledge.

Security

The backend needs a sharper auth and production-boundary posture.

Auth/session target

  • Short-lived JWT access tokens
  • Rotating refresh tokens
  • Server-side session tracking
  • Reuse detection and revocation

Main risk

If long-lived credentials are JavaScript-readable, an XSS bug becomes an account takeover path. If debug extraction endpoints are exposed, they become cost and abuse paths.

Extraction Cost

Saving a link can trigger several paid or expensive operations.

1

Classify

OpenAI web-search classification.

2

Scrape

Firecrawl, Crawl4AI, Jina, custom paths.

3

Extract

OpenRouter structured extraction.

4

Summarize

OpenRouter summary fallback.

5

Process

Images, storage, retries.

This is fine for quality discovery. It needs tiering, logging, cache reuse, rate limits, and deterministic summaries before scale.

Data Model

Keep Summary and Description separate in the data model.

The UI can simplify presentation, but the backend should preserve provenance.

Description

Source-derived text from metadata, page content, or product copy.

Weeve Summary

Generated or post-processed user-facing interpretation.

Why it matters: search, debugging, regeneration, auditability, and future quality controls.

Developer Experience

A new engineer should not need oral tradition to contribute.

Current friction

  • Multiple stacks
  • Runtime drift
  • Historical names
  • Setup knowledge in memory
  • caddie gaps

Cleaner operating model

  • Standard setup around $HOME/work/weeve
  • caddie as workflow vocabulary
  • Repo READMEs that start from zero
  • AGENTS.md for agent work
  • Gaps tracked separately

Recommendation

The member app consolidation is the product-surface fix.

Keep

Landing separate

Marketing and SEO should stay outside the authenticated app.

Consolidate

Member experience

One web/native authenticated client reduces drift and delivery cost.

Harden

Backend platform

Auth, extraction, queue, cost, and observability need production posture.

Roadmap

Sequence the work around risk reduction, consolidation, then growth.

0-30 days

Stabilize

  • Auth/session design
  • Endpoint audit
  • Cost logging
  • Rate limits

30-60 days

Consolidate

  • Migrate workflows
  • Backend contracts
  • Device QA
  • Extraction observability

60-90 days

Prepare

  • Native capture
  • Push/deep links
  • Deterministic summary shadow mode
  • Operational dashboards

Operating Model

Use the current product to learn while the target platform is built.

The roadmap should not freeze customer learning. It should divide work so the offshore team, Wes's 10 hours per week, and Drew/Sebastian's product decisions compound instead of colliding.

Offshore team

  • Keep current production stable
  • Patch bugs and preserve learnings
  • Document existing flows as migration input
  • Build bounded Expo/RNW work packets

Wes, 10 hrs/week

  • Architecture decisions and reviews
  • Auth/security/cost control direction
  • PR quality bar and agent orchestration
  • Roadmap sequencing and risk calls

Drew + Sebastian

  • Define pilot success metrics
  • Prioritize workflows for parity
  • Choose what must remain unchanged
  • Own user feedback and product tradeoffs

Suggested goal: prepare a broader pilot of roughly 100 selected waitlist users after auth, save-link reliability, onboarding, and basic observability are ready.

Questions For Drew + Sebastian

The 100-user pilot should shape the next priorities.

Pilot definition

  • Which waitlist segment should get the first broader invite?
  • What does success mean: saves, retention, sharing, categories, or referrals?
  • What failure rate is acceptable for save-link extraction during pilot?
  • What support process is needed when a save fails or categorization is wrong?

Product priorities

  • Which current web workflows are must-have before consolidation launch?
  • Which Flutter behaviors are required for iOS-first pilot credibility?
  • How much should the pilot optimize for learning versus polish?
  • Which metrics need to be visible every week?

Close

The product is directionally strong. The next job is making it easier to trust.

Trust here means secure auth, controlled extraction cost, one product surface, observable backend behavior, and a developer path that does not require tribal knowledge.

Recommendation

Proceed with consolidation, but pair it with backend hardening and cost controls as first-class workstreams.

01