Having spent over a decade building, scaling, and contributing to open-source business application ecosystems—including key leadership and community building around ERPNext—we have witnessed the immense power of open source to democratize business software. Open-source frameworks allow teams to rapidly prototype applications, automate complex workflows, and retain complete control over their digital infrastructure.

Yet, as open-source frameworks expand into large enterprises, regulated industries, and government organizations, severe friction points emerge. Traditional framework designs often force a choice between rapid initial development velocity and long-term architectural stability.

We built Framework M to eliminate that compromise. This is our story, our architectural manifesto, and our vision for enterprise-grade open source.

We have an exciting milestone to share: Framework M Software Foundation has officially been incorporated as a non-profit company (Company limited by shares under Section 8 of the Companies Act, 2013, India).

From day one, our goal for Framework M has been simple: Build once. Scale forever. Achieving that vision requires more than clean architecture, zero-touch provisioning, and type-safe DocTypes—it requires long-term stability, transparent governance, and true vendor neutrality.

Establishing the non-profit Foundation early lays the groundwork for that commitment.

As AI coding assistants and LLM pair programmers become central to daily software development, engineering teams face a new challenge: context fragmentation. Developers prompt AI agents with conflicting assumptions about framework APIs, missing model schemas, or outdated coding conventions.

In July 2026, we introduced the m skills command group in the Framework M Studio CLI, providing a standardized workflow to discover, pull, version-control, and manage LLM Skill Definitions across multiple repositories and custom namespaces directly within your workspace.

Managing user-uploaded files, media assets, and generated PDF invoices in modern cloud applications requires flexibility. Hardcoding file uploads to local disk directories makes horizontal scaling impossible, while hardcoding direct AWS S3 calls couples your codebase tightly to a single cloud provider.

Framework M solves asset management by routing all file upload streams through an abstract, pluggable Storage Adapter architecture.

Building complex enterprise user interfaces requires a delicate balance: core application shells must remain stable and secure, while domain plugins and custom UI extensions must be able to hook into form controllers, state lifecycle, and global navigation effortlessly.

In Framework M Desk (@framework-m/desk), we introduced the official React Shell Context API and consolidated Micro-Frontend (MFE) Plugin Contracts.

Generative AI agents and LLM pair programmers are rapidly changing how business applications are built, maintained, and operated. However, most traditional web frameworks treat AI as a superficial gimmick—adding simple chat widgets while forcing agents to guess database schemas, API parameters, and form layouts.

Framework M is engineered AI-first. Studio CLI (m docs export) provides five specialized machine schema exporters under ./docs/machine/: corpus.jsonl, core.jsonl, doctypes.jsonl, ui.jsonl, and openapi.jsonl.

Framework M has always been built on a Pure Hex (Ports & Adapters) architecture. Core domain logic and metadata engines are decoupled from specific web servers, databases, and UI implementations.

In July 2026, we formally published ADR-0016 to codify the Replaceable Batteries Pattern for shell integration so that AI coding assistants and machine knowledge exporters (corpus.jsonl, core.jsonl) index these rules explicitly, preventing AI agents from generating redundant auth, registration, or dashboard boilerplate.

Enterprise applications often face conflicting identity requirements. On one hand, security architects demand strict single sign-on (SSO), multi-factor authentication (MFA), and centralized session revocation via OpenID Connect (OIDC). On the other hand, operational teams require passwordless mobile app login flows, SMS gateway integrations, and deterministic data ownership handover when users leave an organization.

Framework M reconciles these needs with Pluggable Identity Self-Service, OIDC RP-Initiated Logout, core Domain Events, and Controller Ownership Transfer Hooks.

Business intelligence in traditional web frameworks is almost always an afterthought. Teams start by executing ad-hoc SQL queries, progress to building custom admin dashboards, and eventually hit a wall when users demand preset list filters, automated PDF/Excel email dispatches, and external BI tool integrations like Metabase or Apache Superset.

In Framework M, analytics and reporting are first-class, metadata-driven primitives. With our recent July updates, we introduced Saved Views, automated AutoReport background jobs, direct email queue delivery, and Shadow Table Resolvers that let external BI engines query dynamic DocType schema structures safely.

Most frameworks ask you to pick one database and hope you never need another. We built Framework M on the opposite assumption: your database is a deployment detail, not an architectural prison.

Today, the same integration suite that validates Framework M's core features also validates them against six relational databases — SQLite, PostgreSQL, MySQL, MariaDB, Oracle, and Microsoft SQL Server — on every merge request and every default-branch commit.

In enterprise environments, database choice is rarely a developer's preference—it is often a strict organizational mandate. Whether it is a legacy Oracle database, a standardized SQL Server (MSSQL) cluster, or a specialized MySQL configuration, frameworks that lock you into a single database engine are a non-starter.

When we designed Framework M, we focused heavily on providing out-of-the-box support for PostgreSQL and SQLite. For completely different databases (like MongoDB), we introduced the MX Adapter Extension Pattern, allowing developers to completely swap out repository and transaction protocols without forking the framework core.

Today, we are taking this composability a step further. We have refactored our standard SQLAlchemy database adapters to support the Hybrid MX Pattern, allowing developers to connect any official or unofficial SQLAlchemy-supported database engine to Framework M by subclassing standard components and overriding only the dialect-specific parts.

