Methodox Blog
·11 min read·Company

Two-Year Reflection on Methodox and the Development of Divooka

Two years of Methodox: a recap of the past year, what we've done, what we've learned, and the road ahead.

By Charles Zhang

Still going strong, and hopefully we will be ready soon.

The Divooka Story

It's surprising to count—it has already been so many years since the first prototype in 2022, the later attempted updates in 2023/2024, the first "beta" in September 2024 that we later downplayed to something closer to an "alpha", the internal builds throughout 2025, the much greater feature expansion towards 2026, and now, over the past few months, what I hope will be the "final" major round of architectural refactoring around the runtime, file format, package management, and features needed for professional use. I just wish I didn't age at the same rate as my software concept.

I spent a lot of time earlier this year, particularly around June, polishing DSLs—Domain-Specific Libraries—because without a useful set of higher-level capabilities, Divooka is JUST a language. A language can be technically interesting while still leaving the user to build everything themselves; the point of Divooka is eventually to provide useful computational building blocks at a much higher level. The areas I've chosen to focus on are naturally the areas I know reasonably well—not necessarily the areas where I would claim to be the world's greatest expert, but areas where I think we can make genuinely useful tools for everyday work: data processing, procedural terrain generation, graphics and media work, automation, and office productivity.

The procedural context in particular took a lot of effort to conceptualize. I wanted to address several problems I have experienced with node-based systems such as Unreal Engine's Blueprint: large procedural graphs can become difficult to restructure, reuse and reason about, while certain programming patterns are awkward to express visually in the first place. Divooka's procedural context is my attempt to retain the visibility of graph-based programming without pretending that traditional programming concepts such as loops, branches, functions and structured control flow somehow stopped being useful. The move towards a compiled runtime was another major jump, and really only came together around April and May 2026. Our Mandelbrot benchmark makes the motivation rather obvious: compilation changed the performance characteristics dramatically compared with execution through the older editor/runtime paths. Fully embracing compilation has been a major undertaking, but I increasingly see it as essential if Divooka is going to combine very high-level programming with acceptable performance. More details and the limitations of the benchmark are published in the GitHub repository linked below.

The file format, runtime and standardization work has been another recurring problem. This is also why we have deliberately slowed down on declaring a final version of DiDS or other Divooka Open Standards. The formats have changed A LOT as the architecture has matured, and publishing something as "final" before we are prepared to support it for years would create more problems than it solves. I don't see much value in pretending the specification is frozen merely for the satisfaction of calling it 1.0. Stability matters, interoperability matters, and eventually backward compatibility matters—but those things are much easier to promise after the underlying system has actually settled.

So where are we going? General-purpose at the core, high utility and high performance, while keeping a super-high-level interface closer to the experience of scripting languages than traditional application development. Nodes where nodes make things clearer, code where code makes things clearer, and enough interoperability underneath that users are not trapped inside an isolated visual-programming island. For people already familiar with programming language design, scripting systems and visual development environments, that probably explains most of the idea. At this point, I am content with that.

Internal and Financial

The financial side became more challenging as we moved through 2026. We are now entering our third year and completing our second, and naturally the resources that felt relatively abundant when I started the company in 2024 are more constrained today. Legal work, IP, infrastructure, hiring and contracting all cost real money, and founder time has a cost even when it doesn't appear as a salary on an income statement. I also did not exactly enter this adventure after ten years of living like a monk and accumulating an infinite personal runway. At some point every bootstrapped founder has to ask the uncomfortable but necessary question: how long can this continue before the business itself has to carry more of the weight?

That doesn't mean I suddenly regret doing it. I am still relatively young—a little over 30—but two years is long enough that the startup can no longer be treated as a temporary experiment detached from the rest of life. I have to think about long-term financial stability, savings, retirement and everything else that continues existing regardless of whether somebody decides to build a visual programming system. There is no magical funding event I can responsibly assume will arrive and solve those questions for me, so one way or another the company has to become increasingly sustainable on its own. In that sense, commercialization is becoming more important, not because the R&D suddenly matters less, but because the only durable way to continue doing the R&D is to build a business capable of supporting it.

I doubt I would particularly enjoy going back to conventional corporate life, although occasionally I do miss parts of it: working in those skyscrapers, looking down at people and cars twenty floors below as little moving dots, the view of Lake Ontario, interesting corporate events, colleagues with very different expertise, and simply being part of something much larger. But it is fundamentally different from being one's own boss. In a large organization I could sometimes lose sight of why a particular piece of work existed in the first place; here, almost every decision is connected directly to something we eventually put in front of users. Maybe one day a smaller studio environment would suit me too, but there is something uniquely rewarding about being able to make a decision, build the thing, and then see something made by us actually published.

That is something to think about. We need to act soon—not out of panic, but because after two years, sustainability deserves to be treated as part of the engineering problem rather than something outside of it.

Noise, Splashes and Small Gadgets

The development process also spun off a surprising number of smaller products. Some were experiments, some became quite handy, and some have already gone through several iterations of their own. I don't really see these as completely separate from Divooka: in many cases they came from technologies, libraries, ideas or workflows developed while working on the larger system, and they give us smaller places to test whether those pieces are actually useful outside the environment in which they were invented.

Released / scheduled: Fantasy Planet Painter, A Detective Story and Divooka Explore.

Smaller apps: Methodox Threads, Methodox Voxel Sandbox, and Transcriber—which has been surprisingly popular as a free tool.

