Solanasis Docs

open-source-erp-research

54 min read

Open Source ERP Platform Research: Solanasis SaaS Strategy

Date: March 10, 2026 Purpose: Evaluate open source ERP platforms for forking into a custom SaaS offering Status: Initial Research — Pending Dmitri’s Input on Clarifying Questions

Table of Contents

  1. Executive Summary & Recommendation
  2. Platform Comparison Matrix
  3. Deep Dive: ERPNext (Frappe Framework)
  4. Deep Dive: Tryton
  5. Deep Dive: Odoo Community Edition
  6. Other Contenders Evaluated
  7. Licensing Analysis & SaaS Strategy
  8. Forking Strategy & Upgrade Path
  9. CRM & Sales Pipeline Assessment
  10. Hosting & Deployment Architecture
  11. E2E Testing Strategy
  12. Community Sentiment (Reddit, HN, Forums)
  13. AI Integration Strategy
  14. Risk Assessment
  15. Complete UI Reskinning & White-Labeling Strategy (CRITICAL)
  16. Clarifying Questions for Dmitri
  17. Verification Report: Fact-Check Results
  18. Dmitri’s Answers & Strategy Updates
  19. Self-Hosting Guide: Windows WSL2 + Docker + Cloudflare Tunnel
  20. Next Steps: Detailed Planning Documents Needed

Executive Summary & Recommendation

After extensive research across 7 open source ERP platforms — analyzing GitHub repos, licensing, community sentiment on Reddit/HN/forums, extensibility, CRM capabilities, and SaaS viability — here is the recommendation stack:

The Verdict: ERPNext (Frappe Framework) — With a Twist

Primary Recommendation: Fork ERPNext + Use Frappe CRM as the Sales Pipeline

  • Why ERPNext/Frappe wins for Solanasis:

    • GPL v3 license = SaaS loophole applies (no obligation to open-source modifications for SaaS-only deployment)
    • Frappe Framework is a genuine full-stack low-code platform (Python + Vue.js 3) — not just an ERP, but a platform for building ANY custom business application
    • 171+ apps in the ecosystem prove the framework’s extensibility beyond ERP
    • Frappe CRM (separate from ERPNext’s CRM module) is a modern, sales-focused CRM with email sync, WhatsApp, and Twilio integrations built-in
    • Custom app architecture keeps your code separate from core = clean upgrade path
    • Docker-ready, multi-tenant, production-proven at scale
    • Active community: 32k+ GitHub stars (ERPNext), 9.7k+ (Frappe Framework), 22k+ forum users, 600+ contributors on v16
    • v16 released January 2026 with 2x performance improvements
    • Cypress E2E testing framework already in place

  • Why NOT Tryton: Smaller community (~168 GitHub stars on mirror), weaker CRM, no native multi-tenancy for SaaS, Mercurial-based workflow (not Git-native), less white-labeling support, limited cold email capabilities

  • Why NOT Odoo CE: While Odoo CE has a massive community (48k+ stars) and LGPL license, the Community vs Enterprise gap is significant — missing Studio (low-code builder), automated workflows, advanced CRM features. You’d be building on an intentionally limited version.

  • Why NOT Apache OFBiz: Apache 2.0 license is most permissive, but tiny community, steep Java learning curve, and limited modern CRM capabilities make it impractical for a small team.

The Strategic Play

  1. Fork ERPNext as the ERP backbone for client deployments
  2. Use Frappe CRM (or build a custom CRM on Frappe Framework) for Solanasis’s own sales pipeline
  3. Build all custom modules as Frappe custom apps (never modify core)
  4. Layer in white-labeling and multi-tenancy for the SaaS offering
  5. Maintain E2E test suite to protect against regressions on upstream merges

Platform Comparison Matrix

CriteriaERPNext (Frappe)TrytonOdoo CEAxelorApache OFBizDolibarriDempiere
LicenseGPL v3GPL v3LGPL v3AGPL v3Apache 2.0GPL v3+GPL v2+
SaaS Loophole✅ Yes✅ Yes✅ Yes (LGPL)❌ No (AGPL)✅ Yes (Apache)✅ Yes✅ Yes
GitHub Stars~32k~168 (archived mirror)48.5k927~1k6.7k~431
Tech StackPython/JS/VuePython/GTK/JSPython/JSJava/SpringJavaPHPJava
Framework Extensibility⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
CRM Quality⭐⭐⭐⭐ (w/ Frappe CRM)⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Cold Email/Outreach⭐⭐⭐ (needs work)⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Multi-Tenancy✅ Built-in❌ Custom work✅ Built-in✅ Yes✅ Built-in✅ Yes✅ Yes
Docker Ready✅ Official✅ Official✅ Official✅ Yes✅ Yes✅ Official✅ Yes
White-Labeling⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Documentation⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Community Size⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
E2E Testing✅ Cypress⚠️ Limited⚠️ Varies⚠️ Varies⚠️ Varies⚠️ Varies⚠️ Varies
Upgrade Safety⭐⭐⭐⭐ (custom apps)⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

Deep Dive: ERPNext (Frappe Framework)

Architecture Overview

ERPNext is built on the Frappe Framework — a full-stack, metadata-driven web framework that serves as a low-code application platform:

  • Backend: Python (server-side logic, API, business rules)
  • Frontend: JavaScript + Vue.js 3 (Frappe UI component library with Tailwind CSS)
  • Database: MariaDB 10.6.6+ (required for ERPNext production — PostgreSQL is supported at the Frappe Framework level only, NOT for ERPNext production deployments)
  • Caching & Queuing: Redis
  • Real-time: WebSockets via Socket.IO
  • Templating: Jinja2

The DocType System (Core Extensibility)

This is where Frappe really shines as a development platform. A DocType defines both the Model (data structure) and View (UI) of your data:

  • Every object in ERPNext/Frappe is a DocType with predefined fields, permissions, and relationships
  • Custom DocTypes can be created with minimal or no coding
  • DocTypes are saved as JSON files = version controllable
  • Every DocType automatically gets REST API endpoints
  • Custom controllers (Python) and client scripts (JavaScript) can be attached
  • DocType inheritance allows extending existing types

Frappe Ecosystem (171+ Apps)

Key apps beyond ERPNext:

  • Frappe CRM — Modern standalone CRM (launched 2023, separate from ERPNext’s CRM)
  • Frappe HR — Full HRMS
  • Frappe Desk — Ticketing/support system
  • Frappe Insights — Data analytics tool
  • Frappe LMS — Learning Management System
  • 35+ developer tools available in the ecosystem

Frappe CRM vs ERPNext CRM (Critical Distinction)

AspectFrappe CRMERPNext CRM Module
FocusStandalone, sales-focusedPart of full ERP system
Data ModelLeads & Deals (simple pipeline)Leads → Opportunities → Quotations → Orders
IntegrationsWhatsApp, Twilio, Exotel, Email sync built-inMust be custom-built
Use CaseSales teams needing pipeline managementCompanies needing ERP + CRM together
Cold EmailBetter email sync + multi-channelBasic email campaigns, buggy at scale
UIClean, modern, purpose-builtGeneral ERP interface

