The Chaos Log - Work Update (4 months)

It’s been around 4 months since I joined Frappe. The other day I was sitting in the office with a few other new hires, playing some random game. After it ended, Sydel(our HR) saw me smiling and asked if I wanted to say something. I don’t know why I smile in serious situations, it’s probably going to get me into trouble someday. But yeah, I ended up sharing a bit about how the last few months have been. If I had to describe it in one word, it would be chaos.(good kinda chaos)

I had been meaning to write this for a while. I really did. But every time things felt like they were settling, something else would change. And writing, at least for me, doesn’t work on command. If I sit down just to “get it done”, it ends up feeling forced, and I don’t like what comes out.

I’m writing this sitting in my native town, by a farm, a bit away from the usual noise and pollution. Things are slower here. Which also means I finally got some time to sit back and write something I had been putting off for a while.

So this is not a perfectly structured update. It’s more of a flashback. Just me trying to make sense of what the last few months have been like. You can skip if you want, just read the part from March if you really want to know what’s the current status of my work.

Jan - Race conditions, late nights, and “this should work”

I joined Frappe thinking I’d take some time to settle in. Get a feel of things, understand the codebase, people, how decisions are made. The usual. We had thought before joining Frappe, that for at least first 3 months we will continue to work on Raven. At least, that was the plan till we figure out what we wanted to do next.

That plan didn’t last very long.

Nikhil decided to move to ERPNext pretty early on and asked if I could take up Raven. I said yes. Slightly scared, but also I’ve kind of done this before - say yes first, then figure it out somehow. Raven was a nice chance to learn more about how can I lead a team. I had acquired a lot of learnings from Nikhil having seen him do this role for years. A few weeks in, we started working on and solving long pending issues on Raven -

Fight with race conditions -

• duplicate channel members
• duplicate DM channels
• inconsistent poll states

The kind of bugs where things don’t crash, they just slowly become incorrect.

I remember one late night call with Nikhil around 11pm where we were discussing one of these issues. I had some idea of how to approach it, he refined it a bit, and over the next few days I started implementing it.

Most of the fixes were not complicated in isolation, but they needed care:

• adding constraints without breaking existing data
• cleaning up already corrupted records
• making sure patches run in the correct order
• ensuring we don’t introduce new edge cases while fixing old ones

Polls were particularly annoying. There were multiple bugs tied to race conditions and fixing them meant being careful about how existing data behaves after constraints. The patches needed to be accurate as well, needed to be super careful.

Apart from that, also worked on a lot of UI things and v3 components like list view and chat input. Chat Input is like the heart of the Raven, had to work on that for v3 as I had done this before as well. Also spent time just thinking about what Raven v3 should even be. Not in a very structured way, just notes, discussions, keeping track of long pending issues which need to be solved, keeping the Github hygiene etc.

January felt like cleaning up a system that had started drifting. Some PRs from that time:

• https://github.com/The-Commit-Company/raven/pull/1967 (duplicate channel members fix)
• https://github.com/The-Commit-Company/raven/pull/1970 (duplicate DMs)
• https://github.com/The-Commit-Company/raven/pull/2007 (chat input)
• https://github.com/The-Commit-Company/raven/pull/1986
• https://github.com/The-Commit-Company/raven/pull/1988 - This one was difficult problem to solve. Fixing race condition issues in Polls. Polls had multiple problems because of this, Ayush had created 2 bugs related to this. Polls being so crucial in Frappe, I had to solve this. Again, the solutioning was not that difficult, I mostly knew how to solve it. It was just ensuring that the past records don’t fail after adding constraints and patch does not fail. The order of execution of patches mattered a lot here. I have described in detail about the solution in the PR.
• https://github.com/The-Commit-Company/raven/pull/1991 (List view component for v3)
• https://github.com/The-Commit-Company/raven/pull/2007 (Chat Input for v3)
• https://github.com/The-Commit-Company/raven/pull/1992

Continued working on Raven Push Notifications on the sides:

I have been doing this since the birth of Raven Cloud. I keep solving the weirdest edge cases related to push notifications whenever there are any. So this part is something that I do after office hours on most days, cause that’s the only time I can find for this. Solved multiple sync and invalid token issues which not many people are aware of. Tightened permissions and API security on push notification server API as well. But there are far less drop offs, close to almost none Notification drops on Raven right now(not sure after the site migration to frappe.io). If you have a Push token created correctly you do receive a notification.

There is one small issue which I am yet to solve , which I tried solving few days ago but could not. It’s related to 2 notifications on PWA. It is a tricky one to solve, I am yet to figure out a solid solution.

Feb - The great bug cleaning sprint

