https://www.frameworkm.dev/docs/explanation/features
just for fun read through what we asked LLMs to generate. Code as well as docs.
2 Likes
This is indeed impressive progress given the short time, and presumably a single contributor with other commitments on his plate. Kudos!
Care to share some updates?
I am excited and curious how this framework will turn out if given enough time, motivation/dedication, and resources.
1 Like
Follow the website https://www.frameworkm.dev (Gitlab Pages), it has further urls, docs and details. I added link to create new github codespace on website.
3 Likes
No docker, pure native binaries desktop app is possible (built with tauri with service sidecars). That means same app can run on: Desktop (cross-platform) > LAN (secure ssl) > VM native binaries > VM with containers > Kubernetes.
This is what I wanted when I started, I remember using the oracle virtualbox erpnext image on windows just to get ERPNext running on my office windows machine/LAN.
Further, to solve the problem of app as service paradigm. Start with app as module/lib, evolve into app as a service on it’s own. Framework supports “monolith” mode and “macroservice” mode. The example foundation is in business-m: wms, finance are separate apps that get federated in frontend and backend in macroservices mode or run as a single unit part of business-m in monolith mode.
Framework pipeline is stable, releases are steady on pypi and npm. I’m right now establishing the release pipeline for business-m (castlecraft / business-m · GitLab / https://business.castlecraft.in).
The speed at which we can build apps is insane! We are translating all our client apps that were pure frappe to framework-m.
Thanks to @kisg for inputs at right time, the ui is React Native compatible. If anyone from community connects with me I am up for it! More things on website, blogs and community.
5 Likes
Now I know where all this comes from 
. You used to diss Frappe engineers by calling them “DocType” engineers, now you are becoming one of them. All you want is not “frappe” 
But competition is good. Let’s see how far you go - I am going to steal your ideas as well, like you are stealing mine. I wished this was more collaborative though. Also I would have been happier if you had at least acknowledged this in your docs / readme. Anyways, now I am also in this business. Let’s play.
edit: Was going through your docs. Looks like heavily “inspired” from Frappe Framework.
edit 2: Just going through your motivations. Frappe will get all of that. We will go super light. We will put async and we will do it by making it backward compatible.
I want Frappe Framework plus More! No one can deny the magic DocType brings!
That will be great! Pick these first:
- Solve Anti-Patterns from Legacy Systems | Framework M
- pypi published packages
- no-nodejs runtime
- async python.
- dependency-injection as I suggested during Frappe build.
- Hexagonal or Port/Adapter pattern can be used for connecting external concerns. Keeps the framework agnostic of infrastructure it requires.
Send the “DocType” engineers to me, I will exactly point out the code and explain!! 
Edit: Another thing I forgot to mention frappe can pick up, is adding module-federation and mfe for frontend building. If frappe can think of that then it becomes easy to compose frontends from different apps without rebuilds. If I build “hrms” frontend and pack it with my hrms python wheels, then as soon as anyone does pip install frappe-hrms the ui should be composed into the main shell without dealing with nodejs.
2 Likes
We will get all of it - these were also my first thoughts: Make framework lighter · Issue #39459 · frappe/frappe · GitHub
I don’t think a rewrite is necessarily a good idea. The LLM depends on strong primitives. the years of long tail fixes in framework are invaluable, will be hard to replicate.
But yes, get rid of much of the weight. For sure.
1 Like
For Frappe Framework? NOT a good idea!
For me, I didn’t want any baggage to even restrict my thoughts! If the experiments work and get stable, Frappe can always pick them up!
1 Like
Hi @rmehta and everyone,
Long overdue reply from me — apologies for the delay. I want to be clear upfront: I completely agree we shouldn’t be rewriting Frappe from scratch. Instead, I’ve been channeling that energy into a set of research projects that extend and strengthen the ecosystem. Happy to share what’s been cooking:
Making Frappe Lighter and Cloud-Native
I’ve been quietly building a Frappe/ERPNext Microservices Backend Library — now running in production for one of my SaaS deployments.
The core idea: keep all Frappe and ERPNext code 100% reusable without changing how developers write it, while enabling it to run as independent microservices with single-site multi-tenancy support. In practice, this means we now have discrete Auth, Invoice, and Signup services, with an API gateway routing requests based on resource context URIs. Would love your feedback.
Agentic AI on Frappe
Two projects here:
-
Frappe Forge — a semantic layer that helps LLMs deeply understand any Frappe app, significantly reducing hallucinations.
-
Frappe Agent — a fully Frappe-aware agentic coding platform built on top of Forge. The Frappe Skills layer has been significantly expanded. Output quality has been really strong — here’s a sample app generated by the agent.
Faster Developer Onboarding — Frappista
Setting up a Frappe dev workspace has always been painful. Frappista solves this with bootable container images — everything pre-seeded, no site installation, no extra configuration. Just run. You can have a full ERPNext site up in under 50 seconds.
Note: M4 Mac support requires a rewrite and is currently in progress.
Redisless Frappe for Local Dev
To reduce local dev bloat, I built an in-memory wrapper that replaces Redis entirely. The implementation is in this commit. I think this becomes increasingly important in the agentic era where lightweight, fast environments matter.
Frappe Operator
A production-ready Kubernetes operator that spins up fully configured Frappe sites in under 5 minutes.
Frappe Package Manager (In Development)
Moving away from Git-based installations toward a proper package manager for shipping Frappe projects — simpler, cleaner distribution.
More coming on the UI front soon. Happy to walk anyone through a demo — just reach out.
Nice, great to see all of us thinking in the same direction. Validates it.
Do you have a video, would love to take a look. I have also been building the next building blocks (GitHub - frappe/bench-cli: [Experimental] One bench to rule them all · GitHub), do check it out!
https://pypi.org/project/framework-m links to https://frappeframework.com/
## Acknowledgments
Inspired by [Frappe Framework](https://frappeframework.com/), reimagined with:
- Modern Python (3.12+, async/await, type hints)
- Clean architecture (Hexagonal/Ports & Adapters)
- No global state (Dependency Injection)
- Code-first schemas (Pydantic, not database JSON)
https://gitlab.com/castlecraft/framework-m/-/blob/main/libs/framework-m/README.md
2 Likes
Is anyone thinking about a central knowledge system for AI mistakes?
Right now every developer using Claude/Cursor/Copilot on Frappe is repeating the same mistakes - wrong DocType patterns, hooks.py anti-patterns, missing fixtures, broken bench commands. Each machine learns alone. Nothing flows back.
What I am imagining - something like mcp.domain.com - a shared MCP server plugged into every developer’s editor. When AI makes a mistake on one machine, it gets captured, reviewed, and the fix flows to every other developer. Like a community-curated rulebook the agent must read before generating code.
Pair this with a learning pipeline - scan PRs that got rejected, extract the “why”, feed it back. Over time the central knowledge becomes the moat. AI on Frappe becomes 10x better than AI on any other framework, simply because we share what doesn’t work.
Also here is github repo for claude code fuse that one can build similar or integrate it in claude code to check its mistake and build agent playbook and mistake ledger GitHub - sbknext/claude-fuse: Local-first observability for Claude Code sessions — auto-detects mistakes, surfaces repeated skills. · GitHub
Thanks for sharing that video, @revant_one; looks awesome! Keep up the good work. 
1 Like
Hello,
I’ve built a complete AI Harness — it can run locally or connect through an MCP server to automate Frappe development, or build entirely new apps from scratch.
If anyone’s interested, my suggestion: start by automating low-risk tasks, then slowly expand. Begin with the repeatable, low-risk work and push it to 100%:
→ Testing — generate, run, triage
→ First-line client support — answer, route, escalate
→ Requirement fine-tuning — clarify, structure, fill the gaps
Once that loop is boringly reliable, let the harness take on more — module by module — until it’s shipping full systems on its own.
Happy to discuss Frappe automation with anyone working in this space. Drop a comment 
github: sbknext repositories · GitHub
1 Like
“Make framework lighter” gave me another idea! Why do we even need database if we are going light? Framework should boot stateless if configured with no database (not even in-memory sqlite). I was able to get it booted in pyodide in browser and added it to blog.
My plan was to get the helm/docker/.deb pipeline ready this week, which I have ready now. Running on Pyodide was extra that got added for framework.
1 Like
Hi @revant_one
Any chance the apps on Frappe Framework can work on Framework M.. maybe a wrapper (e.g. docker on windows) or will it be similar to how rust is slowly being written into the Linux kernel - hoping developers will start coding on the new platform which will take many years to replace legacy code
What does the endgame look like?
Use this if you want to reuse your Frappe and ERPNext code.
For Framework M
- Majority of code will exist in Frappe/Flask(werkzeug), Django.
- Framework M/Litestar, FastAPI will be used to write new code if developer wants to use async.
- Drop in the spec md and Frappe app code in the workspace and get the code generated along with all automated QA checks. (80% there already)
- Business M (Android/AOSP of business apps) because:
- Framework M is my wishlist of what Frappe Framework should be.
- Business M is my wishlist of what ERPNext should be.
@revant_one , Framework M is on the cards for me to evaluate
1 Like
Hi Rishab,
Can you please take a look at this PR for redisless dev environment? I have the screen shots there.
Happy to discuss if you have concerns.