Pro Tip: Frappe CRM is the better starting point for Solanasis’s own sales pipeline needs. ERPNext’s CRM module has known bugs with email campaigns — notably, if ANY one Email Group member unsubscribes, the entire Email Campaign gets unsubscribed for all recipients (GitHub Issue #52448, Feb 2026). However, note that Frappe CRM is licensed under AGPL v3 (not GPL v3), which has implications for your SaaS strategy — see Licensing section for details. You can run both Frappe CRM + ERPNext on the same Frappe instance.

GitHub & Version Status

  • ERPNext: ~32,152 stars, ~10,611 forks, 600+ contributors on v16 release
  • Frappe Framework: ~9,780 stars, ~4,718 forks, active development
  • Latest: v16 (January 2026) — 2x performance improvements, redesigned workspace, modern UI
  • EOL for v16: End of 2029

Customization & White-Labeling

  • White-label module available (ERPNext Whitelabel) — single settings page for branding
  • Custom logos, favicons, splash images, themes
  • Custom apps architecture keeps modifications completely separate from core
  • Hooks system (hooks.py) lets you intercept and extend any core behavior without modifying source

Resource Requirements

  • Database Server: Minimum 8GB RAM (rule of thumb: RAM = total DB size), 2+ vCPU
  • Application Server: ~400MB memory minimum per bench, gunicorn workers = 2 × num_cores + 1
  • Recommended: Vertical scaling up to ~64 vCPU / 128GB RAM before horizontal scaling

Deep Dive: Tryton

Why Tryton Falls Short for Solanasis

While Tryton is a solid, stable ERP with 15+ years of development history, several factors make it a weaker choice:

  1. Tiny Community: ~168 GitHub stars (mirror) vs ERPNext’s 10.6k — this matters enormously for community support, third-party modules, and finding developers
  2. No Native Multi-Tenancy: Built-in multi-company support but NOT true SaaS multi-tenant architecture — requires significant custom work
  3. Mercurial-Based Workflow: Primary development on Heptapod using Mercurial, not Git — adds friction for a team that wants to fork and manage via Git/GitHub
  4. Basic CRM: Sale opportunity module exists with limited pipeline visualization. Kanban views ARE available (correction from earlier draft), but the CRM still lacks cold email capabilities and has notification-focused email only
  5. Limited White-Labeling: Requires custom CSS/theme work — no out-of-the-box white-label solution
  6. GTK Desktop Client: The desktop client uses GTK+ (old school) — web client (Sao) uses jQuery/Bootstrap, which feels dated vs Frappe’s Vue.js 3
  7. Performance at Scale: Documented issues with large databases — problematic tables (stock_move, account_move) reaching tens of GBs cause query slowdowns
  8. Documentation Gaps: Community acknowledges missing user workflows and scattered documentation

Where Tryton Beats ERPNext

To be fair:

  • More stable/predictable release cycle
  • Stronger accounting foundation
  • Better multi-company support within a single instance
  • Less “bloat” — smaller, more focused codebase
  • Python-only stack (no JavaScript framework to learn for backend)

Verdict on Tryton

Tryton would be suitable for a company that needs rock-solid accounting in a traditional ERP with no SaaS multi-tenancy needs. For Solanasis’s goals of building a customizable SaaS with strong CRM/pipeline management and cold outreach — Tryton falls short on too many fronts.

Deep Dive: Odoo Community Edition

Why Odoo CE Is the Runner-Up

Odoo has the largest open source ERP community on the planet (48.3k GitHub stars, 31k forks) and the Odoo Community Association (OCA) maintains thousands of high-quality modules. However:

The Community vs Enterprise Problem

This is the critical issue for Solanasis. Odoo SA intentionally limits Community Edition to drive Enterprise sales:

Missing from Community Edition:

  • Odoo Studio (low-code/no-code builder) — this is huge for rapid customization
  • Automated workflows/actions — must be built manually
  • Advanced inventory (barcode scanning, shipping integrations)
  • Official mobile apps
  • Vendor support, hosting assistance, version upgrade help
  • Advanced CRM features (AI lead scoring in Enterprise only)

What You Get in Community:

  • Core modules: CRM, Sales, Accounting, Inventory, Manufacturing, HR
  • LGPL v3 license — most SaaS-friendly of the copyleft licenses
  • Massive OCA module ecosystem
  • Excellent documentation
  • Largest pool of developers familiar with the platform

LGPL v3 License Advantage

LGPL is more permissive than GPL for SaaS:

  • You can create proprietary modules that link to the LGPL-covered library
  • Your custom modules DON’T need to be open-sourced
  • Modifications to the LGPL-covered core itself must stay LGPL
  • Cleaner legal boundary than relying on the GPL “SaaS loophole”

Why ERPNext Still Wins Over Odoo CE for Solanasis

  1. No intentional feature gating — ERPNext doesn’t hold back features for an enterprise tier
  2. Frappe Framework is a better dev platform — DocTypes, custom apps, hooks system are more developer-friendly for rapid custom development
  3. Frappe CRM — purpose-built modern CRM vs Odoo’s CE CRM which lacks Enterprise features
  4. Smaller learning surface — Odoo’s codebase is massive; Frappe is more focused
  5. Community ethos — ERPNext community is focused on the open source product; Odoo community always plays second fiddle to Enterprise

Other Contenders Evaluated

Axelor Open Suite — ELIMINATED

  • License: AGPL v3 — DEAL BREAKER
  • AGPL requires source code disclosure when modified software is accessed over a network (SaaS)
  • You would be forced to open-source all your customizations
  • Eliminates competitive advantage for a SaaS business model

Apache OFBiz — Not Practical

  • License: Apache 2.0 — most permissive, ideal for SaaS legally
  • But: Steep Java learning curve, small community, complex codebase, outdated UI
  • Would require strong Java development team and significant investment
  • Not practical for a small team trying to move fast

Dolibarr — Too Basic

  • License: GPL v3+
  • PHP-based, lightweight, good for very small businesses
  • CRM is basic (no Kanban, no lead scoring, no email tracking)
  • Performance degrades with data volume growth
  • Documentation is weak and partially French-only
  • Better suited as a simple invoicing/accounting tool, not a SaaS platform

iDempiere — Too Niche

  • License: GPL v2+
  • Java-based, 410 GitHub stars, steep learning curve
  • OSGI plugin system is powerful but complex
  • Documentation gaps acknowledged at their own 2025 conference
  • Multi-tenant capable but requires significant expertise

Licensing Analysis & SaaS Strategy

The GPL v3 “SaaS Loophole” — How It Works

This is the legal foundation of Solanasis’s SaaS strategy with ERPNext:

  1. GPL v3 obligations trigger on “distribution” — i.e., giving someone a copy of the software
  2. SaaS is NOT distribution — GPL v3 Section 0 (Definitions) explicitly states: “mere interaction with a user through a computer network, with no transfer of a copy, is not conveying”
  3. Therefore: Running a forked, customized ERPNext as SaaS does NOT require open-sourcing your modifications
  4. This is NOT the case with AGPL v3 — AGPL Section 13 closes this loophole by requiring source disclosure for network-accessible modified software

ERPNext Specific Licensing Status (March 2026)

  • ERPNext Code: GPL-3.0-only
  • Frappe Framework: GPL-3.0
  • ERPNext Documentation: CC-BY-SA-3.0
  • Newer Frappe Apps (post-April 2024): Released under AGPL v3 (e.g., Frappe Builder)
  • ERPNext itself: Remains GPL v3 — no change to AGPL

What You CAN Do

  • ✅ Fork ERPNext and Frappe Framework
  • ✅ Customize extensively
  • ✅ Deploy as SaaS and charge customers
  • ✅ Keep all your modifications private/proprietary
  • ✅ Create custom Frappe apps without licensing fees
  • ✅ White-label and rebrand completely

What You MUST Do

  • ✅ Maintain GPL v3 license notice in the codebase
  • ✅ Track changes with dates in source files
  • ✅ If you ever DISTRIBUTE the code, it must be under GPL v3
  • ✅ NOT use “ERPNext” in your domain name or product name (trademark restriction)

What You CANNOT Do

  • ❌ Use the “ERPNext” name/trademark for your SaaS product
  • ❌ Distribute your modified fork without including GPL v3 source
  • ❌ Mix in AGPL v3 code (like newer Frappe apps such as Frappe Builder, and notably Frappe CRM is also AGPL v3) without accepting AGPL obligations — if you incorporate AGPL code, the AGPL network-disclosure requirements apply to the combined work, which would CLOSE the SaaS loophole for those components
  • ❌ Sublicense — your fork stays GPL v3 forever (unless you are the sole copyright holder with no external contributions, which is effectively impossible once contractors contribute)

CRITICAL WARNING: Frappe CRM is AGPL v3. This means if you use Frappe CRM as-is in your SaaS, you’d need to provide source access to users interacting with it over the network. Options: (1) Build your own CRM module on the GPL v3 Frappe Framework instead, (2) Accept AGPL obligations for the CRM component, or (3) Use Frappe CRM internally only (not as part of the client SaaS offering). Get legal counsel on this specific point.

Orange v. Entr’Ouvert (2024, Paris): Orange was ordered to pay €860,000 (€500k damages + €150k profits + €150k moral damages + €60k legal costs) for GPL v2 violation — using GPL-licensed Lasso software (57% of their Identity Management Platform) without providing source code when distributing. Case took 12 years to resolve (2010-2024). Key takeaway: GPL violations are enforceable in court with serious financial consequences. As long as you don’t distribute, SaaS deployment is safe. But document your compliance strategy.

Pro Tips for Licensing Safety

  1. Get a brief legal review before launch — a few hours of IP attorney time is cheap insurance
  2. Never distribute your fork — SaaS-only deployment keeps you safe
  3. Document everything — keep a CHANGES file, track what’s modified vs upstream
  4. Consider CLAs (Contributor License Agreements) or DCOs (Developer Certificate of Origin) from any contractors contributing to your fork — CLAs are NOT legally required for GPL v3 but provide copyright clarity; DCOs are a lighter-weight alternative that reduces friction
  5. Watch for AGPL creep — Frappe is shifting newer apps to AGPL; be careful what you pull in. GPL v3 and AGPL v3 are compatible, but the AGPL’s network-disclosure requirements apply to the combined work
  6. JavaScript distribution risk — Serving GPL-licensed JavaScript to users’ browsers IS considered distribution, which triggers GPL source code obligations. Keep your proprietary frontend code separate from GPL frontend code. If you customize ERPNext’s JS and serve it via browser, you must provide source access
  7. Name your SaaS something completely different — no “ERPNext” or “Frappe” in the product name

Forking Strategy & Upgrade Path

solanasis-platform/
├── frappe/                    # Upstream Frappe Framework (submodule or fork)
├── erpnext/                   # Upstream ERPNext (submodule or fork)
├── frappe-crm/                # Upstream Frappe CRM (submodule or fork)
├── solanasis_core/            # YOUR custom Frappe app — core customizations
├── solanasis_crm_extensions/  # YOUR custom CRM extensions
├── solanasis_saas/            # YOUR multi-tenancy & SaaS management layer
├── solanasis_whitelabel/      # YOUR branding/theming
├── solanasis_integrations/    # YOUR third-party integrations
├── solanasis_e2e_tests/       # YOUR E2E test suite
└── docker/                    # YOUR deployment configs

The Golden Rule: NEVER Modify Core

All Solanasis customizations should live in separate Frappe custom apps. This is critical because:

  1. Clean upgrades: When ERPNext releases v17, v18, etc., you pull the new version without merge conflicts
  2. Clear IP boundary: Your proprietary code is physically separated from GPL code
  3. Easier testing: You test your apps independently from core
  4. Developer clarity: New team members know exactly where Solanasis code lives

Git Strategy for Upstream Sync

# Initial setup
git remote add upstream-erpnext https://github.com/frappe/erpnext.git
git remote add upstream-frappe https://github.com/frappe/frappe.git
 
# Before each major version upgrade
git fetch upstream-erpnext
git checkout -b upgrade/v17 main
git merge upstream-erpnext/version-17  # or rebase if you prefer linear history
 
# Test thoroughly in staging
# Run full E2E test suite
# Fix any breaking changes in your custom apps
# Merge to main only after all tests pass

Upgrade Workflow

  1. Staging Environment: Always upgrade in staging first, never production
  2. Run E2E Tests: Full test suite against upgraded staging
  3. Check Custom Apps: Verify all hooks, DocType extensions, and API customizations
  4. Database Migration: Frappe includes migration scripts — run bench migrate
  5. Regression Testing: Manual QA on critical workflows
  6. Blue-Green Deploy: Switch production traffic only after verification

Pro Tip: Upgrade Insurance

Keep a “compatibility test matrix” that maps your custom DocTypes, hooks, and API endpoints to the upstream code they depend on. When upstream releases a new version, diff their changelogs against your matrix to quickly identify breaking changes.

CRM & Sales Pipeline Assessment

Solanasis’s Cold Outreach Needs

Based on the requirement to manage a massive sales pipeline with cold emails and outreach, here’s the honest assessment:

What ERPNext/Frappe CAN Handle

  • Lead capture from websites, social media, events
  • Opportunity tracking through pipeline stages
  • Kanban board visualization (Frappe CRM)
  • Email sync and communication logging
  • WhatsApp and Twilio integration (Frappe CRM)
  • Activity management, follow-ups, scheduling
  • Contact and customer profiles
  • Basic email campaigns (small batches)
  • Pipeline analytics and reporting

What ERPNext/Frappe CANNOT Handle Natively

  • Mass cold email at scale (deliverability optimization, warming, rotation)
  • A/B testing of email campaigns
  • Advanced open/click tracking at scale
  • Email sequence automation (multi-step drip campaigns)
  • Deliverability monitoring and domain health
  • Automatic bounce/complaint handling at scale

For Solanasis’s cold outreach needs, the recommendation is a hybrid approach:

  1. Frappe CRM = Lead/deal management, pipeline, and relationship tracking
  2. Dedicated cold email tool (integrated via API/webhook) = Mass outreach execution
    • Options: Instantly.ai, Smartlead, Lemlist, or self-hosted alternatives
    • These tools handle deliverability, warming, rotation, sequences
  3. n8n or Zapier = Workflow automation between Frappe CRM and cold email tool
  4. Custom Frappe app = Build the integration layer as a Solanasis custom module

This gives you the best of both worlds — professional-grade cold email infrastructure + full CRM pipeline management in your own platform.

Long-Term Play

As Solanasis matures, you could build a native cold email module as a Frappe custom app, incorporating:

  • SMTP rotation and domain warming
  • Email sequence builder
  • Deliverability dashboard
  • Integration with DNS (SPF, DKIM, DMARC verification)
  • Compliance tools (CAN-SPAM, GDPR unsubscribe management)

This becomes a competitive differentiator for your SaaS offering to clients.

Hosting & Deployment Architecture

┌─────────────────────────────────────────────────┐
│                  Load Balancer                    │
│            (ALB on AWS / App Gateway on Azure)    │
└──────────────────────┬──────────────────────────┘
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
┌──────────────┐┌──────────────┐┌──────────────┐
│  App Server  ││  App Server  ││  App Server   │
│  (Frappe +   ││  (Frappe +   ││  (Frappe +    │
│   Gunicorn)  ││   Gunicorn)  ││   Gunicorn)   │
└──────┬───────┘└──────┬───────┘└──────┬────────┘
       │               │               │
       └───────────────┼───────────────┘
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
┌──────────────┐┌──────────────┐┌──────────────┐
│   MariaDB    ││    Redis     ││  Redis       │
│  (RDS/Azure  ││   (Cache)    ││  (Queue)     │
│   Database)  ││(ElastiCache/ ││              │
│              ││  Azure Cache)││              │
└──────────────┘└──────────────┘└──────────────┘

AWS Deployment Option

  • Compute: ECS Fargate (serverless containers) or EC2 with Docker
  • Database: Amazon RDS for MariaDB (managed, automated backups)
  • Cache: Amazon ElastiCache for Redis
  • Storage: S3 for file uploads and backups
  • Load Balancer: Application Load Balancer (ALB)
  • DNS: Route 53
  • SSL: AWS Certificate Manager (free TLS certificates)
  • Monitoring: CloudWatch + custom Frappe metrics

Azure Deployment Option

  • Compute: Azure Container Instances or Azure App Service with Docker
  • Database: Azure Database for MariaDB (managed)
  • Cache: Azure Managed Redis (note: Azure Cache for Redis is being retired Sept 2028 — use Azure Managed Redis for new deployments)
  • Storage: Azure Blob Storage
  • Load Balancer: Azure Application Gateway
  • DNS: Azure DNS
  • SSL: Azure-managed certificates
  • Monitoring: Azure Monitor + Application Insights

Multi-Tenancy Strategy

Frappe supports both DNS-based and port-based multi-tenancy with multiple sites per bench. DNS-based (bench config dns_multitenant on) is the standard production approach where sites are accessed by domain name:

  • Option A: Database-per-tenant — each client gets their own database, same application server. Better isolation, slightly more resource overhead.
  • Option B: Shared database with site separation — Frappe’s native approach. Multiple sites share infrastructure but have logical separation. More efficient, less isolation.
  • Recommendation for SaaS: Start with Option A (database-per-tenant) for stronger data isolation — critical for selling to SMBs and nonprofits who care about data privacy.

Estimated Monthly Costs (Starting Point)

AWS (Solanasis internal + first few clients):

  • t3.large EC2 (2 vCPU, 8GB RAM): ~0.0832/hr on-demand us-east-1)
  • RDS MariaDB db.t3.medium: ~80.30/mo — original estimate was too low)
  • ElastiCache t3.small: ~24.82/mo)
  • S3 storage: ~$5/month
  • ALB: ~16.43 + data processing)
  • Total: ~$195-210/month to start (on-demand pricing; Reserved Instances could save 30-40%)

