Overview
Methodox Technologies, Inc. - officially registered in Ontario at the end of July last year - has now been around for nearly a full year. Time has passed neither too quickly nor too slowly, moving along steadily as it always has. The biggest difference between running a company and doing personal side projects, in my view, can be captured with a comparison between passion and professionalism: when you do something out of passion, you choose based on interest; when you do something professionally, you commit regardless of mood or preference, working methodically toward clear goals and standards - day or night, rain or shine.
To put it more concretely, the difference lies in quality control. As someone with an engineering background, I'm not particularly gifted at self-promotion. What I can do - and do most naturally - is focusing on making a good product. Some friends have asked where the motivation comes from. Truthfully, I'm not entirely sure either. But like clockwork, I still wake up at 6:30 a.m. every day, ready to work.
The Story
When I first started working on Divooka, I didn't envision it as a fully-fledged programming language. I wanted it to be general-purpose, yes - but not necessarily from the standpoint of a programming language. The goal was more about decoupling the functionality from its environment, enabling it to run directly from the command line, and making the library design flexible enough to work beyond our immediate domain.
Initially, the biggest problem I wanted to tackle was how to replace Excel. There are many ways to go about that - because Excel's greatest strength is also its weakness: it's too powerful and flexible, which means it often lacks structure. And that chaos is what we wanted to bring order to. The first step was to build something on top of the spreadsheet concept - adding structure and rules, using something like object-oriented thinking to enable users to visually edit and link spreadsheet data.
Had we stayed on that path, the Divooka interface today would probably look more like floating spreadsheet windows - similar to Apple's Numbers - instead of the visual node-based editor you see now.
The Divooka Way
Back in 2019, I had already started exploring the idea of using general-purpose programming for GUI building. My approach then was more framework-oriented: tools that could generate UI wrappers based on flowcharts. These weren't new languages, but auxiliary features to make diagrams more reusable.
In early 2024, we also explored two major directions: graphic annotation and online collaboration, inspired by modern design tools like Figma and Google's cloud-based productivity suite.
The ability to build complete applications wasn't something I initially envisioned - it seemed too ambitious for what started as a personal side project. But going full-time removed that ceiling. It gave us room to think bigger.
One of the most natural and promising directions for Divooka is visual app development. Unlike traditional text-based languages, Divooka was built as a graphical, extensible environment from the start. Its own development environment is a Divooka app - one that is, in principle, programmable with Divooka itself. That vision is still in blueprint form, and full realization will take time.
Business Collaboration
From a business perspective, the experience of leading a team from late 2024 into early 2025 has been mixed. On the plus side, offloading certain tasks helped reduce some pressure. On the downside, with our current financial constraints, it's been hard to find help we can fully rely on - which, perhaps, is just reality.
Teamwork through outsourcing introduced its own challenges. Choosing the right people is tough. Even highly capable partners don't always deliver the expected results. Interestingly, ChatGPT and other large language models played a strange but useful role in this phase - mainly by helping with research and code scaffolding.
There's a pattern I've noticed: even when working with contractors, I end up defining the architecture and interfaces, and much of my time still goes into coordination. Once you're past the prototyping phase, iterations are limited, and results vary. In a similar way, large language models tend to produce "one-shot" outputs - either useful or not. But if I've already built the structure, the autocomplete results I get from an LLM often rival what a junior outsourced developer might provide.
In that sense, I'd much rather work closely with people over time - collaborating, communicating, and refining a shared workflow. That's where real teamwork becomes meaningful.
The Past
Early on, development followed a pretty rigid schedule - when it was just me, with no meetings or other obligations, daily goals were clear and straightforward. But by mid-year, things were shifting constantly. On the one hand, that brought flexibility, and led to a number of unexpected developments, especially in product direction. On the other hand, such reactive planning made it harder to estimate timelines. A case in point: our "first full version," originally scheduled for release this February, will likely be delayed until next year.
But as mentioned earlier, even the definition of what qualifies as a "first full version" has evolved dramatically.
In many ways, my approach to this company mirrors how I ran projects in university. First, I'm still the main driver and implementer. Second, I remain cautious when it comes to collaboration. Over the years, I've come to understand the Economy of Scale in a deeply personal way - not in terms of wealth or headcount, but in how accumulated skills and better tools dramatically boost my individual productivity. In this age of AI, that effect is more visible than ever. Contrary to popular belief, knowledge - not just capital - is the primary engine of productivity.
That said, if you do have capital and a great team, collaborative scale can still achieve amazing things.
Entrepreneurship
One of the more surprising (though perhaps not shocking) aspects of this journey has been the mix of encouragement and skepticism I've received. Support has mostly come from peers in the professional world, while more traditional voices - old friends from university, family members - have tended to be more doubtful. Though, of course, there have been exceptions in both camps.
This kind of reaction isn't often talked about on social media, but I think it's worth reflecting on.
First, people naturally fear what they don't understand. Second, those closest to us - friends, family - end up becoming supporters in one way or another, whether they intend to or not. Third, when it comes to values and personal incentives, people respond differently to attempts to break convention - especially where money is involved.
At a few conferences, I've had the chance to talk with other founders. Their motivations, strategies, and philosophies run the full spectrum. Some of the most frustrating folks are those who throw around the term "AI" without substance. (We too fell into that trap at one point, admittedly.) But these experiences - moments of confusion, attempts to find clarity - have opened up my view of the world far more than reading philosophy books or binge-watching TV shows ever did.
The Future
Looking ahead, I see three key challenges:
- Finishing development and releasing the first full version of the software.
- Creating a complete educational system around it, ensuring product coherence and knowledge accessibility.
- Marketing and forming partnerships, while keeping the company sustainable.
2026 will be a demanding year. We'll need to maintain development speed while trimming back unnecessary administrative tasks. We want to move with precision, but not become overly cautious. The path forward requires boldness, care, grounded execution, and avoiding the lure of shortcuts. That's something I need to keep reminding myself.
