Strategy Comparison
Two credible approaches to the Proximity Green platform: the white paper's evolve & govern strategy vs a full AI-native rebuild. Both have merit. This page presents the honest trade-offs.
The Two Approaches
Strategy A: Evolve & Govern
Source: Proxity Green White Paper v1.0 (2025)
Core thesis: WSM is operationally mature. Don't rebuild — formalise what exists into a governed RAD platform.
- Keep MongoDB + JXP framework
- Add Model Registry (versioned, Git-governed)
- Add Governance Engine (r/w/x permissions, declarative validation)
- Add append-only event ledger for audit
- Add generic UI engine (model-driven list/form rendering)
- Add versioned config & typed settings
- 5 phases over ~6 months
- Small core team governs, larger delivery team extends
Strategy B: AI-Native Rebuild
Source: Code review & platform requirements analysis (2026)
Core thesis: The security and architectural issues run deep enough to warrant a clean start on a modern, AI-first stack.
- PostgreSQL + Drizzle ORM (ACID for financial data)
- Hono API on Cloudflare Workers (edge deployment)
- Clerk auth (OAuth 2.0 + SALTOK)
- Claude AI for member assistant, admin briefing, skill matching
- Inngest for typed event-driven workflows
- Single frontend framework (Next.js or SvelteKit)
- 6 phases over ~5 months (Claude Code accelerated)
- 1 senior dev + Claude Code
Honest Comparison
| Dimension | A: Evolve | B: Rebuild |
|---|---|---|
| Preserves domain logic Years of battle-tested business rules in Mongoose hooks |
Strong | Risk |
| Security posture JWT bypass, deprecated crypto, no validation, 88 exposed endpoints |
Partial | Clean slate |
| Financial data integrity ACID transactions for wallet/ledger (the most critical subsystem) |
MongoDB | PostgreSQL |
| AI capabilities Conversational UX, predictive analytics, community intelligence |
Bolt-on | Native |
| Delivery risk Probability of completing on time without breaking production |
Low risk | Medium risk |
| Time to value How quickly users see improvements |
Incremental | Big bang |
| Technical debt Node 8/16, eval() cron, 3 frontend frameworks, no tests |
Inherited | Clean |
| API contract Versioned, validated, documented, scoped third-party access |
Improved | OpenAPI 3.1 |
| Multi-tenant / platform play Ability to serve multiple operators on one codebase |
White paper focus | Possible |
| Team scalability How easily new developers can contribute safely |
Governed | Modern DX |
| Build cost | ~R500K–R800K | ~R814K |
| Timeline | ~6 months | ~5 months |
Where the White Paper Is Right
The white paper makes several arguments that are genuinely strong:
1. Domain maturity is real
WSM's Mongoose hooks encode years of hard-won business rules: ledger deduction priority, pro-rata calculations, booking conflict detection, Xero sync edge cases, invoice holiday logic. Rewriting this from scratch is not just expensive — it risks losing undocumented edge-case handling that only exists in the current code.
2. Incremental delivery is safer
The white paper's 5-phase plan delivers value at every stage. Phase 1 (registry) improves governance immediately. Phase 2 (permissions) closes security gaps. There's no risky "big bang" cutover where everything must work on day one.
3. Platform company ambition
The white paper's roadmap to Stage 4 ("Platform Company") with multi-tenant governance and a RAD framework is a bigger strategic vision than a single-product rebuild. If the goal is to sell the platform to other coworking operators, the evolve path may be faster to market.
4. Low-code tools can't match it
The white paper correctly identifies that Budibase, Appsmith, ToolJet etc. can't replicate the domain-specific logic in WSM. The custom rule engine, composite validation, and financial transaction pipeline are too specialised for generic tools.
Where the White Paper Has Gaps
1. Security is not addressed
The white paper does not mention the JWT verification bypass, deprecated crypto, path traversal, command injection, or the 88 unprotected API endpoints. The governance engine would add permissions, but the underlying auth is broken. Governance on top of broken auth is a locked door with no walls.
2. MongoDB for financial data
The ledger/wallet system is the most complex and most critical subsystem. MongoDB lacks ACID transactions across documents. A partial write during a multi-wallet deduction can corrupt balances. The white paper proposes an event ledger (good) but doesn't address the underlying database limitation.
3. No AI strategy
The white paper mentions "AI-ready data exports" as a Stage 4 item (12+ months). It does not propose AI as a core UX element. The member assistant, admin briefing, skill matching, and smart booking features — which are the biggest differentiators — are not part of the plan.
4. Technical debt stays
Node 8/16 Docker images, eval() in the cron scheduler, 3 frontend frameworks, PhantomJS for PDFs, no test suite — the evolve approach inherits all of this. The governance layer sits on top of these issues but doesn't resolve them.
5. Third-party API access
The platform requirements specify scoped third-party API access for wallet deductions (Req 7, 12). The white paper's permission model focuses on internal governance but doesn't address external API consumers with OAuth 2.0 client credentials and scoped tokens.
Strategy C: The Hybrid Path
Recommendation: Combine Both Strategies
The strongest path takes the white paper's incremental, domain-preserving approach and the rebuild's security, AI, and PostgreSQL for financial data. Neither strategy alone is optimal.
The hybrid approach works in three stages:
Stage 1: Secure & Stabilise WSM (Weeks 1–4)
Aligns with: White Paper Phase 1 + Sprint 1–2 fixes
Fix the critical security issues now while the existing platform is live. This is non-negotiable regardless of strategy.
- JWT verification, crypto migration, session hardening (from fixes page)
- Restrict sensitive API endpoints (apikey, config, schedule, tokens)
- Begin the white paper's Model Registry — version and publish model snapshots
- Begin the white paper's Settings Resolver — typed, audited config
Cost: ~R80K • Risk: Low • Value: Immediate security + governance foundation
Stage 2: Extract Financial Core to PostgreSQL (Weeks 5–12)
New: not in either original strategy
The ledger/wallet system is the one subsystem where MongoDB is a genuine liability. Extract it to PostgreSQL with ACID transactions while keeping everything else on MongoDB/JXP.
- Build the new wallet/ledger/invoice engine on PostgreSQL (Drizzle ORM) as a standalone service
- Implement the deduction priority API (Req 12: monthly → weekly → daily → evergreen)
- Third-party scoped API access via OAuth 2.0 client credentials
- WSM calls the new financial service via internal API (the rest of WSM stays on MongoDB)
- Migrate existing ledger/wallet data from MongoDB to PostgreSQL
- Add the white paper's Governance Engine (permissions, validation) to WSM in parallel
Cost: ~R200K • Risk: Medium (isolated to financial subsystem) • Value: ACID financial data + third-party API
Stage 3: AI Layer & Modern Frontend (Weeks 10–20)
Aligns with: Rebuild Phases 5–6 + White Paper Phase 4
Build the AI-powered frontend and community intelligence layer on top of the now-governed WSM backend and the new PostgreSQL financial service.
- AI assistant (Claude Haiku) consuming both the JXP API and the new financial API
- Smart booking, admin briefing, churn prediction, community skill matching
- Modern frontend (Next.js or SvelteKit) replacing the Handlebars templates
- iOS/iPad apps consuming the same APIs
- The white paper's Generic UI Engine for admin/back-office screens
- Skills taxonomy loaded from member data (774 users, 129 skills)
Cost: ~R300K • Risk: Low (additive, not replacing) • Value: AI differentiation + modern UX
Stage 4: Platform Maturity (Months 6–12)
Aligns with: White Paper Stages 3–4
Progressively migrate remaining MongoDB collections to PostgreSQL as the governance layer matures. Move toward the white paper's "Platform Company" vision with multi-tenant governance and the rebuild's full PostgreSQL backend.
- Migrate remaining models (bookings, members, CRM) to PostgreSQL on a collection-by-collection basis
- White paper's PDF reporting engine and standardised automation
- Multi-tenant governance for platform licensing
- AI-ready data model with clean export layer
- Eventually decommission MongoDB entirely
Cost: ~R200K • Risk: Low (incremental) • Value: Full platform maturity
Cost Comparison: All Three Strategies
| Dimension | A: Evolve | B: Rebuild | C: Hybrid |
|---|---|---|---|
| Build cost | ~R500K–R800K | ~R814K | ~R780K |
| Timeline to first value | 2–4 weeks | ~4 months | 1 week (security fixes) |
| Timeline to full maturity | ~6 months | ~5 months | ~6 months (AI at week 16, full at 12 months) |
| Security addressed | Partially (governance) | Fully (clean slate) | Fully (fixes + new financial service) |
| AI capabilities | Stage 4 (12+ months) | At launch (month 5) | Month 4–5 |
| Financial data integrity | MongoDB | PostgreSQL | PostgreSQL (financial only from month 3) |
| Domain logic preserved | 100% | ~90% (re-implemented) | 100% (evolve path) |
| Production risk | Low | Medium (big-bang cutover) | Low (incremental) |
| Platform company path | Strong (white paper focus) | Possible | Strong (best of both) |
| Audit logging (Req 13) | White paper Phase 3 | Built-in (PostgreSQL) | Stage 1 (governance) + Stage 2 (PostgreSQL) |
| PDF / Reporting (Req 14-15) | White paper Phase 5 | Phase 5 | Stage 3 (modern frontend) |
| Advanced UI (Req 16) | White paper Phase 4 | Phase 5 | Stage 3 (modern frontend) |
| Data validation (Req 17) | White paper Phase 2 | Phase 1 (Zod) | Stage 1 (governance + Zod) |
Summary
The white paper and the rebuild analysis both contain important truths:
| The white paper is right that WSM's domain logic is mature and valuable, that incremental delivery is safer, and that the platform company vision requires governance infrastructure. | The rebuild analysis is right that the security issues are critical, that MongoDB is wrong for financial transactions, that AI should be native not bolt-on, and that the technical debt is deep. |
The hybrid path respects both positions:
- Fix security immediately — non-negotiable, both strategies agree
- Keep the domain logic — don't rewrite the business rules that work
- Extract financial data to PostgreSQL — ACID where it matters most
- Build AI as a layer — consuming both the existing JXP API and the new financial service
- Migrate progressively — collection by collection, not big-bang
- End state is the same — full PostgreSQL, AI-native, governed platform
The difference is the journey: the hybrid path never puts production at risk, preserves every line of domain logic, and delivers AI capabilities almost as fast as the full rebuild.