Scales to: ~$500-800/month for 10-20 client tenants on moderately sized instances

Pro Tip: Use Credits Wisely

Since you have AWS/Azure credits, start with slightly larger instances than minimum to avoid performance headaches during the customization/development phase. Downsize once you’ve optimized.

E2E Testing Strategy

Current State in ERPNext/Frappe

  • E2E Framework: Cypress (official repo: frappe/erpnext_ui_tests)
  • Unit Testing: Python unittest (FrappeTestCase)
  • CI/CD: Tests run daily on GitHub Actions via cron
  • Test Runner: bench run-tests with targeting by app/doctype/module
solanasis_e2e_tests/
├── cypress/
│   ├── integration/
│   │   ├── core_erp/           # Smoke tests for core ERPNext features
│   │   ├── frappe_crm/         # CRM pipeline workflow tests
│   │   ├── solanasis_custom/   # Your custom module tests
│   │   ├── saas_management/    # Tenant provisioning, billing tests
│   │   └── whitelabel/         # Branding/theming validation
│   ├── fixtures/               # Test data
│   └── support/                # Helper functions, commands
├── unit_tests/
│   ├── test_solanasis_core.py
│   ├── test_crm_extensions.py
│   └── test_integrations.py
└── ci/
    ├── github-actions.yml      # CI pipeline config
    └── staging-deploy.yml      # Staging environment setup

Testing Workflow

  1. On every PR: Unit tests + critical path E2E tests (< 10 min)
  2. Nightly: Full E2E suite against staging (30-60 min)
  3. Before release: Full E2E + manual QA + performance testing
  4. On upstream merge: Full E2E + regression suite against upgraded codebase

Critical Test Categories

  1. Upgrade Compatibility Tests — Run after every upstream merge to catch breaking changes
  2. Multi-Tenancy Tests — Verify tenant isolation, data separation, provisioning
  3. CRM Pipeline Tests — Lead capture → qualification → opportunity → closed/won
  4. Custom Module Tests — Every custom DocType, hook, and API endpoint
  5. White-Label Tests — Verify branding appears correctly per tenant
  6. Integration Tests — Cold email tool sync, webhook delivery, API auth

Pro Tip: The Upgrade Safety Net

Create a “golden path” E2E test that exercises every critical workflow in your SaaS. Run this against EVERY upstream version bump BEFORE merging. This is your single most important test — if it passes, your upgrade is likely safe. If it fails, you know exactly which workflow broke.

Community Sentiment

ERPNext — Reddit/Forum/HN Consensus

What people love:

  • Truly 100% open source (no hidden enterprise edition)
  • Unlimited users for self-hosted deployments
  • Clean, intuitive UI once past initial setup
  • Comprehensive feature set out of the box
  • Strong customization when done via custom apps

