MWMS MCR

MWMS Automation Architecture And Tool Selection Framework

System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.0
Primary Location: MCR
Future Operational Destination: Automation Brain, HeadOffice Brain, AIBS Brain, Product Brain, Data Brain, Compliance Brain, Risk Brain, Development Governance, Client Delivery Systems
Parent Page: Automation Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-08
Source / Origin: AI Automations by Jack AI Native Entrepreneur Architecture And Tool Decision Block
MWMS Classification: Automation Architecture Framework / Tool Selection Framework / No Code Versus Code Decision Standard / AIOS Build Governance Framework / Client Delivery Architecture Standard
Primary Brain: Automation Brain
Supporting Brains: HeadOffice Brain, AIBS Brain, Product Brain, Data Brain, Compliance Brain, Risk Brain, Sales Brain, UX Brain, Research Brain, Finance Brain, Experimentation Brain

Related Pages: MWMS Micro SaaS Productization And Access Control Framework, MWMS Client Intelligence And Business Memory Automation Framework, MWMS Productized AIOS Service Packaging And Scope Control Framework, MWMS AI Automation Security And Risk Checklist, MWMS AI Usage And Cost Visibility Standard, MWMS AI Tool Permission And Access Framework, MWMS AIBS Business Diagnostic And Opportunity Discovery Framework, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS AI App Builder And Productized Interface Framework, MWMS AI Tool Access Browser Automation And MCP Governance Framework

Purpose

The purpose of the MWMS Automation Architecture And Tool Selection Framework is to define how MWMS chooses the correct automation, AI, database, interface, hosting, and development tool architecture for each internal system, client system, productized AIOS module, or future micro SaaS product.

This framework exists because the AI automation landscape creates constant tool temptation.

MWMS will repeatedly face questions such as:

  • Should this be built in n8n?
  • Should this be built in Make?
  • Should this be built with Claude Code?
  • Should this be built in Lovable?
  • Should this be a Supabase backed product?
  • Should this use Airtable or Google Sheets?
  • Should this use a browser automation tool?
  • Should this be local hosted?
  • Should this use direct APIs?
  • Should this use MCP?
  • Should this be a manual workflow first?
  • Should this be a custom-coded system?
  • Should this be built at all?

This framework prevents MWMS from chasing tools because they are new, popular, cheap, impressive, or heavily promoted.

The core purpose is:

To help MWMS choose the right build architecture for the business problem, instead of forcing every problem into the latest tool.

Core Doctrine

The MWMS doctrine is:

The business problem chooses the architecture. The tool does not choose the business problem.

MWMS must never begin with:

  • “Let’s use n8n.”
  • “Let’s use Claude Code.”
  • “Let’s build it in Lovable.”
  • “Let’s use MCP.”
  • “Let’s automate the browser.”
  • “Let’s make an AI agent.”
  • “Let’s self host it.”
  • “Let’s turn this into an app.”

MWMS must begin with:

  • What problem are we solving?
  • Who owns the problem?
  • What outcome matters?
  • What data is needed?
  • What risk exists?
  • How often does it run?
  • Who uses it?
  • How reliable must it be?
  • How visible must it be?
  • How supportable must it be?
  • What is the simplest safe architecture?

The key doctrine is:

Tool choice is a consequence of diagnosis.

Strategic Importance

This framework is strategically important because MWMS is becoming a multi Brain, multi system, multi employee ecosystem.

That means tool decisions will become more frequent and more dangerous.

Without a decision framework, MWMS risks:

  • overbuilding simple systems
  • underbuilding critical systems
  • choosing tools based on hype
  • creating fragile automations
  • building systems M cannot maintain
  • confusing client-facing products with internal workflows
  • using browser automation where an API should be used
  • using no-code where proper code is required
  • using code where no-code would be faster
  • creating security risks
  • increasing tool costs
  • adding support burden
  • creating unclear ownership
  • creating systems that cannot scale
  • creating systems that cannot be handed over

This framework creates a disciplined path.

The strategic standard is:

MWMS should build measurable systems, not impressive diagrams.

Definition

Automation architecture means the complete structure used to deliver a system, including trigger, data source, automation engine, AI model, database, interface, user access, reporting, hosting, security, and maintenance model.

Tool selection means choosing the correct tool or combination of tools for the specific business problem.

No-code architecture means using tools like n8n, Make, Airtable, Google Sheets, Supabase interfaces, or visual automation builders to create workflows without traditional software development.

Code architecture means using custom development, Claude Code, Cursor, Python, JavaScript, TypeScript, APIs, custom plugins, or server-side logic to create a more controlled system.

Hybrid architecture means combining no-code, AI coding tools, databases, APIs, and human review to get the right balance of speed, reliability, control, and cost.

MWMS Definition

The MWMS Automation Architecture And Tool Selection Framework is:

Automation Brain’s standard for deciding which tools, platforms, hosting models, interfaces, databases, and development approaches should be used for each MWMS or client system based on business outcome, complexity, reliability, risk, cost, ownership, and long-term maintainability.

Scope

This framework applies to:

  • internal MWMS automations
  • AIBS client systems
  • AIOS productized systems
  • client dashboards
  • micro SaaS products
  • lead capture systems
  • outreach systems
  • review systems
  • content systems
  • RAG systems
  • voice agent systems
  • browser automation workflows
  • Supabase systems
  • WordPress systems
  • n8n workflows
  • Make scenarios
  • Airtable systems
  • Google Sheet automations
  • Lovable MVPs
  • Claude Code projects
  • local hosted automation systems
  • cloud hosted automation systems
  • API integrations
  • MCP tool access
  • custom coded tools
  • prototype systems
  • production systems
  • future AI Employee operational systems

This framework does not provide step-by-step development instructions.

It governs decision-making before development begins.

Core Principle

The core principle is:

