Over the past months QuantumByte has run two-day builder workshops with two groups who, on paper, have no business building software: high-school students at Penabur with no coding background, and community members in Banyuwangi with a practical problem and no technical staff. In both cases, working applications existed by the end of the second day. Several of the student apps were adopted by their schools.
I want to be careful about what this does and does not prove.
What it does not prove
It does not prove that anyone can replace a software team. The enterprise systems Quantum builds, for command centers, logistics networks, and certification bodies, need engineers, security review, integration, and the discipline of a delivery process. Two days does not produce that, and nobody in the workshops thought it would.
What it does prove
It proves something more useful: the person closest to a workflow can build the first version of the tool for that workflow, if the platform meets them where they are.
The village applications are the clearest example. A rice-stock tool for Duda Timur, a child-health monitoring tool for Kauman, a harvest-recording tool for the women's farming group in Cibiru Wetan. None of these would ever have reached the top of a software company's roadmap. They were built by the people who needed them, because those people understood the trigger, the steps, the exceptions, and what "done" looks like better than any outside analyst could.
That is the same discovery material I spend weeks extracting from enterprise clients. The builders already had it in their heads.
What the platform has to do
The lesson for anyone building tools, low-code or otherwise, is about where the effort goes:
- Make the first hour rewarding. Both groups had a working screen with their own data in it before lunch on day one. Without that, you lose the room.
- Speak the workflow, not the schema. Nobody in Banyuwangi wanted to define an entity. They wanted to record a harvest. The platform has to start from the action and derive the data.
- Make exceptions cheap. Real workflows have a "what if the stock arrives damaged" case. If handling it takes an engineer, the tool stays a toy.
- Keep the result shareable. An app that only runs on the builder's laptop is a demo. The moment the school could hand a link to other teachers, the app became real.
Why a founder should care
If you run an operation, the fastest path to a useful internal tool is often not a vendor and not your IT backlog. It is the supervisor who has been keeping the process alive in a spreadsheet, given a platform that respects their knowledge and a couple of days of guidance.
That does not remove the need for professional engineering when the tool has to scale, integrate, or carry sensitive data. It does change where you start. Start with the person who knows the work.
What the two days looked like
The format was the same for both groups. Day one started with each participant naming one thing they record, track, or report in real life, and building a screen for exactly that before lunch. The afternoon was spent adding the second step of their workflow and the first exception. Day two was about making it real: entering actual data, letting someone else use it, and fixing what confused them. Nobody was taught what a database is. Several people built one anyway, because their workflow needed it, and that is the correct order to learn it in.
The person closest to the problem can build the first version, if the tool speaks their workflow instead of your schema.