What people complain about:

  • Steep learning curve for initial setup and new modules (verified: G2 reviews confirm this widely)
  • Documentation has significant gaps (verified: widespread complaint, though exact percentages are unverifiable)
  • Customer support is slow/inconsistent (verified: G2 reviews confirm slow response times)
  • Integration with external tools requires additional work (verified: common complaint on forums)
  • Heavy customization makes upgrades unstable (verified: best practice is to keep customizations in separate apps)
  • Duplication of business logic between Python and JavaScript
  • v16 has critical bugs: link field generates broken navigation URLs (Issue #52864), scheduler NULL trap + timezone mismatch breaks background jobs (Frappe Issue #37490)
  • v16 reception is mixed/negative — users report: “new UI is poor,” difficulty finding features, breaking changes from v15, container deployment issues

Red flags to watch:

  • Support quality is lower than competitors
  • If you customize heavily, plan your upgrade strategy carefully
  • Don’t rely on Frappe/ERPNext community for fast bug fixes — be prepared to fix issues yourself

Tryton — Reddit/Forum Consensus

What people love:

  • Stable, rarely significant downtime
  • Good community support (responsive)
  • Strong security features
  • Scalable architecture by design

What people complain about:

  • Documentation is “scarce” and “not good for beginners”
  • Learning curve is steep, especially for advanced functionality
  • Performance issues with searching and large datasets
  • Not beginner-friendly
  • Limited ecosystem compared to competitors

Key Insight from Community

The most common advice on Reddit for anyone building a SaaS on open source ERP: “Keep your customizations in separate modules/apps and never touch the core. The moment you modify core files, you’re in upgrade hell.” This aligns perfectly with the Frappe custom app approach.

AI Integration Strategy

The Vision: AI-Powered ERP/CRM as a Differentiator

This is where Solanasis can create massive differentiation. Most open source ERPs have zero or minimal AI integration. Building an “AI sidekick” into your forked platform — powered by Claude or similar models — would put you leagues ahead of competitors in the SMB/nonprofit space.

How Frappe Framework Supports AI Integration

Frappe’s architecture is well-suited for AI integration because:

  1. REST API everywhere — Every DocType has API endpoints, making it trivial for an AI agent to read/write data
  2. Webhook system — Trigger AI workflows on any document event (create, update, submit)
  3. Server Scripts (Python) — You can call AI APIs directly from backend logic
  4. Custom API endpoints — Build dedicated AI endpoints as part of your custom Frappe app
  5. Background jobs (Redis Queue) — Long-running AI tasks won’t block the UI
  6. Socket.IO real-time — Stream AI responses back to the UI in real-time

AI Integration Architecture

┌──────────────────────────────────┐
│       Solanasis Platform UI       │
│   (Frappe + Custom Vue.js)        │
│                                   │
│  ┌─────────────────────────────┐ │
│  │    AI Sidekick Chat Panel    │ │
│  │    (embedded in every view)  │ │
│  └──────────┬──────────────────┘ │
└─────────────┼────────────────────┘
              │ WebSocket / REST
              ▼
┌──────────────────────────────────┐
│    solanasis_ai (Custom App)      │
│                                   │
│  ├── AI Router (picks model/task) │
│  ├── Context Builder (gathers     │
│  │   relevant DocType data)       │
│  ├── Prompt Templates (per task)  │
│  ├── Tool Definitions (for        │
│  │   agent tool use)              │
│  └── Response Handler (actions    │
│      back to Frappe DocTypes)     │
└──────────────┬───────────────────┘
               │ API Calls
               ▼
┌──────────────────────────────────┐
│     AI Provider Layer             │
│                                   │
│  ├── Claude API (Anthropic)       │
│  ├── OpenAI API (fallback)        │
│  └── Local models (future, for    │
│      cost-sensitive tasks)        │
└──────────────────────────────────┘

Concrete AI Use Cases for the Platform

For Solanasis Internal Use (Sales Pipeline):

  1. AI Lead Scoring — Analyze lead data, website behavior, email engagement to auto-score leads
  2. Email Draft Generation — Claude-powered cold email drafting personalized to each lead’s industry/role
  3. Meeting Prep Briefs — Auto-generate briefing docs before sales calls by pulling CRM data + web research
  4. Pipeline Insights — “Which deals are at risk?” “What should I follow up on today?”
  5. Data Entry Assistant — Natural language to CRM entries (“Log a call with John at Acme, they’re interested in security assessment”)

For Client-Facing SaaS Product:

  1. AI Operations Assistant — Embedded chat that can answer questions about their data (“What were our top expenses last quarter?“)
  2. Document Generation — AI-powered proposals, reports, SOWs generated from CRM/project data
  3. Anomaly Detection — Flag unusual patterns in accounting, inventory, or operations
  4. Workflow Suggestions — “Based on your data, here’s how to optimize your approval process”
  5. Natural Language Querying — Clients ask questions in plain English, AI translates to Frappe queries
  6. Smart Automation Builder — AI helps clients create workflow automations without coding

Using Claude Code / AI Coding Agents for Development

For building and maintaining the platform itself:

  1. Claude Code as Development Partner — Use Claude Code to write custom Frappe apps, DocTypes, hooks, and test suites
  2. Automated Code Review — AI reviews PRs against Frappe best practices
  3. Test Generation — AI generates E2E and unit tests from DocType definitions
  4. Documentation Generation — Auto-generate API docs and user guides from code
  5. Migration Scripts — AI-assisted data migration script writing for new client onboarding

For SOP-Driven Contractor Workflow:

Since you’re building SOPs for 1099 contractors, AI coding agents can:

  • Auto-generate boilerplate code from SOP templates
  • Validate contractor code submissions against standards
  • Provide real-time guidance while contractors work
  • Run automated QA checks before code review

Technical Implementation Plan

Phase 1 (Month 1-2): Foundation

  • Build solanasis_ai custom Frappe app
  • Implement Claude API integration with API key management
  • Create basic chat interface embedded in Frappe UI
  • Build context builder that pulls relevant DocType data for prompts
  • Start with 2-3 use cases: email drafting, lead scoring, data entry assistant

Phase 2 (Month 3-4): Agent Capabilities

  • Implement tool use / function calling so AI can take actions in the system
  • Build tool definitions for common CRM operations (create lead, update deal, log activity)
  • Add prompt templates for each use case
  • Implement conversation history and context management

Phase 3 (Month 5-6): Client-Facing AI

  • Package AI features for the SaaS offering
  • Per-tenant AI configuration (usage limits, feature toggles)
  • Build the natural language query engine for client data
  • Add document generation capabilities
  • Implement usage metering for AI features (cost management)

Cost Considerations

  • Claude API (Sonnet 4.6): ~15/M output tokens — very cost-effective for business queries
  • Per-tenant cost: Estimate $5-20/month in AI API costs per active tenant
  • Pricing strategy: Bundle AI as a premium feature or include with usage caps

Pro Tip: AI as Your Wedge Differentiator

Most SMBs and nonprofits have never experienced AI integrated into their operational tools. An AI sidekick that can answer questions about their own data, draft emails, generate reports, and suggest optimizations is a massive “wow factor” that justifies premium pricing and reduces churn. This is exactly the kind of thing that makes Solanasis’s Responsible AI Implementation offering tangible rather than abstract.

Complete UI Reskinning & White-Labeling Strategy (CRITICAL)

THIS IS A TOP PRIORITY REQUIREMENT. Solanasis must be able to completely reskin the entire application to look like a modern, purpose-built SaaS product — NOT like ERPNext. The end product must appear to clients as if it’s Solanasis’s own proprietary ERP system. This is essential for reselling to clients and establishing the brand as a legitimate SaaS provider.

Why This Is Non-Negotiable

  1. Brand credibility — SMBs and nonprofits won’t pay premium prices for something that looks like a free open source tool with a logo swap
  2. Competitive positioning — You’re competing against polished SaaS products (HubSpot, Monday, Salesforce); the UI must match that quality bar
  3. Reseller model — If clients can Google “ERPNext” and find the free version, your value proposition collapses. The product must look and feel completely different
  4. Per-client white-labeling — Long-term, each client or reseller partner may want their own branding on the platform

Frappe’s Reskinning Capabilities — Honest Assessment

What Frappe gives you out of the box:

CapabilityBuilt-in?How?
Logo/favicon swap✅ YesERPNext Whitelabel module (single settings page)
Color theme changes✅ YesCSS variables + Tailwind classes
Hide “Powered by ERPNext”✅ YesWhitelabel module setting
Custom splash screen✅ YesWhitelabel module setting
Custom navbar title✅ YesWhitelabel module setting
Custom CSS injection✅ YesWhitelabel module + custom app hooks
Custom login page⚠️ PartialRequires custom Jinja2 template override
Completely different layout❌ NoRequires custom Vue.js components
Redesigned navigation❌ NoRequires overriding Frappe’s desk layout
Custom component library❌ NoRequires building on Frappe UI (Vue 3 + Tailwind)
Per-tenant branding❌ NoRequires custom multi-tenant theme system

The Reskinning Architecture

Solanasis needs a three-layer approach to achieve a fully modern, unrecognizable UI:

Layer 1: Branding (Week 1-2)
├── Logo, favicon, colors, fonts
├── ERPNext Whitelabel module for quick wins
├── Custom CSS overrides via hooks.py
└── Hide all ERPNext/Frappe branding

Layer 2: Theme System (Month 1-2)
├── Custom Frappe UI theme (Vue 3 + Tailwind)
├── Redesigned color palette, typography, spacing
├── Custom login/signup pages
├── Redesigned sidebar navigation
├── Modern card-based layouts vs ERPNext's table-heavy defaults
└── Dark mode support (differentiator — ERPNext doesn't have this natively)

Layer 3: Deep UI Redesign (Month 2-4)
├── Custom Vue.js page components for key workflows
├── Redesigned CRM pipeline (Kanban with custom cards)
├── Modern dashboard with data visualization (Recharts/D3)
├── Custom onboarding wizard for new client tenants
├── Mobile-responsive design overhaul
├── Per-tenant theme configuration (colors, logos, fonts per client)
└── Design system documentation for consistency

Technical Implementation Approach

1. Frappe UI Component Library (Your Foundation)

Frappe UI is a Vue 3 + Tailwind CSS component library maintained by Frappe. This is your starting point for building custom UI:

  • Components: Button, Dialog, Input, TextInput, Autocomplete, Avatar, Badge, etc.
  • Built on Tailwind CSS = easy to restyle with utility classes
  • Already used by Frappe CRM and newer Frappe apps
  • You can extend/override individual components without replacing the entire UI

2. Custom App Hooks for UI Overrides

In your solanasis_whitelabel custom app’s hooks.py:

# Override website templates
website_context = {
    "favicon": "/assets/solanasis_whitelabel/images/favicon.ico",
    "splash_image": "/assets/solanasis_whitelabel/images/splash.png",
}
 
# Inject custom CSS/JS on every page
app_include_css = "/assets/solanasis_whitelabel/css/solanasis-theme.css"
app_include_js = "/assets/solanasis_whitelabel/js/solanasis-overrides.js"
 
# Override Jinja2 templates
override_doctype_class = {
    # Override specific DocType renderers
}
 
# Website page overrides
website_route_rules = [
    {"from_route": "/login", "to_route": "solanasis_login"},
]

3. CSS Variable Architecture (Quick Wins)

Frappe uses CSS variables that can be overridden globally:

:root {
    /* Override Frappe's default colors */
    --primary: #YOUR_BRAND_COLOR;
    --primary-light: #YOUR_LIGHT_VARIANT;
    --text-color: #YOUR_TEXT_COLOR;
    --bg-color: #YOUR_BG_COLOR;
 
    /* Override typography */
    --font-stack: 'Your Font', -apple-system, sans-serif;
 
    /* Custom Solanasis variables */
    --solanasis-accent: #ACCENT_COLOR;
    --solanasis-sidebar-bg: #SIDEBAR_BG;
    --solanasis-card-radius: 12px;
}

4. Per-Tenant Theming for Client Reselling

Build a Theme Configuration DocType in your custom app:

DocType: Solanasis Theme
Fields:
  - tenant_site (Link to Site)
  - primary_color (Color)
  - secondary_color (Color)
  - logo (Attach Image)
  - favicon (Attach Image)
  - font_family (Data)
  - sidebar_style (Select: light/dark)
  - custom_css (Code)

Load the theme CSS dynamically per tenant in your app’s boot script.

Design Inspiration & Benchmarks

The goal is to make the platform look like these modern SaaS products (not like a traditional ERP):

  • Linear — Clean, minimal, fast-feeling UI with keyboard shortcuts
  • Notion — Flexible layouts, beautiful typography, approachable
  • Attio — Modern CRM with custom objects and beautiful data visualization
  • Plane — Open source project management with a premium feel

What Makes a UI Feel “Modern” vs “Legacy ERP”

Legacy ERP Feel (avoid)Modern SaaS Feel (target)
Dense table views with 20+ columnsCard-based layouts with progressive disclosure
Gray/blue enterprise color paletteVibrant but restrained brand colors
Small, cramped typographyGenerous spacing, readable fonts (16px+ body)
Deep menu hierarchiesFlat navigation, command palette (Cmd+K)
Form-heavy data entryInline editing, smart defaults, auto-save
No animationsSubtle micro-interactions, smooth transitions
Desktop-only layoutResponsive, mobile-first approach
Generic iconsCustom iconography, illustrations

Estimated Level of Effort

PhaseTimelineEffortResult
Layer 1: Branding1-2 weeks1 personLooks different but still “Frappe-like”
Layer 2: Theme System4-6 weeks1-2 peopleFeels noticeably different, modern polish
Layer 3: Deep Redesign8-12 weeks2-3 people (frontend-heavy)Completely unrecognizable as ERPNext
Per-Tenant Theming2-3 weeks1 personEach client sees their own brand

Pro Tips for Reskinning

  1. Start with Layer 1 immediately — even basic branding makes it feel “yours” from day one
  2. Hire a UI/UX designer (even as a contractor) — developer-designed UIs always look like developer-designed UIs. A designer will 10x the perceived quality for relatively low cost.
  3. Build a design system early — Document colors, typography, spacing, components in a Storybook or equivalent. This saves massive time when multiple people are building UI.
  4. Don’t fight Frappe’s layout for everything — Override the key pages (dashboard, CRM pipeline, login, onboarding) but let Frappe handle the admin/settings pages. 80/20 rule.
  5. Command palette is a quick win — Adding Cmd+K search (like Linear, Notion, Slack) immediately makes the app feel modern and premium. Frappe has frappe.ui.toolbar.search() you can build on.
  6. Dark mode is a premium signal — Implementing dark mode is relatively easy with CSS variables and signals “modern, polished product” to clients.

Risk: v16 UI Reception

The verification agents confirmed that ERPNext v16’s new UI has received mixed-to-negative reception from users. This is actually an OPPORTUNITY for Solanasis — you can build a better UI than the upstream project, making your fork more attractive than vanilla ERPNext. Key complaints to address in your redesign:

  • Users find features hard to locate in v16’s new layout
  • No customization options for the workspace
  • Breaking changes from v15 frustrated existing users

Your custom UI that addresses these pain points becomes a competitive advantage.

Risk Assessment

RiskProbabilityImpactMitigation
Upstream license change to AGPLLow-MediumHighMonitor Frappe announcements; your existing fork stays GPL v3 regardless
Heavy customization breaks on upgradeMediumHighCustom apps only, never modify core; comprehensive E2E test suite
Cold email integration complexityMediumMediumStart with proven tools (Instantly.ai, Smartlead); build native module later
Multi-tenancy scaling issuesLowMediumDatabase-per-tenant architecture; horizontal scaling plan
Trademark enforcement by FrappeLowMediumNever use “ERPNext” or “Frappe” in your product name
Team capacity for ERP customizationMedium-HighHighStart with minimal customization; leverage Frappe’s low-code capabilities
Community support inadequacyMediumMediumBuild internal expertise; budget for self-sufficiency
Client data migration complexityMediumMediumBuild standardized migration tooling as a custom app
UI reskinning scope creepMedium-HighHighPhase the work (Layer 1→2→3); hire a UI/UX designer early; don’t try to redesign everything
Frappe CRM AGPL v3 license conflictHighHighBuild custom CRM on GPL v3 Frappe Framework OR accept AGPL obligations; get legal counsel
JavaScript distribution triggers GPLMediumHighKeep proprietary JS separate from GPL JS; document what’s GPL vs proprietary

Clarifying Questions for Dmitri

Please review each question below and select your answer (or provide notes). These will shape the next phase of implementation planning.

Question 1: Primary Tech Stack Comfort

Why this matters: ERPNext uses Python/JavaScript/Vue.js; Tryton is Python-only; Odoo is Python; OFBiz is Java. Your team’s comfort with the stack directly impacts development speed and ability to customize deeply.

Why Option A is recommended: Python + JS/Vue.js (Frappe’s stack) is the most versatile for web SaaS development and has the largest talent pool for 1099 contractors.

  • A) Python + JavaScript/Vue.js (Frappe/ERPNext stack) — Modern, large talent pool, full-stack web development
  • B) Python only (Tryton) — Simpler stack but limits frontend customization
  • C) PHP (Dolibarr) — Widely known but less suited for complex SaaS
  • D) Java (OFBiz/iDempiere) — Enterprise-grade but steeper learning curve, smaller contractor pool

