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.
Classify
OpenAI web-search classification.
Scrape
Firecrawl, Crawl4AI, Jina, custom paths.
Extract
OpenRouter structured extraction.
Summarize
OpenRouter summary fallback.
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.mdfor 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.