Choose the simplest architecture that can safely, reliably, and profitably deliver the required outcome.

Simple does not always mean basic.

Simple means:

  • fewer moving parts
  • clear ownership
  • clear data flow
  • low failure risk
  • easy debugging
  • appropriate security
  • manageable cost
  • user-friendly interface
  • supportable by the MWMS team
  • aligned with the business goal

Complex architecture is allowed only when the problem genuinely requires it.

Rule

Do not add technical complexity unless it creates measurable business value or reduces meaningful risk.

The MWMS Automation Architecture Decision Model

Every MWMS automation architecture decision should be evaluated across twelve layers:

  1. Business Outcome Layer
  2. User And Operator Layer
  3. Data Source Layer
  4. Workflow Complexity Layer
  5. Tool Fit Layer
  6. Interface Layer
  7. Database Layer
  8. AI Model And Prompt Layer
  9. Hosting And Infrastructure Layer
  10. Security And Compliance Layer
  11. Cost And Maintenance Layer
  12. Scale And Upgrade Layer

1. Business Outcome Layer

Every tool decision begins with the business outcome.

Business Outcome Questions

Ask:

  • What problem is being solved?
  • What business result should improve?
  • Is the goal to save time?
  • Is the goal to make money?
  • Is the goal to reduce risk?
  • Is the goal to improve follow-up?
  • Is the goal to improve reporting?
  • Is the goal to improve decision-making?
  • Is the goal to improve customer experience?
  • Is the goal to create a sellable product?
  • Is the goal internal productivity or client delivery?
  • How will success be measured?

Outcome Types

Common MWMS outcomes include:

  • faster lead response
  • better client diagnosis
  • fewer missed leads
  • better content production
  • better reporting
  • better customer support
  • better review collection
  • cleaner data
  • better sales follow-up
  • reduced manual work
  • higher conversion
  • stronger client visibility
  • more reliable operations

Rule

If the outcome is unclear, do not choose a tool yet.

2. User And Operator Layer

A system must fit the people who use it and maintain it.

User Types

Users may include:

  • Martyn
  • M
  • future MWMS employees
  • client business owners
  • client staff
  • sales teams
  • content operators
  • support staff
  • local business owners
  • agency partners
  • consultants
  • internal AI Employees
  • external customers

Operator Questions

Ask:

  • Who uses the system?
  • Who maintains the system?
  • Who fixes it when it breaks?
  • Who approves outputs?
  • Who sees the dashboard?
  • Who owns the data?
  • Who is responsible for support?
  • Is the user technical?
  • Does the user need a simple frontend?
  • Can the user tolerate tool complexity?
  • Does M need to be involved?
  • Can this be managed manually first?

Rule

A tool is only suitable if the users and operators can realistically use, understand, and maintain it.

3. Data Source Layer

Architecture depends heavily on the data source.

Data Source Types

Sources may include:

  • web forms
  • Google Sheets
  • Airtable
  • Supabase
  • WordPress database
  • Google Drive
  • Gmail
  • CRM
  • GoHighLevel
  • YouTube
  • RSS feeds
  • websites
  • PDFs
  • call transcripts
  • voice agent logs
  • chat history
  • customer reviews
  • public web pages
  • private client systems
  • APIs
  • uploaded files
  • manual input
  • browser-extracted data

Data Source Questions

Ask:

  • Where does the data come from?
  • Is it public or private?
  • Is it structured or unstructured?
  • Is it reliable?
  • Is it current?
  • Is access approved?
  • Is an API available?
  • Is browser automation required?
  • Is the data sensitive?
  • Does it need storage?
  • Does it need retrieval later?
  • Does it need deletion?
  • Does it need source tracking?

Rule

Data access method should be chosen before automation tool choice.

4. Workflow Complexity Layer

Some workflows are simple. Others are complex.

The tool must match the complexity.

Simple Workflow Examples

Simple workflows include:

  • form submission to email
  • spreadsheet row to AI summary
  • RSS feed to draft content
  • completed job to review request
  • new lead to CRM record
  • uploaded file to folder move

These may fit:

  • Make
  • n8n
  • Zapier
  • Airtable automation
  • Google Apps Script
  • simple WordPress logic

Complex Workflow Examples

Complex workflows include:

  • multi-step client intelligence reports
  • AI agents with multiple tools
  • RAG systems
  • voice agents with fallback logic
  • browser automation with session handling
  • paid micro SaaS products
  • client portals
  • user access control
  • subscription logic
  • multi-tenant systems
  • complex approval workflows

These may require:

  • n8n
  • Supabase
  • custom code
  • Claude Code
  • WordPress plugin logic
  • backend functions
  • proper database schema
  • dedicated QA
  • human review workflows

Rule

Workflow complexity determines whether no-code is enough or proper development is required.

5. Tool Fit Layer

Each tool has a role.

MWMS must not confuse the role of each tool.

n8n

Best for:

  • complex workflows
  • self-hosted automation
  • API-heavy processes
  • AI agent workflows
  • reusable workflows
  • technical operators
  • internal MWMS systems
  • more control than Make

Weaknesses:

  • steeper learning curve
  • can become messy
  • requires good naming and structure
  • needs hosting or cloud cost
  • requires technical discipline

Use n8n when:

  • workflow complexity is medium to high
  • API control matters
  • ownership matters
  • long-term maintainability matters
  • MWMS wants more control
  • client data flow needs structure

Make

Best for:

  • fast visual automation
  • simple to medium workflows
  • quick client demos
  • simpler SaaS integrations
  • non-technical visibility
  • rapid prototyping

Weaknesses:

  • can become fragile
  • scenarios can sprawl
  • costs can rise
  • less flexible for advanced architecture
  • harder for complex agent systems