Notes: _______________________________________________

Question 2: SaaS Multi-Tenancy Model

Why this matters: This affects data isolation, cost per tenant, compliance posture, and architectural complexity. Since your clients are SMBs and nonprofits, they may have varying data sensitivity requirements.

Why Option A is recommended: Database-per-tenant gives the strongest data isolation story for selling to organizations that care about data privacy (which is part of Solanasis’s value proposition as an operational resilience partner).

  • A) Database-per-tenant — Each client gets their own database. Best isolation, slightly more expensive, easier compliance story.
  • B) Shared database with site separation — Frappe’s native approach. More efficient, less isolation. Good for getting started fast.
  • C) Hybrid — Start with shared, migrate high-value clients to dedicated. More complex to manage.
  • D) Not sure yet — Need to understand client needs better first

Notes: _______________________________________________

Question 3: Cold Email/Outreach Tool Strategy

Why this matters: No open source ERP has enterprise-grade cold email built in. You need to decide whether to integrate with a dedicated tool or build your own from the start.

Why Option A is recommended: Using a proven tool immediately lets you start your pipeline now while you build a native solution over time. Building from scratch would delay your outreach by months.

  • A) Integrate with a dedicated tool now (Instantly.ai, Smartlead, etc.), build native module later — Fastest path to pipeline, recurring tool cost ($50-200/mo)
  • B) Build a native cold email module on Frappe from day one — Full control, no recurring cost, but 2-4 months to build properly
  • C) Use n8n (self-hosted automation) to bridge Frappe CRM with SMTP providers — Middle ground, more control than SaaS tool, faster than building native
  • D) Stick with a simple approach (Baserow + email tool) until the ERP is fully set up — Defer the CRM migration

Notes: _______________________________________________

Question 4: AWS vs Azure for Primary Hosting

Why this matters: Both work fine, but your credit balance and existing familiarity should drive the decision. Some services differ in pricing and capabilities.

Why Option A is recommended: AWS has better MariaDB support (RDS), more Frappe community deployment guides, and generally more flexibility for containerized workloads.

  • A) AWS — Better MariaDB support (RDS), more ERPNext community deployment docs, larger ecosystem
  • B) Azure — Better if you have more credits here, good if clients are Microsoft-ecosystem shops
  • C) Split — Production on one, staging/dev on the other to use both credit pools
  • D) Start with a simpler setup (single VPS like Hetzner/DigitalOcean) and migrate to AWS/Azure later — Cheapest to start, migration cost later

Notes: _______________________________________________

Question 5: Initial SaaS Scope

Why this matters: ERPNext has 15+ modules. Trying to customize and offer everything as SaaS from day one would be overwhelming. Starting focused is smarter.

Why Option A is recommended: CRM + Project Management aligns directly with Solanasis’s consulting/services model and lets you dogfood your own product while building the SaaS.

  • A) CRM + Project Management first — Aligns with your consulting services model, manageable scope
  • B) CRM + Accounting + HR — Broader offering but more complexity to customize and support
  • C) Full ERP from day one — Maximum offering but highest risk of scope creep
  • D) CRM only — Minimal scope, fastest to market, but limited differentiation from existing CRM SaaS products

Notes: _______________________________________________

Question 6: White-Labeling Depth

Why this matters: Determines how much frontend customization work is needed before you can put the product in front of clients.

