Frappeverse keynote: what happens when non-developers can build

Frappe spent years debating whether AI-assisted coding was ready for serious product work. Then a colleague from its business team built Frappe Sheets, and the argument changed. The result was unusually concrete: Frappe set aside June 2026 as a company-wide hackathon month and invited engineers and non-developers alike to build with coding agents.

At Frappeverse Mumbai 2026, Vibhav Katre, Frappe's director of growth, and Neha Sankhe, its director of products, showed what came out of that experiment. The demos ranged from new applications to a document-first purchase-invoice workflow and an overhaul of ERPNext documentation.

The keynote was optimistic about what agents make possible, but it was not a claim that software now builds itself. Its stronger idea was that product context can travel further when the person who understands a problem can also prototype a solution, while engineering, design and product judgment remain close enough to turn that prototype into dependable software.

A hackathon month changes who gets to experiment

Vibhav traced Frappe's changing relationship with AI across several events. In 2024, the company was still debating whether the technology was a bubble. By Frappe Build in April 2026, community projects and AI-assisted work inside Frappe had made the shift harder to dismiss.

The decisive example was Frappe Sheets, built by a member of the business team using agentic coding. Vibhav said it prompted an all-hands discussion and convinced engineers, non-engineers and company leadership to reconsider their assumptions. Frappe's response was characteristically direct: give everyone a month to experiment, invest in models and build something useful for themselves, the community or customers.

That last part mattered. Frappe framed the work through dogfooding: solve a problem you understand, make the solution good enough for your own use, then consider releasing it for others.

Frappe Draw turns product context into a prototype

Vibhav's first project was Frappe Draw, an infinite canvas inspired by products such as Whimsical, Excalidraw and draw.io. It combines mind maps, structured flowcharts and a whiteboard in one application.

Mind maps can branch on either side of a parent node and be formatted for presentation. Flowcharts support process, decision, input, output and terminal nodes, with automatic layouts that can be tidied after the user moves things around. The whiteboard adds shapes, connectors, snapping, grids, tables, images, sticky notes and a presentation pointer.

The point was not that Frappe suddenly has a finished diagramming product. Vibhav described Frappe Draw as a prototype that received useful validation at demo day and could eventually belong in Frappe Suite if it becomes polished enough. Its immediate value was proving that someone without a software-engineering background could turn a detailed product idea into working software.

That did not remove the difficult parts. Vibhav raised the questions that arrive after a prototype: security, architecture, community contributions and code review. An apprentice, Bhargavi, joined the project, allowing him to spend more time on quality assurance while getting technical help where the product needed it.

Greenfield apps move beyond demo day

His next project, Frappe Toolbox, started from the utilities folder on a phone. Instead of separate calculators, converters, timers and lookup tools, Vibhav built one application containing 33 tools.

The keynote showed currency conversion with historical charts, GST calculations, HSN and SAC lookup, health and finance calculators, unit conversion, timers and a dictionary. Unlike Frappe Draw, Toolbox had already moved beyond an internal prototype: it was hosted on Frappe Cloud at frappe.tools and could be installed as a progressive web app.

Other non-developers used the month to address problems closer to ERPNext. A business-team colleague built Tally Migrator, which imports XML from Tally, identifies mismatches, maps account names and lets the user review data before migrating it into ERPNext. Vibhav presented it as available in Frappe's GitHub repositories. He also showed Letters, a visual newsletter builder created during the same wave of experimentation.

These were all greenfield applications, where a new codebase gives an agent room to work without navigating years of existing product behavior. They showed speed, but Vibhav also acknowledged the tradeoff: a new product still needs refinement, a pilot and adoption before it creates meaningful impact.

Purchase invoices start with the document

Neha carried the keynote into an existing product. She had previously worked on accounts-payable automation and knew a recurring problem well: invoices arrive through employees, shared mailboxes, paper and supplier portals before an accountant can enter or validate them.

ERPNext's purchase-invoice workflow began with the form and attached the source document later. Neha's proposal reverses that order. A new Document Queue begins with the files waiting to be processed. An accountant can browse the queue, pick an urgent invoice and review the document beside the transaction being created. The proposed intake paths include an inbox integration and bulk upload.

The queue is intended as a Framework capability rather than purchase-invoice-only code. A custom DocType could enable the same upload-first workflow from DocType Settings. Neha said its pull request was close to being merged, with bulk upload, email inbox intake and support for more formats still pending.

Even without OCR, the side-by-side layout makes a digital PDF easier to work from. That is a useful example of starting with the workflow instead of treating AI as the only meaningful improvement.

Extraction joins data entry with checks

The second half of the idea is a purchase-invoice extractor. In the demo, it filled fields such as the supplier invoice number, due date and invoice details while keeping the document visible for review.

For basic digital invoices, the current custom app uses heuristics rather than an AI model at runtime. Neha used LLMs while developing and testing those heuristics, but she was explicit about how the demonstrated extraction worked. The review can surface mismatched totals, missing supplier tax IDs and differences between payment details on the invoice and the supplier master.

The ambition goes further. Future checks could flag invoices outside a contract period, unusual rate changes or possible supplier impersonation. Regional invoice rules would belong in compliance apps, while an optional Frappe Flow path is planned for cases that need higher-confidence extraction and mapping.

This remains a hackathon custom app. Frappe plans to build the capability natively into ERPNext, most likely in version 16 if the work proceeds as expected. That distinction matters: the keynote demonstrated a working direction, not a finished ERPNext release.

Coding agents take on the documentation backlog

Neha's second project addressed a less visible product problem: ERPNext documentation with old pages, missing features, duplicated versions, broken redirects and 404s.

She began manually, rewriting a few documents to understand what useful ERP documentation should contain: a clear story for a new user, examples, field explanations, diagrams, frequently asked questions and troubleshooting. Once the repeated work became visible, she turned it into separate research, writing and screenshot skills.

Agents also helped inspect redirect chains, locate the nearest valid destination and clean up duplicated documentation. Neha estimated that the models saved about 80 percent of the time required for that cleanup, while emphasizing that precise redirects still needed manual judgment. The result was a visible reduction in 404 errors.

The broader rewrite is around 20 percent complete, so this is an active documentation program rather than a finished refresh. But it offers a credible use of agents: read the current code, follow a documented structure, prepare screenshots and let a product owner spend more time checking whether the explanation is actually useful.

Context is the beginning, not the whole job

The keynote ended with a useful limit on its own enthusiasm. Non-developers often have deep context, but context alone does not produce a good product. They still need to imagine the right solution, develop taste, sustain the ambition required to finish and work with engineers who can challenge the architecture and implementation.

Good primitives matter too. Neha described struggling to make her purchase-invoice tabs feel native until Frappe's component library gave the coding agent better building blocks. The quality of agent-generated software rises when Framework already offers well-designed, reusable components.

The most useful outcome of Frappe's hackathon month is that product people can test more of their thinking in working software. Engineers can meet them later in the process, with something concrete to review. The teams that turn that speed into adoption will still be the ones that care about the last 90 percent.

Watch the full Day 2, Track 1 livestream from the start of this keynote