Use Make when:

  • speed matters
  • workflow is simple
  • integration support is strong
  • client can understand the scenario
  • fast proof of concept is needed

Zapier

Best for:

  • very simple integrations
  • common SaaS connections
  • non-technical users
  • fast business workflows

Weaknesses:

  • expensive at scale
  • limited for complex systems
  • less ideal for MWMS deep architecture

Use Zapier when:

  • client already uses it
  • workflow is simple
  • speed matters more than control

Claude Code

Best for:

  • custom app development
  • structured code projects
  • moving beyond no-code
  • building reusable logic
  • repairing or extending code
  • controlled development
  • developer-assisted systems

Weaknesses:

  • can create risk if unmanaged
  • needs version control
  • needs testing
  • not for casual copy-paste operation
  • may create hidden technical debt

Use Claude Code when:

  • no-code is no longer enough
  • custom logic is needed
  • proper files and versioning are required
  • the project is moving toward production

Lovable

Best for:

  • quick MVPs
  • client-facing prototypes
  • simple web apps
  • interfaces over automations
  • dashboards
  • proof of value
  • quick product demos
  • early micro SaaS prototypes

Weaknesses:

  • can create fragile prototypes
  • may require proper dev later
  • can burn credits through debugging
  • not ideal for complex production systems without review
  • requires careful backend integration

Use Lovable when:

  • the interface matters
  • a quick demo is valuable
  • user experience needs to be visible
  • a client-facing product needs a first version

Supabase

Best for:

  • structured database
  • authentication
  • vector storage
  • app backend
  • user records
  • chat history
  • secure data layer
  • micro SaaS infrastructure
  • client memory systems

Weaknesses:

  • more technical than Airtable
  • security must be handled carefully
  • service role keys are sensitive
  • poor schema design creates problems

Use Supabase when:

  • database structure matters
  • user authentication is needed
  • app backend is needed
  • RAG or vector storage is needed
  • MWMS needs a more serious system than a spreadsheet

Airtable

Best for:

  • flexible data organization
  • quick dashboards
  • content libraries
  • manual review queues
  • lightweight client systems
  • prototype databases
  • non-technical operations

Weaknesses:

  • not always ideal for production apps
  • permissions can become complex
  • API limits may matter
  • not ideal for sensitive or high-scale systems

Use Airtable when:

  • visibility matters
  • data is semi-structured
  • manual review is needed
  • quick operational interfaces are useful

Google Sheets

Best for:

  • simple logs
  • early testing
  • manual workflows
  • low-cost prototypes
  • client-visible simple data
  • export/import workflows

Weaknesses:

  • weak permissions
  • poor production architecture
  • can become messy
  • not ideal for sensitive systems
  • unreliable as core app backend

Use Google Sheets when:

  • the system is early-stage
  • manual review is required
  • data volume is low
  • simplicity matters more than scale

Browser Automation Tools

Examples:

  • Airtop
  • Axiom
  • browser agents
  • web automation agents

Best for:

  • websites with no useful API
  • form filling
  • controlled scraping
  • visual browser tasks
  • human-like navigation
  • short-term workflow bridging

Weaknesses:

  • fragile
  • platform terms risk
  • account ban risk
  • session issues
  • authentication risk
  • expensive at scale
  • must be monitored

Use browser automation only when:

  • no API exists
  • permission is clear
  • risk is reviewed
  • workflow is bounded
  • human review is possible
  • platform terms are considered

MCP

Best for:

  • flexible tool access
  • AI tool discovery
  • Claude or ChatGPT connected to external capabilities
  • exploratory tool use
  • advanced agent workflows

Weaknesses:

  • reliability concerns
  • harder to predict
  • security risk
  • tool misuse risk
  • not always production-safe
  • can be slower than direct workflow building

Use MCP when:

  • flexible tool access matters
  • the task is exploratory
  • strict deterministic outputs are not required
  • security and permissions are controlled

Direct API

Best for:

  • reliable production workflows
  • predictable data exchange
  • secure integrations
  • scalable systems
  • clean logging
  • better error handling

Weaknesses:

  • requires technical setup
  • requires documentation reading
  • API changes can break workflows
  • credentials must be managed

Use direct APIs when:

  • reliability matters
  • the platform provides an API
  • volume is meaningful
  • automation needs to scale
  • browser automation would be risky

Local Hosting

Best for:

  • privacy-sensitive systems
  • local data control
  • specific client security requirements
  • testing local AI or local n8n
  • controlled environments

Weaknesses:

  • computer must stay on
  • security burden increases
  • uptime responsibility increases
  • troubleshooting burden increases
  • not always worth the cost savings

Use local hosting when:

  • privacy or client requirement justifies it
  • the operator understands the maintenance burden
  • downtime is acceptable or managed
  • local control is more important than convenience

Cloud Hosting

Best for:

  • availability
  • client-facing systems
  • production systems
  • remote access
  • stable automation
  • team access
  • scalable infrastructure

Weaknesses:

  • monthly cost
  • data hosted externally
  • security configuration required
  • vendor dependency

Use cloud hosting when:

  • uptime matters
  • remote access matters
  • client-facing systems are involved
  • system must run without Martyn’s PC on

6. Interface Layer

The interface changes perceived value.

An automation hidden in a backend tool may work, but a proper interface makes it easier to sell, use, and support.

Interface Options

Use:

  • Google Form
  • Tally
  • Typeform
  • Airtable Interface
  • Google Sheet
  • WordPress page
  • Lovable web app
  • Supabase app
  • custom dashboard
  • client portal
  • Chrome extension
  • WhatsApp assistant
  • Telegram bot
  • voice agent
  • email interface
  • Brain Room style interface

Interface Questions

Ask:

  • Does the user need to see the system?
  • Does the user need to input data?
  • Does the user need a dashboard?
  • Does the user need approval buttons?
  • Does the system need to look professional?
  • Is this for internal use only?
  • Is this a client demo?
  • Is this a paid product?
  • Does perceived value matter?
  • Does UX reduce support burden?