Why Option A is recommended: Custom branding with standard UI gives you a professional look quickly. Deep UI redesign would delay launch by months and require dedicated frontend developers.

  • A) Custom branding (logo, colors, domain) but keep standard Frappe UI layout — Fast, professional, minimal frontend work
  • B) Deep UI redesign — completely custom look and feel — Premium feel, but 3-6 months of frontend work
  • C) Different branding per client (full white-label) — Each client sees their own brand. Adds complexity but valuable for resellers.
  • D) Start unbranded, add white-labeling later — Fastest to market, looks less professional initially

Notes: B - need to make it look modern and differentiated with modern UI/UX _______________________________________________

Question 7: Forking Approach

Why this matters: Impacts your ability to pull upstream updates, your IP separation clarity, and how contractors work with the codebase.

Why Option A is recommended: Custom Frappe apps on top of unmodified core is the officially recommended approach, keeps your IP cleanly separated, and makes upstream merges trivial. This is the most “smartcuts” approach — leverage the upstream work, layer your value on top.

  • A) Custom Frappe apps on top of unmodified ERPNext/Frappe core — Cleanest upgrade path, clear IP boundary, officially recommended approach
  • B) Hard fork with core modifications — Maximum control, but upgrade hell and GPL compliance gets murky
  • C) Hybrid — custom apps for most things, selective core patches for critical needs — Pragmatic middle ground, requires discipline to track patches
  • D) Don’t fork at all — use Frappe Cloud hosting and build custom apps as add-ons — Simplest path, but less control over infrastructure

Notes: C - need to be able to rework certain parts and keep track of all of our core changes_______________________________________________

Question 8: Timeline Priority

Why this matters: Shapes whether to optimize for speed-to-market or thoroughness of customization.

Why Option A is recommended: Getting your own pipeline running on Frappe CRM first lets you dogfood the platform, understand its strengths/weaknesses, and start building pipeline immediately while developing the SaaS offering in parallel.

  • A) Get Solanasis’s own CRM/pipeline running on Frappe CRM within 30 days, then build SaaS offering in parallel — Dogfood first, SaaS second
  • B) Build the SaaS platform first (3-6 months), then migrate Solanasis to it — More polished initial offering
  • C) Run both tracks simultaneously from day one — Aggressive but requires more bandwidth
  • D) Prototype with a managed ERPNext host first, then decide on self-hosting — Lowest initial effort, delayed learning

Notes: _______________________________________________

Question 9: AI Integration Approach

Why this matters: AI integration is a major differentiator but also a significant development effort. The approach you choose affects timeline, cost, and the value you deliver to clients.

Why Option A is recommended: Building a dedicated Frappe app for AI gives you full control over the integration, clean separation of concerns, and the ability to iterate independently. Starting with Claude API is the fastest path to a working AI sidekick.

  • A) Build a custom solanasis_ai Frappe app with Claude API integration — Full control, clean architecture, iterative rollout of AI features
  • B) Use an existing AI chatbot framework (like Rasa or Botpress) embedded in Frappe — Pre-built conversation management, but adds another dependency
  • C) Build MCP (Model Context Protocol) server for Frappe — Claude Code / desktop Claude could connect directly to your ERP data. Cutting-edge, but newer technology.
  • D) Start with simple AI features (email drafting, summarization) via server scripts, build a full AI layer later — Lowest effort, fastest to demo, less architectural planning upfront

Notes: _______________________________________________

Question 10: AI Cost Model for SaaS Clients

Why this matters: AI API costs are real and per-tenant. You need to decide how to handle this in your pricing model.

Why Option A is recommended: Including AI with usage caps lets you market AI as a core feature (differentiator) while protecting against runaway costs. You can monetize heavy users with premium tiers.

  • A) Include AI features with usage caps (e.g., 500 AI queries/month), premium tier for unlimited — AI as a core differentiator, sustainable cost model
  • B) AI as a paid add-on module — Only clients who want it pay for it, simpler cost management
  • C) All-inclusive pricing (absorb AI costs) — Simplest for clients, but you eat the API costs
  • D) Usage-based pricing (per AI query) — Most fair, but unpredictable bills scare SMB clients

Notes: _______________________________________________

Appendix: Additional Considerations for a Small Team SaaS

Contractor/1099 Developer Onboarding