February kind of reset everything. We had a company-wide sprint. Drop whatever you’re doing and focus on fixing issues that actually affect users and the business. I joined the Framework sprint. It was a different experience. Different team, different kind of problems. A lot of these issues were old, sometimes hard to reproduce, sometimes just sitting there because no one got around to them. But I enjoyed it. There was something nice about having a clear goal - just fix things that should have been fixed earlier.

Worked on a mix of things:

• permission handling inconsistencies
• annoying UI/UX issues
• email queue behavior (CC/BCC, inline images, clarity of behavior)
• file upload restrictions
• some improvements in utility APIs

Towards the end of the sprint, some of us were asked if we wanted to continue working on Framework. I thought about it. I liked the work. But I also knew I had to do something else which came up by then. So the plan now is just to pick up framework issues when I find time. They’re painful, but really fun challenge to have. Like the analogy I use for framework bugs is like solving chess.com puzzles. You find some free time, you don’t want to work on deeper solutions, just take up some issue from framework and try to solve it. Satisfying honestly.

Some PRs from the sprint:

https://github.com/frappe/frappe/pull/36637 - permission handling for Administrator role in has_perm/get_perm JS API

https://github.com/frappe/frappe/pull/36651 - edit button misalignment in address and contact fields

https://github.com/frappe/frappe/pull/36736 - add support for blocking unsupported file types in file uploader

https://github.com/frappe/frappe/pull/36818 - fix(ux): enhance display of currency symbol editable grid fields

https://github.com/frappe/frappe/pull/36968 - include "Time" fieldtype in read-only check on focus

https://github.com/frappe/frappe/pull/37050 - support list of fields in get_value method when cache is True

https://github.com/frappe/frappe/pull/37113 - clarify behavior of queue_separately and CC/BCC in email_queue

https://github.com/frappe/frappe/pull/37182 - ensure CC header visibility according to email semantics

https://github.com/frappe/frappe/pull/37246 - respect inline_images parameter in sendmail

Another PR in framework which came later, but was much needed - https://github.com/frappe/frappe/pull/38356 - enhance post_api method to send payloads in data/json

March - The Marketplace experiment begins

During the offsite, I had some conversations with Neha about the Frappe Cloud marketplace. A week later she asked if I wanted to take it up. This caught me off guard a bit. I had already said no to working on frontend for FC earlier because I wanted to focus on Raven. But marketplace felt like a different kind of problem. It also had a bit of a reputation. People didn’t stick around there for long, cause it’s messy, depends on too many things, and doesn’t have very clear boundaries. Very boring as well cause you have to review a bunch of apps. I still said yes.

I think I just tend to pick these kinds of problems. Not always intentionally, but it keeps happening. Marketplace is tricky because it’s not just a technical problem. It’s also an ecosystem problem. You need good apps for users to come. You need users for developers to build. And somewhere in between, trust can break very easily.

The first thing that stood out to me and Neha was quality. There are apps that are broken, poorly maintained, or just hard to use. If someone hits that early, they don’t try again. So instead of thinking about growth or discoverability, I thought - let’s fix the baseline first.

That’s where the idea of the App Auditor came from. The manual review process is honestly boring. It’s also inconsistent. So the thought was, why not automate most of it. Started building a system that checks apps for basic sanity:

• unsafe patterns (monkey patching)
• OS-level commands
• config issues
• general installability

I didn’t expect it to be useful beyond marketplace, but it looks like it can help in other areas as well. I have talked more about the auditor in “What’s new in the market?” section.