Rule

Client-facing systems usually need a better interface than internal workflows.

7. Database Layer

Database choice determines system reliability and intelligence.

Database Decision Questions

Ask:

  • Is data temporary or long term?
  • Does data need relationships?
  • Does data need search?
  • Does data need semantic retrieval?
  • Does data need user accounts?
  • Does data need permissions?
  • Does data need audit logs?
  • Does data need source tracking?
  • Does data need deletion?
  • Does data need dashboard reporting?
  • Is it sensitive?
  • Is it client-specific?
  • Is it product data?

Database Selection Guide

Use Google Sheets when:

  • the system is simple
  • data volume is low
  • manual review is needed
  • the workflow is temporary

Use Airtable when:

  • visual data management matters
  • content or review workflows need status fields
  • non-technical users need visibility
  • a lightweight database is enough

Use Supabase when:

  • user authentication is needed
  • vector search is needed
  • app backend is needed
  • serious database structure is required
  • client data separation matters
  • future productization matters

Use WordPress database when:

  • the system lives inside a WordPress plugin
  • admin UI is tied to WordPress
  • MCR or Brain pages are involved
  • WordPress is the operational environment

Use vector database when:

  • semantic retrieval is needed
  • documents need to be searched by meaning
  • RAG is required
  • business memory is required

Rule

Do not use a spreadsheet as a production database unless the risk and scale are low.

8. AI Model And Prompt Layer

AI tools must match the task.

AI Decision Questions

Ask:

  • Does this task need AI?
  • Is AI generating content?
  • Is AI classifying data?
  • Is AI extracting fields?
  • Is AI answering from memory?
  • Is AI making recommendations?
  • Is AI using tools?
  • Does the output need JSON?
  • Does the output need human review?
  • Does the output need source references?
  • What model quality is required?
  • What model cost is acceptable?

AI Use Types

Use simple models for:

  • classification
  • short summaries
  • formatting
  • routing
  • simple extraction

Use stronger models for:

  • complex reasoning
  • client reports
  • strategy recommendations
  • sales diagnosis
  • legal or compliance-adjacent review
  • multi-source synthesis

Use structured outputs when:

  • data must enter a workflow
  • JSON is required
  • fields must be clean
  • API payloads must be valid
  • automation cannot tolerate messy text

Use human review when:

  • the output affects clients
  • the output affects sales
  • the output affects compliance
  • the output affects public content
  • the output affects reputation

Rule

AI output must be structured when automation depends on it.

9. Hosting And Infrastructure Layer

Hosting choice affects uptime, privacy, cost, and maintenance.

Hosting Options

Use:

  • local computer
  • VPS
  • RackNerd
  • managed n8n cloud
  • Make cloud
  • Supabase cloud
  • WordPress hosting
  • client-owned hosting
  • cloud app hosting
  • hybrid local and cloud

Hosting Questions

Ask:

  • Does this need to run all day?
  • Can it stop when the computer is off?
  • Is this client-facing?
  • Is uptime important?
  • Is privacy important?
  • Is cost important?
  • Who maintains it?
  • Who has access?
  • Who backs it up?
  • What happens if it fails?
  • Does M need to support it?
  • Does the client require local control?

Rule

Local hosting is not automatically better. Cloud hosting is not automatically safer. Choose based on risk, uptime, privacy, and maintenance.

10. Security And Compliance Layer

Every architecture decision must include risk review.

Security Questions

Ask:

  • What credentials are used?
  • Where are API keys stored?
  • Is a service role key involved?
  • Is a webhook exposed?
  • Is authentication required?
  • Is user data stored?
  • Is client data stored?
  • Is browser automation logging in?
  • Is scraping involved?
  • Are platform terms affected?
  • Is personal data processed?
  • Is sensitive data processed?
  • Is human review required?
  • Is deletion possible?
  • Is access revocation possible?

Risk Areas

Review:

  • webhook exposure
  • API key leakage
  • browser session leakage
  • account ban risk
  • client data mixing
  • unapproved data collection
  • insecure frontend secrets
  • unsafe Supabase permissions
  • local machine vulnerability
  • MCP tool misuse
  • AI hallucination
  • direct autoposting
  • automated outreach
  • voice agent disclosure
  • customer privacy

Rule

Architecture is not approved until security and compliance risks are visible.

11. Cost And Maintenance Layer

A system must be affordable and maintainable.

Cost Sources

Costs may include:

  • n8n hosting
  • Make operations
  • Supabase usage
  • OpenAI or Claude tokens
  • voice agent minutes
  • browser automation compute
  • storage
  • email sending
  • SMS
  • API calls
  • image generation
  • video generation
  • developer time
  • support time
  • client onboarding
  • debugging time
  • tool subscriptions

Maintenance Questions

Ask:

  • Who fixes it?
  • How often will it break?
  • How easy is debugging?
  • Are logs available?
  • Are errors visible?
  • Are retries controlled?
  • Are costs monitored?
  • Is there a fallback?
  • Does it need documentation?
  • Can the client support it?
  • Can MWMS support it?
  • Is M required?

Rule

A system that is cheap to build but expensive to support is not cheap.

12. Scale And Upgrade Layer

Not every prototype should become production.

Scale Questions

Ask:

  • Is the workflow proven manually?
  • Has the prototype worked with real data?
  • Has a user tested it?
  • Has it generated value?
  • Is usage predictable?
  • Is cost per run known?
  • Is failure rate acceptable?
  • Are security controls strong enough?
  • Is the interface usable?
  • Is the backend strong enough?
  • Should this be rebuilt properly?
  • Should this stay as a no-code system?
  • Should this become a product?

Upgrade Paths