Since Solanasis will rely on 1099 contractors following SOPs, the Frappe development environment needs:

  • Standard dev environment: Docker-based local setup so every contractor has an identical environment in minutes
  • Branch strategy: main (production) → staging (QA) → feature/* branches per task
  • Code review: All PRs require review before merge — AI-assisted code review can help here
  • Secrets management: Use environment variables or a vault (AWS Secrets Manager / Azure Key Vault) — never commit API keys
  • Onboarding SOP: Step-by-step guide: fork the repo → set up Docker → run tests → make first PR

Data Migration Tooling (Critical for Client Onboarding)

Every new client means migrating data from their existing systems. Build a standardized solanasis_migrations Frappe app:

  • CSV/Excel import templates per DocType
  • Validation rules that catch bad data before import
  • Rollback capability (snapshot before migration, restore on failure)
  • Migration audit log (what was imported, from where, by whom)
  • Pre-built connectors for common sources: QuickBooks, Salesforce, HubSpot, Google Sheets

SaaS Operations & Support

  • Use Frappe Desk (already in the ecosystem) as your support ticketing system
  • Define SLA tiers aligned with pricing (e.g., 24hr response for standard, 4hr for premium)
  • Build a self-serve knowledge base for common questions
  • Client communication: monthly check-ins, release notes, feature announcements

Security & Compliance Roadmap

Given Solanasis’s positioning as an operational resilience partner, security credibility is essential:

  • Phase 1: Basic security hygiene — encrypted connections (TLS), database encryption at rest, regular backups, role-based access control (built into Frappe)
  • Phase 2: SOC 2 Type I preparation — document policies, access controls, incident response plan
  • Phase 3: SOC 2 Type II audit — demonstrate controls operating over time
  • GDPR/CCPA: Build data subject request handling into the platform (export, delete)
  • Data residency: Use AWS/Azure region selection to keep client data in required jurisdiction

Competitive Differentiation (Why Solanasis vs DIY ERPNext)

The key question clients will ask: “Why pay Solanasis when ERPNext is free?”

Answer — Solanasis delivers value through:

  1. Completely custom, modern UI — Looks and feels like a premium SaaS product, not a free open source tool. Clients will never know it’s ERPNext under the hood.
  2. AI-powered operations — Built-in AI sidekick that no self-hosted ERPNext has
  3. Managed & optimized — We handle hosting, upgrades, security, backups
  4. Industry-specific customization — Pre-configured for SMB/nonprofit workflows
  5. Operational resilience expertise — Cybersecurity assessments, DR, and data migration bundled with the platform
  6. White-glove onboarding — Data migration + training + ongoing support
  7. Integration suite — Pre-built connectors for the tools SMBs actually use
  8. The “lovable” factor — Personable team, clear SOPs, responsive support

This is the full stack of value that justifies SaaS pricing over self-hosting.

Verification Report: Fact-Check Results

All claims in this document were independently verified by dedicated verification agents checking primary sources (GitHub repos, official documentation, license texts, court records, pricing pages, Reddit, G2 reviews, and community forums). Below is the consolidated verification summary.

Corrections Applied Based on Verification

Original ClaimIssue FoundCorrection Applied
ERPNext: “10,611 stars”Stars/forks were reversedCorrected to ~32,152 stars, ~10,611 forks
Frappe: “4,718 stars”Stars/forks were reversedCorrected to ~9,780 stars, ~4,718 forks
GPL v3 “Section 6” quoteQuote is in Section 0 (Definitions), not Section 6Corrected to Section 0
Orange case: “€800,000”Actual total was €860,000Corrected with full breakdown
”Require CLAs”CLAs are optional, not required for GPL v3Changed to “Consider CLAs or DCOs” with explanation
AWS RDS cost: ”~$65/month”Actual: ~$80.30/monthCorrected; total revised to ~$195-210/month
PostgreSQL supportERPNext requires MariaDB for productionAdded clarification that PostgreSQL is Frappe Framework only
Tryton: “No Kanban boards”Kanban views ARE available in TrytonCorrected
iDempiere: “410 stars”Actual: ~431 starsMinor correction noted
”75% of users report doc gaps”Percentage unverifiableRemoved specific percentage
”G2 rating 6.3/10 for support”Specific rating unverifiableRemoved specific rating; kept verified complaint
”Breaks above 50 recipients”Specific threshold unverifiableRemoved; kept verified unsubscribe bug (Issue #52448)
Frappe CRM licenseFrappe CRM is AGPL v3, NOT GPL v3Added critical warning about AGPL implications for SaaS
Azure Cache for RedisBeing retired Sept 2028Updated to recommend Azure Managed Redis
Multi-tenancy: “port-based”DNS-based is more common in productionAdded DNS-based as the standard production approach
ERPNext v16 receptionNot mentioned originallyAdded mixed/negative user reception with specific complaints

Claims Verified as Accurate

  • ✅ ERPNext license: GPL-3.0-only (confirmed via GitHub LICENSE file)
  • ✅ Frappe Framework license: GPL-3.0 (confirmed via GitHub)
  • ✅ 171+ apps in Frappe ecosystem (confirmed via awesome-frappe.gavv.in)
  • ✅ 22k+ forum users (confirmed via discuss.frappe.io)
  • ✅ Frappe CRM launched 2023 with WhatsApp, Twilio, Exotel, email sync (confirmed via official docs)
  • ✅ ERPNext Whitelabel module exists and works as described (confirmed via Frappe Cloud Marketplace)
  • ✅ Cypress E2E tests in frappe/erpnext_ui_tests (confirmed via GitHub)
  • ✅ v16 EOL: End of 2029 (confirmed via GitHub wiki Supported-Versions)
  • ✅ Resource requirements: 8GB RAM DB, 400MB/bench, 2N+1 workers (confirmed via official docs)
  • ✅ Multi-tenancy: port-based and DNS-based both supported (confirmed via frappe_docker docs)
  • ✅ DocType REST API auto-generation (confirmed via Frappe REST API docs)
  • ✅ Odoo CE: LGPL v3, 48.5k stars, 31.1k forks (confirmed via GitHub)
  • ✅ Odoo CE vs Enterprise feature gap: all listed gaps confirmed (Studio, workflows, inventory, mobile, AI lead scoring)
  • ✅ OCA: Founded 2014, 4,500+ modules, 1,500 contributors (confirmed via odoo-community.org)
  • ✅ Axelor: AGPL v3, 927 stars (confirmed via GitHub and official site)
  • ✅ Apache OFBiz: Apache 2.0, v24.09.05 released Jan 20, 2026 (confirmed)
  • ✅ Dolibarr: 6.7k stars, 3.2k forks (confirmed via GitHub)
  • ✅ Tryton: GPL v3.0-or-later, v7.8.1 released Dec 20, 2025, Heptapod/Mercurial hosting (all confirmed)
  • ✅ Tryton performance issues with large tables (confirmed via discuss.tryton.org)
  • ✅ GPL v3 SaaS loophole: accurate quote, correct legal interpretation (confirmed via license text and legal analyses)
  • ✅ AGPL v3 Section 13 closes the SaaS loophole (confirmed via FSF and license text)
  • ✅ Apache 2.0 permissiveness for proprietary SaaS (confirmed via license text)
  • ✅ ERPNext trademark restrictions on domain/product names (confirmed via TRADEMARK_POLICY.md)
  • ✅ ERPNext CRM unsubscribe bug (confirmed: GitHub Issue #52448)
  • ✅ ERPNext v16 scheduler bug (confirmed: Frappe GitHub Issue #37490)
  • ✅ ERPNext v16 link field bug (confirmed: GitHub Issues #52864, #35354)
  • ✅ Tryton documentation quality complaints (confirmed: discuss.tryton.org, Capterra reviews)

Legally Ambiguous Areas Flagged

  1. JavaScript in SaaS = distribution? — Serving GPL-licensed JavaScript to browsers IS generally considered distribution, triggering GPL obligations. However, serving proprietary JS that communicates with a GPL backend does NOT trigger obligations. The line depends on which code is GPL-licensed. Recommendation: Get legal counsel on this specific point.

  2. AGPL + GPL mixing — GPL v3 and AGPL v3 are compatible per Section 13 of both licenses. However, when combined, the stricter AGPL network-disclosure requirements apply to the combined work. This is particularly relevant since Frappe CRM is AGPL v3. Recommendation: Either build your own CRM module on GPL v3 Frappe Framework, or accept AGPL obligations.

  3. “Fork stays GPL v3 forever” — Essentially correct for any fork that accepts external contributions. Technically, if you are the sole copyright holder, you can relicense — but this is impossible once contractors contribute code. Recommendation: Treat as permanent.

Verification Sources Used

  • GitHub repositories: frappe/erpnext, frappe/frappe, frappe/frappe_docker, frappe/erpnext_ui_tests, tryton/trytond, odoo/odoo, axelor/axelor-open-suite, Dolibarr/dolibarr, idempiere/idempiere, apache/ofbiz-framework
  • License texts: GPL v3, AGPL v3, LGPL v3, Apache 2.0 (gnu.org, apache.org)
  • Legal analyses: DLA Piper (Orange v. Entr’Ouvert), Mend.io, Revenera, FOSSA, Software Freedom Law Center
  • Official documentation: docs.frappe.io, tryton.org, odoo.com/documentation
  • Community forums: discuss.frappe.io, discuss.tryton.org, G2.com, Capterra, Reddit
  • Pricing: AWS pricing calculator, Vantage instances.vantage.sh, Economize Cloud
  • Court records: Orange v. Entr’Ouvert (Paris, Feb 14, 2024)

Self-Hosting Section Verification (Round 2)

ClaimStatusCorrection
Cloudflare Tunnel completely free, no limits✅ Verified—
WSL2 ~20x better I/O performance⚠️ Partially correctChanged to “5-20x” range; varies by operation type
Xfinity ToS prohibits servers✅ Verified—
Xfinity 1.2TB/month data cap❌ OutdatedCorrected: Xfinity removed data caps in 2025 for new plans
Cloudflare Tunnel ~50-200ms latency⚠️ Partially correctTypical is 15-45ms; extremes can reach 500ms+
frappe_docker supports WSL2 for dev & prod⚠️ Partially correctAdded note: officially supported for dev only, not recommended for production
Cloudflare free tier Auto Minify❌ FalseCorrected: Auto Minify deprecated Aug 2024; use build pipeline instead
ERPNext 2+ hours slow on WSL2✅ VerifiedGitHub Issue #1365 confirmed
Xfinity blocks ports 25, 80, 443⚠️ Partially correctPort 25 blocked; 80 NOT officially blocked; 443 inconsistent. Corrected.
Tunnel maintains 4+ connections⚠️ ClarifiedExactly 4 connections to 2+ data centers by default; up to 25 replicas

Dmitri’s Answers & Strategy Updates

Q6 Answer: B — Deep UI Redesign

Dmitri chose Option B: Deep UI redesign — completely custom look and feel. This confirms that the UI/UX overhaul is a top priority. The Solanasis platform must be completely unrecognizable as ERPNext. This means:

  • Layer 3 (Deep Redesign) is NOT optional — it’s the target state
  • Budget 8-12 weeks of frontend-heavy work (2-3 people including a UI/UX designer)
  • Design system first — before writing any custom Vue.js components, establish the design language
  • Solanasis brand palette is already defined (Navy #020532, Parchment FEF9F1, Copper C47A3D) — this becomes the foundation of the theme
  • Still start with Layer 1 (branding) immediately, but plan and execute all three layers

Q7 Answer: C — Hybrid Forking (Custom Apps + Selective Core Patches)

Dmitri chose Option C: Hybrid — custom apps for most things, selective core patches for critical needs. This is pragmatic. Implementation approach:

  • 95% of work in custom Frappe apps (solanasis_core, solanasis_whitelabel, etc.)
  • 5% selective core patches — only when absolutely necessary (e.g., deep UI layout changes that can’t be done via hooks)
  • Patch tracking system required: Maintain a CORE_PATCHES.md file that documents every core modification with:
    • File path modified
    • What was changed and why
    • Upstream issue/PR reference (if applicable)
    • Reapply instructions for next upstream version
  • Rebase strategy: When upstream releases a new version, reapply patches from CORE_PATCHES.md — this is where E2E tests are critical
  • Minimize core patches aggressively — every core patch is tech debt. Before patching core, exhaust all alternatives (hooks, monkey-patching, custom app overrides)

Self-Hosting Guide: Windows WSL2 + Docker + Cloudflare Tunnel

Context: Dmitri has a Windows machine with WSL2 and Docker Engine, and Xfinity internet in Boulder, CO. This section covers how to self-host ERPNext at home to avoid cloud costs, using Cloudflare Tunnel for secure internet access.

Architecture Overview

Internet Users
       │
       ▼
┌──────────────────────────┐
│   Cloudflare Edge (CDN)   │  ← Free tier: SSL, caching, DDoS protection
│   + Cloudflare Tunnel     │  ← Free: no open ports needed
└──────────┬───────────────┘
           │ Encrypted outbound tunnel
           ▼
┌──────────────────────────┐
│  Dmitri's Windows Machine │
│  ┌─────────────────────┐ │
│  │       WSL2           │ │
│  │  ┌────────────────┐  │ │
│  │  │  Docker Engine  │  │ │
│  │  │                 │  │ │
│  │  │  ┌───────────┐  │  │ │
│  │  │  │ cloudflared│  │  │ │  ← Tunnel connector (free)
│  │  │  └───────────┘  │  │ │
│  │  │  ┌───────────┐  │  │ │
│  │  │  │  ERPNext   │  │  │ │  ← Frappe + ERPNext app
│  │  │  │  (Gunicorn)│  │  │ │
│  │  │  └───────────┘  │  │ │
│  │  │  ┌───────────┐  │  │ │
│  │  │  │  MariaDB   │  │  │ │  ← Database
│  │  │  └───────────┘  │  │ │
│  │  │  ┌───────────┐  │  │ │
│  │  │  │   Redis    │  │  │ │  ← Cache + Queue
│  │  │  └───────────┘  │  │ │
│  │  └────────────────┘  │ │
│  └─────────────────────┘ │
│  ┌─────────────────────┐ │
│  │       UPS            │ │  ← Recommended: 1-2 kVA (~$200)
│  └─────────────────────┘ │
└──────────────────────────┘

Step-by-Step Setup Guide

Prerequisites:

  • Windows 10/11 with WSL2 enabled
  • Docker Desktop or Docker Engine in WSL2
  • Cloudflare account (free) with a domain
  • Minimum 8GB RAM on host machine (16GB recommended)
  • SSD storage (HDD will be painfully slow)

Step 1: Prepare WSL2 for Optimal Performance

# CRITICAL: Store ALL project files in the WSL2 filesystem, NOT /mnt/c/
# This gives ~20x better I/O performance
cd ~
mkdir -p erpnext-home
cd erpnext-home

Pro Tip: The #1 performance mistake people make with WSL2 + Docker is storing files on the Windows filesystem (/mnt/c/). Docker file operations are dramatically slower (benchmarks vary but can be 5-20x slower depending on the operation) on Windows NTFS mounts vs the native ext4 filesystem inside WSL2. Always keep your Docker volumes and project files in the WSL2 home directory. Note: frappe_docker officially supports WSL2 for development, but production on WSL2 is not officially recommended — use it for dev/staging and cloud for production.

Step 2: Clone frappe_docker

git clone https://github.com/frappe/frappe_docker.git
cd frappe_docker

Step 3: Configure for Production

Use the production Docker Compose setup from frappe_docker. Key configuration:

# docker-compose.yml (simplified — use official production config)
services:
  erpnext:
    image: frappe/erpnext:v16
    ports:
      - "8080:8080"
    volumes:
      - sites:/home/frappe/frappe-bench/sites
    depends_on:
      - mariadb
      - redis-cache
      - redis-queue
 
  mariadb:
    image: mariadb:10.6
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    volumes:
      - mariadb-data:/var/lib/mysql
 
  redis-cache:
    image: redis:alpine
 
  redis-queue:
    image: redis:alpine
 
  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=${CLOUDFLARE_TUNNEL_TOKEN}
 
volumes:
  sites:
  mariadb-data:

Step 4: Create Cloudflare Tunnel

  1. Go to https://dash.teams.cloudflare.com → Networks → Tunnels
  2. Create a tunnel, give it a name (e.g., “solanasis-home”)
  3. Copy the tunnel token
  4. Add to your .env file: CLOUDFLARE_TUNNEL_TOKEN=your-token-here
  5. Configure public hostname: erp.yourdomain.com → http://erpnext:8080

Step 5: Configure Multi-Site (Multi-Tenant) via Tunnel

Single tunnel, multiple sites:

# Cloudflare Tunnel ingress rules (configured in dashboard or config.yml)
ingress:
  - hostname: erp.solanasis-internal.com
    service: http://erpnext:8080
  - hostname: staging.solanasis-internal.com
    service: http://erpnext-staging:8080
  - hostname: client1.yoursaas.com
    service: http://erpnext:8080  # Frappe DNS multi-tenancy handles routing
  - service: http_status:404

CDN Strategy with Cloudflare Free Tier

What Gets Cached (Free):

Asset TypeCached?TTLImpact
CSS files (/assets/*.css)✅ Yes1 year (versioned)Major — reduces bandwidth
JavaScript (/assets/*.js)✅ Yes1 year (versioned)Major — faster page loads
Images (/files/*)✅ Yes30 daysMajor — uploaded images served from edge
Fonts (/assets/fonts/*)✅ Yes1 yearModerate — fewer requests
HTML pages❌ No (dynamic)N/ACan’t cache — dynamic content
API responses❌ NoN/AShould not cache — real-time data

Configuration in Frappe:

// common_site_config.json
{
  "serve_default_site": true,
  "dns_multitenant": true
}

Cloudflare Dashboard Settings:

  • Caching → Cache Rules → Create rule for /assets/* with Edge TTL of 1 month
  • Speed → Auto Minify DEPRECATED — Cloudflare removed Auto Minify in August 2024. Instead, handle minification in your build pipeline (e.g., Frappe’s asset bundler already minifies in production mode)
  • Speed → Brotli → Enable
  • Speed → Early Hints → Enable
  • SSL → Full (Strict)

Expected Performance Improvement:

  • Static asset load: 30-50% faster (served from nearest Cloudflare edge)
  • Total page load (first visit): ~2-4 seconds (vs 3-6 without CDN)
  • Subsequent visits: ~1-2 seconds (browser cache + CDN)

Xfinity ISP Reality Check

The Hard Truth:

ConcernStatusMitigation
ToS violation⚠️ Running servers violates residential Xfinity ToSCloudflare Tunnel makes it invisible (no open ports), but technically still violates ToS
Upload speed⚠️ 10-35 Mbps typicalSufficient for <50 concurrent users with CDN offloading static assets
Dynamic IP✅ Not an issueCloudflare Tunnel handles this — no DNS updates needed
Port blocking✅ Not an issue with TunnelXfinity blocks port 25 (SMTP); ports 80/443 are NOT officially blocked but some users report inconsistent blocking. Cloudflare Tunnel bypasses all of this since it uses outbound HTTPS only
Data caps✅ Xfinity removed data caps in 2025 — new plans have unlimited data (verify your specific plan; some legacy/grandfathered plans may still have the old 1.2TB cap)Should not be an issue on current plans
Reliability❌ No SLAISP outage = your SaaS is down

Recommendation: For development and staging, residential Xfinity is fine. For production SaaS, consider upgrading to Comcast Business ($150/month) which explicitly allows servers and provides an SLA.

Production Hardening for Home Server

1. Automated Backups

# Cron job: backup every 6 hours, sync to S3
0 */6 * * * docker exec erpnext bench --site all backup
0 1 * * * rclone sync ~/erpnext-home/backups s3:solanasis-backups/