Over the next month, I kept hearing people talk about whether the auditor could do this/that. The ERPNext team keeps getting huge amount of support tickets which are impossible to reproduce cause the builders of the app have done some customisation which is difficult to spot. These sort of customisations are bad practice and we should not be wasting time on solving sup[port tickets for such issues. The auditor can help with that as it can be extended to custom apps as well. I did not see this use case at all, it’s just something that came up.

Also around this time, I picked up PRM onboarding work. Mostly to get more comfortable with Vue and help out with UI/UX where needed. I learnt Vue in a day or two - was simple to pick cause I knew the core concepts in React. Just had to map the models mentally. If anyone wants to see those - https://github.com/prathameshkurunkar7/vue-experiments

March felt like stepping into something that is still not fully defined, but has potential if done right.

What’s new in the market?

So I have built some beta version of the Marketplace auditor. It is somewhat ready and functioning. Some of you might have seen that Gameplan audit email that got triggered. That wasn’t entirely intentional. But also, it proved that the system actually works end-to-end. At a high level, the problem I was trying to solve was simple: A lot of apps on the marketplace don’t meet a minimum quality bar. And manual review is slow, inconsistent, and honestly… not something people enjoy doing. One of the many reasons why people think marketplace is boring is because of the manual reviews. I tried doing manual reviews one week when Hussain had just explained how he does it, and honestly, it was super boring.

I get why people dislike marketplace. Reviewing apps and going through them one by one with some mental model to check is just cumbersome. My first question was can we automate this so that I only have to check what is app actually does and the “How” can be automated?

Also, we had just seen Ankush’s frappe/semgrep-rules recently being used to perform security scans and semgrep seemed like a good answer for this.

The auditor is basically a system that takes an app and answers: “Is this safe, sane, and compatible enough to be on Frappe Cloud?”

There are a lot of checks internally, but they roughly fall into a few buckets:

Area	What it checks	Why it matters
Metadata	Description quality, screenshots, required links (docs, support, policies)	This is the first impression. If this is broken, users don’t trust the app
Versioning	pyproject.toml, Frappe version spec, dependency structure	Prevents install/upgrade issues and weird dependency conflicts
App structure	hooks.py, app naming, symlinks, side-effects	Ensures the app behaves like a proper Frappe app
Code quality	Overrides, wildcard hooks, risky patterns	Surfaces things that might not break immediately but are risky
Security & correctness	SQL patterns, command execution, monkey patching, eval usage (via semgrep)	Catches unsafe or dangerous code early
Compatibility	Frappe version support vs actual deployment environments	Avoids runtime failures due to version mismatch
Operational sanity	Whether scans/tools actually ran correctly	Ensures the audit itself is reliable

Underneath each of these buckets are multiple checks, but thinking in terms of these categories makes it easier to reason about. Some checks are just warnings. Some are strict enough to block an app entirely. And this will keep evolving. There are more checks that will be added over time as we understand more failure cases and edge scenarios.

The flow is roughly like this:

1. A new app release is created (either on push to a registered source branch or first-time publishing)
2. The auditor automatically picks it up (if it’s a marketplace app)
3. It clones the app at that exact commit
4. Runs all checks (metadata → structure → code → compatibility → semgrep)
5. Stores each check as an individual result
6. Computes an overall result (Pass / Needs Improvement / Warn / Fail)
7. Based on that, it can:
   • block approval
   • prevent publishing
   • or in stricter cases, yank the release

Everything runs asynchronously in the background, so it doesn’t block the normal workflow. This is done in the long queue, although we can improve it more as well, need to discuss more on this with the team. What I like about this is that it’s not just a pass/fail system. It tells you what failed, why it failed, and how to fix it.

That last part is probably the most important. Most of these issues don’t happen because people are careless. They happen because people don’t know what’s considered “good practice” in the ecosystem. If we can make that explicit and actionable, a lot of problems disappear before they even reach users.

How it’s designed to be extensible?

This part mattered a lot while building. I was very clear about this since the start that I wanted to make it extensible. I didn’t want this to turn into something rigid where adding a new check means touching a lot of core logic. So the design is intentionally simple:

• Each check is just a small function that returns a structured result
• All checks follow the same format (severity, result, message, details, remediation)
• Checks are grouped by category, but don’t depend on each other
• You can add or remove checks without affecting the pipeline Even semgrep is just one module in the system. It runs separately and feeds results into the same structure. So adding a new check is basically:
• write the check
• return a result
• plug it into the pipeline

That’s it. The harder part is not implementation, it’s thinking clearly about what should be checked. Once that is clear, adding it is straightforward.

Relevant PRs -

https://github.com/frappe/press/pull/5884 - Add marketplace app auditing https://github.com/frappe/press/pull/6056 - Improve marketplace auditor https://github.com/frappe/press/pull/6161 - Wire up the auditor to take actions https://github.com/frappe/press/pull/6199 - Enhance compatibility checks in auditor and other improvements

https://github.com/frappe/press/pull/6290 - Enhance email report with formatted summary

Attaching some screenshots of how the audit report looks like - (nothing against Gameplan, used it cause the mail was already sent for Gameplan)

I am currently building the frontend for this, so that the report shows up directly in cloud dashboard. That is in progress, will update this thread once that is done.

Observations while building this

Initially, this was just about improving marketplace quality. But while building it, something else became obvious. A lot of support issues come from bad custom apps. Things that are hard to debug because they’re doing something unexpected or unsafe. This system can catch a lot of that early. Which means it doesn’t have to stay limited to marketplace. It can extend to:

• custom apps
• internal apps
• smoke checks for builds
• even generating reports for support teams

For example, if an issue is caused due to unsafe customisation, we should be able to identify that early and avoid spending time debugging something that shouldn’t have been there in the first place. None of this was planned. This mostly came from conversations with people who saw what I was building and started suggesting where it could be useful. Also, I had kept several apps in review on purpose and not attended a lot of marketplace tickets for at least 3/4 weeks. That was done on purpose so that I could test the auditor. I tested it last Saturday, I found that I could reply/resolve almost 24 tickets in about 1 hr. Because the auditor had already done the checks, I only had to verify them and send it to the publishers. Even this can be further improved.

There’s a lot to improve:

• better signal vs noise
• clearer feedback for developers
• more checks over time
• better documentation and developer education
• Automatically replying to publishers on helpdesk when audit fails
• Show audit findings on the marketplace listing page - already planned, but feels like the next thing to pick up after fixing a few issues.
• Scans take around 5–20 seconds. Currently, there’s no separate worker; everything goes into the long queue.

But the direction feels right. The goal is not to make publishing harder. If anything, it should make expectations clearer and reduce surprises later. If we get this right, the marketplace becomes more trustworthy without anyone explicitly noticing it. It also improves cloud reliability and reduces load on support, because a lot of issues get caught earlier. This turned out to be a much higher impact problem than I initially thought.

April - Got into the control room (no manual included)

April was supposed to be predictable. Frappe Build happened, then SOP season. I had written down a fairly clean plan for the year:work on marketplace, improve PRM onboarding, help with UI/UX, slowly grow into more responsibility.

It felt… controlled.

And then one Thursday, that illusion broke. We had a product review for Frappe Cloud. Rushab(our CEO) walked through what’s not working. Not in a vague way, very clearly - where things feel off, where the experience breaks, where we’re not thinking deeply enough. And while he was saying it, I could see it too. That surprised me a bit. Because this is something I’ve seen Nikhil do a lot. Just look at something and immediately point out what’s wrong in the product thinking or UX. I never thought I had that instinct. I’ve always said this -

I don’t have taste, I have acquired taste.

After that discussion, Rushab suggested that I take ownership of the Frappe Cloud product/application layer. That moment was a bit weird.

On one hand, this is exactly the kind of responsibility I had written in my SOP that I want to grow into. On the other hand, I wasn’t expecting it this soon. I thought I’d have more time. Ease into it. Make smaller mistakes first. Instead, it was more like - this needs attention, take it. Rushab mentioned something that stuck with me. He said it’s like that scene in Terminator 2 where someone is suddenly thrown into a control room and has to figure things out without really knowing how everything works. That’s pretty much how it feels right now. Most of my decisions are instinctive. I usually go with the first thing that feels right. And even here, my first reaction was yes.

But that doesn’t mean the doubt doesn’t show up. I overthink a lot. So naturally the questions start coming in - am I ready for this, do I even know enough, what if I mess this up. I had a conversation with Nikhil around this as well, and I went back to the same two questions I usually ask myself:

• is this the biggest problem I can solve right now?
• will this create real impact? Is this the big swing?

Both answers were clearly yes. That made the decision easier. Now it’s less about being “ready” and more about accepting that I won’t have all the answers on day one, and still showing up and trying to make things better. Also helps that there are people around me who seem to believe I can pull this off. I don’t fully know why, but I’ll take it.

My plan ahead

I’ve been thinking about how to approach this next phase of me taking up the ownership of FC Product layer (not technically a promotion-cause we don't have a promotion system, but added responsibility like a promotion?). The first step is to develop a clearer vision of what the product should feel like. Not just my view, but aligning with what others in the team think as well, that includes Neha, Pragati, Sidhant, Shadrak and Bowrna(till May end). We will likely need a couple more engineers eventually.

Once that is clearer, the next step is execution:breaking that vision down into something actionable across timelines - 6 months, 3 months, 1 month, and then weekly work. Also making sure that everyone knows:

• what we’re trying to achieve
• what their role is in that
• how they can contribute effectively

I keep going back to a football analogy. Everyone plays a certain position. You don’t win because one person runs everywhere. You win because everyone plays their role well to perfection and the system works together. Right now, I’m still trying to understand the field and players properly before trying to optimise how we play.

Closing Thoughts?

Not sure if I had to mention more of my PR links in this, I am pretty sure I missed many, cause they were not relevant to the flashbacks. But if anyone is remotely interested in whatever work I have done since 1st of January 2026, they can check this search filter on Github.

This ended up being a long read. Partly because I didn’t write frequently enough. I was waiting to feel like “something is ready” before writing about it.

In hindsight, that was perhaps a mistake. Most of the interesting work happens while things are being built, not when they’re done. And writing along the way would have made this easier to follow, and probably easier for me to think as well. Although my only counter to that is, I wanted to have something significant to show before I actually talk about it.

Nonetheless, I will try to write more frequently going ahead. Even if things are incomplete, or still messy. That’s probably a better way to document the journey. For now, this is where things stand. Let’s see how it goes from here. Hoping for the best (🤞🏻)

Also, on side note, my list of food places to try in Mumbai has been making some noise in the office. Was thinking of sharing it with everyone, so here it is - https://maps.app.goo.gl/Ub7SHASETFS6B64n7 This is view only right now, but if anyone wants to be a contributor and help me better curate it, reach out. (need more)

That’s all for now.