A system may move from:

  • manual workflow to Google Sheet
  • Google Sheet to Airtable
  • Airtable to Supabase
  • Make to n8n
  • prototype to WordPress plugin
  • Lovable MVP to custom app
  • single workflow to productized AIOS module
  • internal tool to micro SaaS
  • simple automation to client operating system

Rule

Prototype quickly, but do not pretend prototypes are production systems.

Architecture Decision Scorecard

Before choosing architecture, score the system out of 100.

Score Categories

Business Outcome Clarity: 10
User Fit: 10
Data Source Clarity: 10
Workflow Complexity Fit: 10
Tool Fit: 10
Interface Need: 10
Database Fit: 10
Security And Compliance Fit: 10
Cost And Maintenance Fit: 10
Scale Path Clarity: 10

Interpretation

85–100: Architecture is strong and ready to proceed
70–84: Good architecture with minor risks to resolve
55–69: Prototype only or needs redesign before production
40–54: Too risky or unclear
Below 40: Do not build yet

Rule

A system should not move to production unless architecture score is strong.

MWMS Tool Selection Matrix

Use Make When

Use Make when:

  • speed matters
  • workflow is simple
  • integration is straightforward
  • a visual demo helps
  • client understands the platform
  • low technical depth is needed
  • fast testing is more important than deep control

Avoid Make when:

  • workflow is highly complex
  • user access control is needed
  • advanced database logic is required
  • long-term MWMS infrastructure is needed
  • heavy AI agent logic is required

Use n8n When

Use n8n when:

  • workflow complexity is higher
  • API logic matters
  • AI agents are involved
  • reusable internal systems are needed
  • self-hosting matters
  • MWMS wants more control
  • custom error handling is needed
  • systems must connect across many Brains

Avoid n8n when:

  • a simple form-to-email will do
  • user interface is the main need
  • client cannot support it
  • M’s development work would be disrupted

Use Lovable When

Use Lovable when:

  • a fast frontend is needed
  • a demo must look good
  • client perception matters
  • an MVP needs to be tested
  • a micro SaaS idea needs quick validation
  • dashboards or portals are useful

Avoid Lovable when:

  • production reliability is required immediately
  • complex security is required
  • user data is sensitive and not reviewed
  • the system needs long-term custom architecture
  • no one will test or maintain the app

Use Claude Code When

Use Claude Code when:

  • no-code is too limited
  • custom logic is required
  • file-based development is needed
  • a real codebase must be created
  • GitHub versioning matters
  • M or a developer can review and maintain it

Avoid Claude Code when:

  • the workflow can be done safely in no-code
  • no one can review the code
  • the task is vague
  • the system is not worth technical debt

Use Supabase When

Use Supabase when:

  • authentication is needed
  • app backend is needed
  • vector storage is needed
  • structured records matter
  • user access matters
  • chat history matters
  • source retention matters
  • productization is likely

Avoid Supabase when:

  • simple spreadsheet storage is enough
  • no one understands the schema
  • security settings are unclear
  • service role keys would be exposed

Use Airtable When

Use Airtable when:

  • visibility matters
  • operators need a simple table interface
  • status workflows matter
  • content or asset management is needed
  • early client systems need structure

Avoid Airtable when:

  • sensitive data needs tighter control
  • high-scale backend logic is required
  • authentication and permissions are complex

Use Google Sheets When

Use Google Sheets when:

  • the system is early
  • data is simple
  • manual review matters
  • speed and cost matter
  • prototype logging is enough

Avoid Google Sheets when:

  • the data is sensitive
  • records are complex
  • access control matters
  • production reliability matters

Use Browser Automation When

Use browser automation when:

  • no API exists
  • the task is browser-based
  • form filling is required
  • visual navigation matters
  • a controlled workflow can be tested
  • terms and risk are reviewed

Avoid browser automation when:

  • direct API exists
  • platform terms prohibit automation
  • login credentials are sensitive
  • accounts may be banned
  • the workflow is mission-critical
  • high reliability is required

Use MCP When

Use MCP when:

  • flexible AI tool access is useful
  • the task is exploratory
  • tools need to be discovered dynamically
  • operator supervision exists
  • security boundaries are clear

Avoid MCP when:

  • deterministic output is required
  • production reliability matters
  • tool misuse would be costly
  • strict compliance is required
  • a simple workflow would be safer

Use Direct API When

Use direct API when:

  • platform supports it
  • production reliability matters
  • data exchange must be predictable
  • workflow must scale
  • logging matters
  • security can be controlled

Avoid direct API when:

  • API access is not available
  • setup cost outweighs value
  • the workflow is temporary
  • manual export is enough

No Code Versus Code Decision Standard

Use No Code When

Use no-code when:

  • speed matters
  • workflow is simple to medium
  • changes are frequent
  • visual maintainability matters
  • client needs visibility
  • prototype stage is active
  • business value is not yet proven

Use Code When

Use code when:

  • reliability matters
  • security matters
  • scale matters
  • user access matters
  • custom logic matters
  • no-code becomes fragile
  • system is productized
  • system becomes client-facing and mission-critical
  • data model is complex

Use Hybrid When

Use hybrid when:

  • no-code handles orchestration
  • code handles custom logic
  • Supabase handles data
  • Lovable handles interface
  • WordPress handles operational admin
  • AI handles drafting or reasoning
  • humans handle approval and governance

Rule

MWMS should not be ideological about no-code or code. The correct answer is the architecture that fits the job.

Prototype Versus Production Standard

Prototype System

A prototype may use:

  • Google Sheets
  • Airtable
  • Make
  • Lovable
  • manual approvals
  • test data
  • limited users
  • temporary credentials
  • low-risk workflows

Prototype goal:

  • prove value
  • test user behavior
  • validate workflow
  • understand data requirements
  • find failure points