It sometimes feels like we spent a lot of time on each of these, and then when I actually count the list it somehow doesn't look like that much. Such is software development.

Public-Facing

On the product-readiness side, we've updated the official Methodox website, added dedicated websites for the main products, greatly expanded the Methodox Wiki, and gone through migrations away from systems such as Wiki.js and WordPress in the process. The public surface of a software company is itself a substantial product: documentation, downloads, storefronts, licensing information, release notes, product pages and examples all have to remain reasonably synchronized with software that is changing underneath them. That work is less glamorous than implementing a compiler or graph runtime, but without it there isn't really a product that an outside person can confidently understand or use.

The CI, packaging and deployment side has improved as well. Those processes had remained painfully manual for much longer than I would have liked, and ironing out the development pipeline has been one of those improvements that is difficult to advertise but immediately makes everything else easier. Releasing software should eventually become boring. If every build and publication feels like a special event requiring a checklist of mysterious manual steps, something in the engineering process is still unfinished.

Lessons

Looking back to my reflection from July 8 last year, the burden from training, external obligations and general management has been reduced considerably. A surprising amount of time last year disappeared into accounting and tax work, which was not exactly why I founded a software company, but I suppose—and I must believe—that doing something three times makes the fourth much less intimidating. More importantly, I think I now have a better understanding of what actually makes a "product", especially the amount of work between something technically functioning and something polished enough to release, document, announce and support. A feature being implemented is not the same thing as a product being finished. That distinction sounds obvious until you repeatedly experience how much work lives between those two points.

One thing I still don't do enough is "engage with the community". I understand why people keep emphasizing it, and I don't think building completely in isolation is healthy, but my view has become more nuanced over the past year: community engagement becomes substantially more useful when there is something coherent for that community to engage with. Feedback on a moving architectural target can easily turn into noise for both sides. Divooka Explore's Early Access period should give us a better mechanism for that interaction, because users can increasingly react to a functioning system rather than an abstract promise.

Things such as cloud services through Methodox One, AI integration through projects such as Chat Gateway, and various other interesting ideas people suggested all pulled my attention in different directions. In retrospect, the core runtime was simply not ready enough for that level of expansion, even towards the middle of 2026. It was really only over the past month or so that I began feeling that the foundation was taking good shape and, more importantly, starting to feel robust and trustworthy. The runtime took an unexpectedly long time to develop even though I am no stranger to making scripting systems: EasyShell worked well for what it was designed to do, and I have been using Pure in one form or another since my time at OTPP. But Divooka is a fundamentally larger undertaking. Creating a new syntax, graph model, execution system, editor, IDE, packages, interoperability layer and application model from the ground up is very different from building a convenient language layer on top of an existing interface. We absolutely use existing foundations—Roslyn, .NET, C#, Python and their enormous ecosystems—but there are still a remarkable number of edges that become our responsibility the moment we try to make them feel like one coherent system.

Launching the product has always been a priority, but during roughly the first year and a half I have to admit that I spent too much attention on what I thought I was supposed to be doing as an "entrepreneur": conferences, investor calls, chasing VC conversations, networking because people said networking was important, and generally talking about building the company while I was still trying to build the thing the company exists to make. Some friends still tell me I haven't talked to enough people, and they may well have a point. But I've also learned that there is a limit to how much external motion is useful before it becomes noise. Right now I care much more about making Divooka real, solid and usable. There will always be more people to talk to afterwards.

The AI Gain

I am finally starting to officially "use AI" in a much more meaningful way—more precisely, coding agents. I have used ChatGPT on a near-daily basis for quite a long time, while also being fairly critical of media coverage portraying every new model as immediately revolutionary. For a long time I simply didn't find the reality matched the hype. That has changed considerably through the middle of 2026, and especially since late July. Coding agents have become useful enough that I can no longer dismiss them as an unreliable novelty: for certain kinds of implementation, research, repetitive work and review, they are genuinely efficient.

That does not mean I suddenly believe an AI is going to independently build Divooka for us. In practice it feels much more like a reduction in the cost of certain kinds of labour. It can generate, inspect, compare, research and iterate very quickly, but somebody still has to decide what ought to exist, whether the proposed architecture makes sense, whether the output actually works, and whether any of it belongs in the product. If anything, human capacity has become a more obvious bottleneck: judgment, prioritization and verification do not disappear merely because implementation becomes cheaper. The useful question is no longer "is AI useful?" but "which work should we delegate to it, which work should we keep doing ourselves, and how do we verify the difference?" That is a much more practical question, and one I expect will continue changing rapidly.

Conclusion

The one thing I would most like to see now is Divooka properly released. But my philosophy throughout this project has been that some steps simply cannot be skipped. That is part of the reason I quit my job and went deep into R&D in the first place: if the only objective had been to ship something quickly, there were much easier products I could have chosen to build.

I still look forward to the day when I can produce a fully illustrated, properly written Introduction to Visual Programming with Divooka. In my head I can already see it as an entire textbook covering a way of thinking about programs that is still poorly represented in conventional computer science education—not "visual programming" as a collection of toy blocks, and not simply a diagrammatic wrapper around scripting, but a serious treatment of graphs as a practical programming medium alongside text. If we can eventually build a system rich enough that such a book genuinely deserves to exist, I think that will be an achievement in its own right.

And I think that is worth taking the time to get right.

References