2. UPS Configuration

  • Buy a 1-2 kVA UPS (~$200, e.g., APC Back-UPS Pro 1500)
  • Install apcupsd in WSL2 for monitoring
  • Configure graceful Docker shutdown on battery low:
# /etc/apcupsd/apccontrol
# On battery low: gracefully stop containers
docker compose -f ~/erpnext-home/docker-compose.yml down

3. Auto-Recovery After Power/Restart

# Add to WSL2 /etc/wsl.conf or Windows Task Scheduler
# Auto-start Docker containers on WSL boot
[boot]
command = "docker compose -f /home/dmitri/erpnext-home/docker-compose.yml up -d"

4. Monitoring Stack (Free)

  • Uptime Kuma (self-hosted, in Docker): HTTP monitoring + alerts
  • ntfy.sh (free push notifications): Alert to phone when services go down
  • Healthchecks.io (free tier): Cron job monitoring for backups

5. Windows Update Protection

# Disable automatic restarts (Group Policy)
# Computer Configuration → Admin Templates → Windows Components → Windows Update
# Configure: "No auto-restart with logged on users for scheduled updates" → Enabled

Cost Comparison: Home vs Cloud

SetupMonthly CostUptimeBest For
Home only (residential Xfinity)~60 + electricity $30)95-98%Dev/staging, personal use
Home + Comcast Business~150 + electricity 30)98-99%Internal tools, early SaaS clients who tolerate some downtime
Hybrid: Home staging + Cloud prod~90 + cloud $190)99.5%+ for prodRecommended — best of both worlds
Cloud only (AWS/Azure with credits)~$195-210 (covered by credits initially)99.9%When credits last, this is the winner

Given that you have AWS/Azure credits AND a home server:

  1. Home Server (WSL2 + Docker + Cloudflare Tunnel):

    • Development environment
    • Staging/testing environment
    • Local AI model experimentation
    • Build and test custom Frappe apps
    • Cost: ~$0 incremental (you already have the machine and internet)

  2. Cloud (AWS/Azure, using credits):

    • Production SaaS environment
    • Client-facing deployments
    • Automated backups, monitoring, scaling
    • Cost: 195-210/month

  3. Cloudflare (Free tier for both):

    • CDN for static assets (prod and staging)
    • Tunnel for home server access
    • SSL/TLS for both environments
    • DDoS protection

This gives you the ability to develop for free at home, test without cloud costs, and deploy to reliable cloud infrastructure for clients.

Pro Tips for Home Hosting

  1. Use WSL2 native filesystem — store everything under /home/, NOT /mnt/c/. This is the single biggest performance win (~20x faster I/O).
  2. Pin your Docker images — use frappe/erpnext:v16.x.x not latest to avoid surprise breaking changes
  3. Test your backup restore process — a backup you’ve never restored is not a backup
  4. Monitor your Xfinity data cap — 1.2TB/month sounds like a lot but video calls + backups + updates add up
  5. Set up WoL (Wake on LAN) — if your machine sleeps, you can wake it remotely via Cloudflare Access + a WoL trigger
  6. Create a recovery runbook — document every step to rebuild from scratch. When (not if) something breaks at 2am, you want a checklist, not a debugging session.

Next Steps: Detailed Planning Documents Needed

Based on all research and Dmitri’s answers, the following detailed planning documents should be created as separate deep-dive artifacts:

1. UI/UX Deep Planning Document (HIGH PRIORITY)

  • Complete design system specification using Solanasis brand palette
  • Wireframes for key pages (dashboard, CRM pipeline, login, onboarding)
  • Vue.js component architecture for custom Frappe UI overrides
  • Design benchmark analysis (Linear, Notion, Attio, Plane)
  • Per-tenant theming technical specification
  • Dark mode implementation plan
  • Timeline with milestones and resource allocation
  • Contractor/designer requirements and job description

2. Technical Architecture Document

  • Complete infrastructure diagram (home + cloud hybrid)
  • Docker Compose configurations for dev, staging, and production
  • Cloudflare Tunnel setup with multi-tenant routing
  • CI/CD pipeline design (GitHub Actions)
  • Database schema extensions for custom DocTypes
  • API design for integrations (cold email, AI, etc.)

3. Licensing & Compliance Playbook

  • Detailed GPL v3 compliance checklist
  • AGPL v3 risk mitigation plan (avoiding Frappe CRM dependency)
  • JavaScript distribution audit
  • Trademark usage guidelines
  • Contractor IP assignment agreements
  • Legal counsel engagement plan

4. E2E Testing Master Plan

  • Cypress test architecture
  • Golden path test definitions
  • Upgrade compatibility test suite
  • Performance benchmarks and thresholds
  • CI/CD integration and nightly run schedule

5. CRM Module Build Specification

  • Custom CRM DocTypes (built on GPL v3 Frappe Framework, NOT Frappe CRM)
  • Pipeline stages and workflow
  • Cold email integration architecture
  • Lead scoring algorithm design
  • Email sync and logging approach

This document will be updated based on Dmitri’s answers to the remaining clarifying questions. Next steps: implementation roadmap, architecture decision records (ADRs), and sprint plan for Phase 1.

Graph View