Production System

A production system should include:

  • secure credentials
  • access control
  • stable database
  • logging
  • error handling
  • backups
  • documentation
  • human review where needed
  • usage monitoring
  • cost monitoring
  • support plan
  • compliance review
  • clear owner

Rule

Prototype tools are allowed, but production claims require production discipline.

Client Facing Versus Internal Tool Standard

Internal Tool

Internal tools can be rougher if:

  • only MWMS uses them
  • data risk is low
  • outputs are reviewed
  • manual correction is acceptable
  • failure does not harm clients

Client Facing Tool

Client-facing tools need:

  • better interface
  • stronger reliability
  • clearer onboarding
  • stronger permissions
  • support path
  • error handling
  • documentation
  • privacy review
  • cost review
  • rollback plan

Rule

Never treat a client-facing system like an internal experiment.

Dashboard First Architecture Rule

When selling AIBS systems, dashboards often increase perceived and actual value.

A dashboard helps show:

  • baseline
  • improvement
  • activity
  • bottlenecks
  • lead flow
  • review flow
  • sales progress
  • customer issues
  • automation output
  • ROI signals

Dashboard Questions

Ask:

  • What number matters?
  • What baseline exists?
  • What should improve?
  • What does the client need to see?
  • What does MWMS need to monitor?
  • What actions should follow from the dashboard?
  • What proves value?

Rule

For client systems, if value is measurable, dashboard visibility should be considered early.

Human Strategy Layer

The tool stack is not the whole system.

MWMS architecture must include human strategy.

Human Strategy Questions

Ask:

  • What decision does this system support?
  • What human action follows the automation?
  • Who approves important outputs?
  • Who responds to exceptions?
  • Who owns improvements?
  • Who reviews reports?
  • Who handles unhappy customers?
  • Who updates the system?
  • Who decides whether to scale?

Rule

Automation without human strategy becomes brittle and disconnected from business value.

Architecture Drift Protection

This framework protects MWMS from:

  • chasing shiny tools
  • using n8n for everything
  • using Lovable for everything
  • using Claude Code too early
  • using no-code when code is required
  • using code when no-code is enough
  • using browser automation when an API exists
  • using MCP when schema is safer
  • building client-facing prototypes with no support plan
  • letting tool demos become business strategy
  • creating systems M cannot maintain
  • ignoring data structure
  • ignoring cost per run
  • ignoring access control
  • ignoring client privacy
  • ignoring dashboard visibility
  • confusing impressive workflows with valuable outcomes

Architecture Drift Signals

Watch for:

  • “This tool is hot right now.”
  • “Everyone is using this.”
  • “Let’s use it because the course used it.”
  • “We can build the whole thing in one prompt.”
  • “No need to map the workflow first.”
  • “We can fix security later.”
  • “Let’s scrape it.”
  • “Use browser automation instead of checking for an API.”
  • “M can clean it up later.”
  • “The client will not care how it works.”
  • “The demo worked once, so it is ready.”
  • “Let’s skip the dashboard.”
  • “Let’s go straight to production.”
  • “We do not need human review.”

Rule

When these drift signals appear, stop and apply the Architecture Decision Scorecard.

MWMS Architecture Selection Workflow

Use this workflow before starting a build.

Step 1: Define The Business Outcome

Write:

  • problem
  • user
  • desired result
  • success metric
  • risk level

Step 2: Map The Workflow

Write:

  • trigger
  • input
  • data source
  • process
  • AI step
  • output
  • storage
  • approval
  • delivery
  • reporting

Step 3: Identify Risk

Review:

  • privacy
  • compliance
  • security
  • tool access
  • credentials
  • client data
  • platform terms
  • hallucination
  • user harm
  • cost

Step 4: Choose Tool Stack

Choose:

  • automation engine
  • database
  • interface
  • AI model
  • hosting
  • reporting layer
  • approval layer

Step 5: Decide Prototype Or Production

Decide:

  • manual first
  • prototype
  • internal tool
  • client pilot
  • production system
  • productized offer

Step 6: Define Maintenance

Define:

  • owner
  • support path
  • logs
  • error handling
  • documentation
  • change control
  • upgrade path

Step 7: Score The Architecture

Use the scorecard before build.

Rule

Architecture must be written before implementation.

Example Architecture Decisions

Example 1: Simple Lead Form To Email

Best architecture:

  • Tally or WordPress form
  • Make or n8n
  • Gmail or CRM
  • Google Sheet log

Do not use:

  • full Supabase app
  • Lovable portal
  • Claude Code build
  • MCP

Reason:

The workflow is simple.

Example 2: AIBS Client Diagnostic Report

Best architecture:

  • structured intake form
  • Supabase or Airtable
  • AI report generation
  • human review
  • PDF or dashboard output
  • CRM follow-up

Possible tools:

  • n8n
  • Supabase
  • Airtable
  • OpenAI or Claude
  • WordPress or Lovable frontend

Reason:

This requires structured data, AI synthesis, review, and sales follow-up.

Example 3: Local Review Automation

Best architecture:

  • customer completion trigger
  • SMS or email system
  • feedback form
  • routing logic
  • dashboard
  • manager alerts

Possible tools:

  • Make or n8n
  • Airtable or Supabase
  • Twilio or email tool
  • dashboard interface

Reason:

The workflow is commercial, measurable, and client-facing.

Example 4: Client Knowledge Base Chatbot

Best architecture:

  • approved document intake
  • embeddings
  • vector storage
  • retrieval
  • source tracking
  • chat interface
  • deletion process

Possible tools:

  • Supabase vector
  • n8n
  • OpenAI or Claude
  • WordPress or Lovable frontend

Reason:

This requires memory, retrieval, source freshness, and privacy controls.

Example 5: Browser Form Filling