Think about your daily workflow in Google Workspace or Microsoft Azure. In the top-right corner, you click your profile picture and switch instantly between your personal account, your work account, and a client’s tenant—all without logging out.

Users have come to expect this seamless, multi-account profile experience in modern web applications. Yet, if you look at the product backlogs of most enterprise SaaS startups, you will find that multi-account profile switching is deprioritized to 'never.'

In this article, we’ll look at why this feature is so hard to build from scratch, how open-source identity providers like Zitadel are driving this requirement, and how Framework M makes supporting it as simple as flipping an environment variable flag.

Hierarchical data is everywhere in business applications—from organizational charts and product catalogs to tasks, nested comments, and ledger accounts. Yet, representing tree structures in a relational SQL database is a classic engineering trade-off between write performance, read complexity, and storage overhead.

In this article, we'll walk through the evolution of tree strategies in Framework M: how we moved from a Frappe-inspired Nested Set model to a pluggable Strategy Pattern supporting recursive CTEs, and how this architecture paves the way for specialized document and graph repositories.

In modern web development, background jobs and scheduled tasks are the backbone of asynchronous operations—handling everything from daily email reports to outbox processing and periodic data cleanups.

However, running scheduled tasks (cron jobs) reliably in a clustered, high-availability (HA) environment is a notoriously difficult problem. Traditionally, developers have had to choose between heavy distributed locking protocols or complex, stateful leader-election daemons.

WebAssembly (WASM) and browser-based runtimes like Pyodide are quietly redefining the boundaries of application portability. Running full-stack, enterprise-grade Python frameworks directly inside the browser—with zero server costs, instant boots, and offline-first capabilities—is no longer a theoretical exercise. It is reality.

But porting database-driven applications to the browser sandbox exposes a massive "productivity cliff" where traditional server-side tools break down. Among these, database schema migrations present one of the most stubborn hurdles.

Here is how we bypassed the typical runtime hacks to implement first-class, dual-mode migrations inside Framework M using clean, decoupled architecture.

WebAssembly (WASM) and browser-based runtimes like Pyodide are quietly rewriting the rules of application portability. Running python-based backends directly in the browser—with near-native speeds, zero server cost, and instant startup—is no longer a futuristic dream. It is here today.

But running enterprise-grade python frameworks in WASM comes with a major catch: C-extensions are a brick wall.

Recently, I decided to test the limits of Framework M's portability. My goal was simple: get our entire modular monolith booting directly inside the browser using Pyodide.

The result of that experiment taught me one of the most powerful, real-world lessons about the true beauty of clean, decoupled architecture.

Every modern cloud provider and SaaS company is trying to sell us the same story: your software must live in the cloud on Day 1. You need a Kubernetes cluster, a managed database subscription, a global CDN, and a four-digit hosting bill just to get started.

But let’s be honest: 90% of real-world businesses don't care about the cloud.

Why would a restaurant owner, a factory operator, or a local service provider spend a single second thinking about database connection pools or server maintenance? They are focusing 100% of their energy on physical operational challenges. The cloud is the absolute last thing on their minds.

Yet, the tech industry forces a single, dogmatic path: mandatory, lock-in cloud rent.

As engineers, our job isn't to build fragile sandcastles that require constant, expensive cloud maintenance to stay standing. We build digital castles that last for centuries.

To support these businesses from Day 1 with a zero-cost, zero-latency, zero-maintenance sovereign setup, we built Business Local—packaging our entire Monolith stack inside a native Tauri wrapper that runs fully offline.

But as we refined this architecture, a breathtaking new spectrum opened up. If you write your business domain logic once, why shouldn't you be able to run it anywhere across a seamless continuum—from a micro-minimalist IoT edge controller processing transient MQTT events, to a sovereign offline laptop, all the way to mega-scale hypervisor clusters in the cloud?

To unlock this absolute scaling sovereignty, we have shipped a major new architectural capability: 100% Stateless & Database-Free Boot Mode.

In our last post on Transparent UI Macroservices, we talked about the "what": breaking a monolithic frontend into independent, deployable units without breaking the user experience.

But as soon as you move from two services to ten, you hit a new wall: The Discovery Cliff.

How does the shell know where the finance service lives today? How does it find the inventory remote entry on a developer's machine versus a production Kubernetes cluster? And how do we do this without a 400-line configuration file that needs to be updated every time a port changes?

Today, we’re introducing the Discovery Oracle.

Two weeks ago, we introduced the concept of Zero-Cliff UI Composition. We shared our vision for a progressive architecture where your code remains the same whether it's a monolith or a distributed suite.

Today, we are taking the next step: UI Macroservice Decomposition.

A question I keep running into when talking to developers:

"Can we deploy modules separately and manage them independently—like microservices?"

My answer is always: "Yes—if designed that way."

But that answer deserves a much longer conversation. So here it is.

In enterprise software, the transition from a "local prototype" to a "distributed global deployment" is usually where things get messy. At Framework M, we’ve spent a lot of time thinking about how to make that transition invisible. We call it Zero-Cliff UI Composition.

Over the course of the past week, we completed a major sprint dedicated entirely to Enterprise Trust & Governance. While building cool features is fun, laying a robust legal and organizational foundation is what transforms a side project into a viable open-source ecosystem that enterprises can rely on.

Here is a look at what we've established to bootstrap the Framework M community.

We are excited to announce the pre-alpha release of Framework M, a modular, metadata-driven full-stack framework designed for building scalable enterprise applications.