Best architecture:

  • direct API if available
  • browser automation only if API unavailable
  • limited session
  • risk review
  • logging
  • human verification

Possible tools:

  • Airtop
  • Axiom
  • n8n
  • manual review

Reason:

Browser automation is powerful but risky.

Example 6: Micro SaaS Tool

Best architecture:

  • frontend
  • authentication
  • payment
  • access control
  • backend workflow
  • database
  • usage limits
  • support path

Possible tools:

  • Lovable prototype
  • Supabase backend
  • Stripe
  • n8n
  • custom code later

Reason:

Paid products need access control, cost control, and user management.

Application To Automation Brain

Automation Brain owns this framework.

Automation Brain should use it to:

  • choose correct automation platforms
  • avoid tool drift
  • define workflow architecture
  • protect maintainability
  • document build decisions
  • prevent fragile systems
  • decide no-code versus code
  • decide API versus browser automation
  • decide prototype versus production

Automation Brain Rule

Automation Brain must solve workflow problems, not collect tools.

Application To HeadOffice Brain

HeadOffice Brain should use this framework to approve major architecture choices.

HeadOffice should ask:

  • does this support MWMS strategy?
  • is this the right tool?
  • does this create unnecessary cost?
  • does this burden M?
  • does this improve client value?
  • does this create risk?
  • does this need a dashboard?
  • should this be manual first?
  • should this become a product?

HeadOffice Rule

HeadOffice approves architecture based on strategic value, not technical excitement.

Application To AIBS Brain

AIBS Brain should use this framework before recommending client systems.

AIBS should ask:

  • what is the client problem?
  • what is the business outcome?
  • what architecture fits the client?
  • what does the client need to see?
  • what can be supported?
  • what can be measured?
  • what creates the first win?
  • what should not be automated?

AIBS Rule

AIBS architecture must follow business diagnosis.

Application To Product Brain

Product Brain should use this framework when deciding whether an automation becomes a product.

Product Brain should ask:

  • does this need a frontend?
  • does this need authentication?
  • does this need payment?
  • does this need usage limits?
  • does this need proper backend?
  • does this need prototype testing?
  • does this need custom code?

Product Brain Rule

Product architecture must be stronger than demo architecture.

Application To Data Brain

Data Brain should use this framework to choose storage, schema, and retrieval systems.

Data Brain should decide:

  • spreadsheet
  • Airtable
  • Supabase
  • vector storage
  • WordPress database
  • temporary memory
  • long-term memory
  • audit logs
  • source metadata

Data Brain Rule

Data architecture must match the future value and risk of the data.

Application To Compliance And Risk Brain

Compliance and Risk Brain should review tool architecture when systems involve:

  • client data
  • customer data
  • browser automation
  • scraping
  • MCP
  • API keys
  • Supabase service roles
  • local hosting
  • voice agents
  • outreach
  • review automation
  • public posting
  • paid products

Compliance Rule

Risk review is part of architecture, not an afterthought.

Application To Finance Brain

Finance Brain should review architecture for cost.

Finance Brain should track:

  • tool subscriptions
  • AI token cost
  • browser automation compute
  • voice minute cost
  • hosting cost
  • storage cost
  • support cost
  • cost per run
  • margin impact
  • product profitability

Finance Rule

Tool choice must be economically sustainable.

Deferred Update And Parking Lot Section

This page creates later update needs.

Later Update 1: MWMS AI Automation Security And Risk Checklist

Add:

  • tool selection risk review
  • browser automation risk
  • MCP risk
  • local hosting risk
  • Supabase service role key caution
  • direct API versus browser automation decision
  • prototype versus production security checklist

Later Update 2: MWMS AI Usage And Cost Visibility Standard

Add:

  • tool stack cost mapping
  • cost per workflow run
  • cost per AI call
  • browser automation compute cost
  • voice agent minute cost
  • Lovable prototype cost
  • Make versus n8n operation cost
  • production cost review

Later Update 3: MWMS Productized AIOS Service Packaging And Scope Control Framework

Add:

  • architecture selection before packaging
  • prototype stack versus production stack
  • client-facing interface requirements
  • dashboard-first value display
  • tool support boundaries
  • no-code versus code scope boundary

Later Update 4: MWMS Micro SaaS Productization And Access Control Framework

Add:

  • tool selection before micro SaaS approval
  • Lovable MVP to production migration
  • Supabase backend fit
  • Stripe and access control architecture
  • prototype kill or upgrade decision

Later Update 5: MWMS Client Intelligence And Business Memory Automation Framework

Add:

  • architecture selection for memory systems
  • Supabase versus Airtable versus vector storage
  • RAG tool decision pathway
  • local versus cloud memory hosting
  • source security review

Later Update 6: MWMS AI Tool Access Browser Automation And MCP Governance Framework

Add:

  • tool access decision rules
  • schema versus MCP
  • API versus browser automation
  • platform risk decision tree
  • session and credential handling standards

Later Update 7: MWMS AI App Builder And Productized Interface Framework

Add:

  • Lovable as interface prototype
  • Claude Code as upgrade path
  • Supabase as app backend
  • GitHub as code control
  • client-facing prototype rules
  • when to rebuild properly

Later Update 8: MWMS AIBS Business Diagnostic And Opportunity Discovery Framework

Add:

  • architecture recommendation section
  • audit-to-architecture pathway
  • business problem to tool stack mapping
  • dashboard-first system recommendation

Future AI Employee Ideas

These AI Employee ideas are parked candidates only.

Automation Architecture Advisor

Primary Brain: Automation Brain / HeadOffice Brain
Status: Parked Candidate
Purpose: Chooses the best tool stack for each MWMS or client system based on outcome, complexity, risk, cost, and maintainability.

No Code Versus Code Analyst

Primary Brain: Automation Brain
Status: Parked Candidate
Purpose: Decides whether a workflow should remain no-code, move to custom code, or use a hybrid approach.

Tool Stack Risk Reviewer

Primary Brain: Compliance Brain / Risk Brain
Status: Parked Candidate
Purpose: Reviews automation architecture for security, platform, credential, privacy, and reliability risks.

Prototype To Production Advisor

Primary Brain: Product Brain / Automation Brain
Status: Parked Candidate
Purpose: Decides when a Lovable, Make, Airtable, or Google Sheet prototype should remain as is, be improved, or be rebuilt properly.

Automation Cost Analyst

Primary Brain: Finance Brain
Status: Parked Candidate
Purpose: Calculates tool costs, AI token costs, hosting costs, usage costs, and support costs for automation systems.

Client System Interface Strategist

Primary Brain: UX Brain / Product Brain
Status: Parked Candidate
Purpose: Decides when client systems need dashboards, portals, forms, app interfaces, or simple backend workflows.

Data Architecture Mapper

Primary Brain: Data Brain
Status: Parked Candidate
Purpose: Chooses between Google Sheets, Airtable, Supabase, WordPress database, vector storage, and custom database architecture.

Hosting Decision Advisor

Primary Brain: Automation Brain / Risk Brain
Status: Parked Candidate
Purpose: Decides between local hosting, VPS hosting, managed cloud tools, client-owned infrastructure, and hybrid hosting.

Drift Protection

This framework protects MWMS from:

  • tool hype
  • automation spaghetti
  • unclear ownership
  • fragile demos
  • overbuilt prototypes
  • underbuilt production systems
  • unnecessary Claude Code use
  • unnecessary Lovable apps
  • unnecessary browser automation
  • ungoverned MCP usage
  • weak database decisions
  • spreadsheet overuse
  • client-facing systems with no support plan
  • ignoring dashboard value
  • ignoring cost
  • ignoring security
  • dumping maintenance onto M
  • confusing “can build” with “should build”

Strategic Summary

The AI Native Entrepreneur Architecture And Tool Decision Block showed many tools and build paths.

The important MWMS lesson is not that one tool wins.

The important lesson is that every tool has a role.

n8n, Make, Claude Code, Lovable, Supabase, Airtable, Google Sheets, browser automation, MCP, APIs, local hosting, and cloud hosting can all be useful.

But they are useful only when matched to the correct problem.

The strategic upgrade for MWMS is:

Build the right architecture for the business outcome.

This framework gives MWMS a disciplined method for choosing tools, avoiding bloat, protecting M’s development time, supporting AIBS client delivery, and preventing shallow AI automation thinking.

MWMS should not be known for building automations.

MWMS should be known for diagnosing business problems and building the right AI operating systems to solve them.

Final Standard

The MWMS final standard is:

No MWMS automation, AIOS system, client workflow, productized tool, or internal build should begin until the business outcome, user, data source, workflow complexity, tool fit, interface need, database need, AI role, hosting model, security risk, cost, maintenance owner, and scale path have been considered.

A valid MWMS automation architecture decision must define:

  • business problem
  • desired outcome
  • user
  • operator
  • data source
  • workflow steps
  • automation engine
  • interface
  • database
  • AI model
  • hosting
  • security risks
  • compliance risks
  • cost drivers
  • maintenance owner
  • logging
  • human review points
  • prototype or production status
  • upgrade path

That is the MWMS Automation Architecture And Tool Selection standard.

Change Log

Version: v1.0

Date: 2026-06-08
Author: HeadOffice

Change:
Created the MWMS Automation Architecture And Tool Selection Framework from the AI Automations by Jack AI Native Entrepreneur Architecture And Tool Decision Block.

Captured the strongest lessons from practical and strategic workshop material involving:

  • Do I Even Need n8n Anymore
  • Framework Workshop No Code vs Code
  • local n8n hosting
  • Claude Code introduction
  • Lovable to Claude Code integration
  • browser automation
  • ChatGPT and Claude connected to n8n
  • MCP tool access
  • Supabase backend direction
  • Make versus n8n considerations
  • no-code versus code decision-making
  • local versus cloud hosting trade-offs
  • tool fit versus business outcome thinking
  • five pillars operating system thinking

Defined the MWMS Automation Architecture Decision Model with twelve layers:

  1. Business Outcome Layer
  2. User And Operator Layer
  3. Data Source Layer
  4. Workflow Complexity Layer
  5. Tool Fit Layer
  6. Interface Layer
  7. Database Layer
  8. AI Model And Prompt Layer
  9. Hosting And Infrastructure Layer
  10. Security And Compliance Layer
  11. Cost And Maintenance Layer
  12. Scale And Upgrade Layer

Added key operating sections:

  • Architecture Decision Scorecard
  • MWMS Tool Selection Matrix
  • No Code Versus Code Decision Standard
  • Prototype Versus Production Standard
  • Client Facing Versus Internal Tool Standard
  • Dashboard First Architecture Rule
  • Human Strategy Layer
  • Architecture Drift Protection
  • MWMS Architecture Selection Workflow
  • Example Architecture Decisions
  • Deferred Update And Parking Lot Section
  • Future AI Employee Ideas

Mapped the framework across:

  • Automation Brain
  • HeadOffice Brain
  • AIBS Brain
  • Product Brain
  • Data Brain
  • Compliance Brain
  • Risk Brain
  • Sales Brain
  • UX Brain
  • Research Brain
  • Finance Brain
  • Experimentation Brain

Purpose of creation:
To establish a formal MWMS standard for choosing the correct automation, AI, database, interface, hosting, and development architecture based on business outcome, complexity, risk, cost, maintainability, and long-term MWMS strategy rather than tool hype.

END — MWMS AUTOMATION ARCHITECTURE AND TOOL SELECTION FRAMEWORK v1.0