Our Software Development Services Journey

At this point in our journey, WorkingMouse has evolved into a steady and reliable software development services company, specialising in high-quality legacy system rearchitecture for both government and enterprise. However, the path to achieving this focus has been anything but straightforward.

Our specialisation in tackling the complex legacy problem didn't happen overnight. It has been shaped by hard-earned lessons: the burnout of great team members, unjust legal battles, difficult decisions like downsizing, several rounds of redundancies, and even the experience of taking a multi-million-dollar product to market only to find we hadn’t achieved the crucial product/market fit.

Each twist and turn has contributed to refining our approach and driving us towards the stability we now enjoy. These experiences have not only strengthened our resolve but also provided the insights necessary to act as a comprehensive guide for software development services. We now stand as a trusted partner, equipped with the knowledge and resilience to help organisations modernise their most critical systems and provide the reuse of these to consistently pay down their technical debt.

Origins

The journey of WorkingMouse’s software development services began soon after our founder completed their PhD, which laid the groundwork for the creation of Model Driven Engineering Software as a Service (MDSAAS). The core concept of was to treat the artefacts of software—such as requirements and designs—as models. This approach aimed to build in reuse, momentum, and quality from the start, marking the beginning of our research and development journey.

To support the development and delivery of the first version of this model-driven approach, WorkingMouse was formed. Initially, we were a small team, delivering services without any formal structure or process. At that stage, we relied heavily on the ingenuity of our people and the tools at hand to overcome the inevitable obstacles that cropped up during projects.

As the company began to grow, so did our challenges. What started as a few team members soon evolved into a team of over a dozen. With this growth came new complications: communication became harder to manage, and ensuring consistent quality across all projects proved increasingly difficult.

To address these growing pains, we developed our first customer journey. This process was designed to align both our customers and team to a streamlined, process-driven approach. It was a significant turning point, introducing a more systematic way of working and a framework for managing projects more effectively.

At the same time, our tooling evolved. We developed a local Codebot called Lampbot, a combination of Linux, Apache, MySQL, and PHP—the classic web app stack. Though the tooling was offline and complex to set up, when used properly, it delivered substantial value to projects.

One of the key challenges we encountered at this stage was managing customer expectations, particularly balancing the trade-offs between time, quality, and cost. To address this, we introduced project sliders, allowing customers to priorities between fixed or flexible project timelines, as well as a scientific estimation process that accounted for uncertainties.

Despite these challenges, WorkingMouse managed to grow its revenue year on year significantly, laying the foundation for the structured and service-oriented company we are today.

The Major Factors

During this pivotal growth phase, WorkingMouse transitioned from being a young company into a more “mature” organisation.... Unfortunately, this growth was not without its missteps. Like many companies in their early stages, we made several childish mistakes that shaped our path and forced us to rethink how we approached the business and realise we’d only just transitioned to walking.. not on our opens just yet.

One of the most significant issues we faced was taking on too much work at too low a margin. This decision, driven by a desire to grow quickly, left us vulnerable. We also made the mistake of trusting customers who showed early signs of being problematic. Instead of exiting the relationship early and refunding their money, we overcommitted, hoping that trust and hard work would overcome the challenges. This, in turn, led to situations where we expended massive effort for clients who were never truly satisfied, no matter what we delivered. This burnt team members out and showed we were out of balance between our customers, team and company.

As we brought on more team members, we added a middle layer of staff with only a few years’ experience. While this layer was intended to manage the increasing workload, it further complicated our communication lines. The additional complexity, coupled with high-volume, low-margin business, misaligned our services and led to software delivery that fell short of the quality we aimed for.

The turning point came when one of the problematic customers, whom we should have let go early on, returned two years later to attempt legal action against us. This was a wake-up call—forcing us to realise that we had to do things differently.

At the same time, we decided to split the company into two distinct branches: a product business and a services business. We raised $4 million in capital to fund the cloud migration of our Codebots product to its third generation. However, we misjudged our market, despite playing with many sales and growth strategies. We went to market with 2 Codebots that were designed to accelerate project momentum but ultimately took too much control away from the users. Customers wanted more flexibility and ownership over their technology, and our bots didn’t provide that.

This misalignment with customer needs forced us to pull back into below-the-line R&D, where we worked to figure out what the market truly required. Ironically, we found the answer internally by focusing on platform engineering and building an internal product to meet the needs of our own WorkingMouse project teams first.

Progression

These key elements—our business challenges, internal reflections, and market adjustments—interacted with each other in profound ways as we cleaned up the business and refocused on internal empowerment.

To move forward, we undertook several key initiatives. The first was to align everyone in the company around a shared vision, reduce unnesessary cloud/subscription cost, and put in place an information management system (ISMS) to achieve ISO27001 knowing that team members would be with us for varying lengths of time. We made this transparent and formalised our commitment by publishing our manifesto. This period of introspection helped us identify the three key variables necessary for project success: People, Process, and Tools.

We found that achieving a balance between these three elements enabled us to deliver remarkable results. So, what did we do differently?

Firstly, we re-examined the roles within a self-organising project team. We recognised that these roles need to shift throughout different project stages, depending on customer needs. This led us to create a new approach: smaller, specialised teams that focus on delivering high-quality results. Empowering these teams gave them the ability to respond more flexibly and efficiently to the needs of each project.

Next, we reviewed the tools we used. We embraced best-in-class, technology-agnostic tools, with a particular emphasis on open-source software. This led to the development of our fourth-generation platform, which enables a model-driven approach that is flexible enough to support any technology and automate its output.

Lastly, we recognised the need for a process that was not overly prescriptive but flexible enough to adapt to the other two elements. This led us to the concept of Jidoka, or “automation with a human touch,” borrowed from Toyota’s production system. The idea was to leverage automation that can be reused repeatedly while maintaining human control over critical decisions.

We realised that we didn't need to strictly follow traditional Agile or Waterfall methodologies. Instead, we could combine the best of both approaches, customising them to our strengths. We also discovered that conventional methods, such as the shortest path to value or the strangler fig pattern, which are commonly used for legacy system rearchitecture, didn't align with our capabilities or vision.

This is when we fully embraced Model Driven Engineering, adopting a breadth-first approach. By modernising systems as closely to their original state as possible and building reusable components, we were able to systematically solve complex legacy system challenges in a way that suited our platform’s strengths.

The Pivotal Moment

Several critical decisions have shaped the course of WorkingMouse and pushed us toward our current focus. One of the most significant was our strategic decision to focus on enterprise and government legacy system modernisation, particularly like-for-like modernisations. This allowed us to channel our people, processes, and tools into a specific direction, sharpening our expertise and streamlining our operations.

In parallel, we made another crucial shift by refocusing the Codebots team. Previously, we were trying to meet the demands of third-party clients, which spread our resources too thin. By turning inward and creating a more direct and rapid feedback loop within WorkingMouse, the Codebots team developed a much more functional and robust tool set. The platform engineering team has taken this feedback and used it to empower the development teams, making them more agile and effective in their projects.

For me, one pivotal moment stands out above the rest. It happened during the Department of Defences commercial tracker project. Dean, the lead designer on the project, had a breakthrough that changed the game for us. He announced that he was deprecating Figma (An indsutry standard design tool that Adobe Tried to snap up for $20 Billion) from the design process and modelling the components directly within the Codebots system. This was a massive leap forward!

For the first time, we had a development team collaborating directly with the client, fully supported by the Codebots platform engineering tools. This not only accelerated delivery but also ensured we maintained exceptional quality. Dean was able to configure both the user interface and the database model, with Codebots writing a full-stack, open-source application on its own. The realisation that this approach was better than using external tools like Figma was a defining moment.

Seeing Deans pride in what he had accomplished, and understanding the massive amount of value we were now able to deliver at such high quality and momentum, confirmed that we had found our path forward. This was a fantastic moment that validated our decisions and showed us the future of our work.

Resolution: The Consequences

All of these critical decisions and interactions have culminated in where we are today. At WorkingMouse, we have refined our approach to software development by building a platform that allows us to abstract models to an organisation’s standards early in the project lifecycle. This upfront investment enables us to leapfrog technical debt and create massive reuse across projects, essentially creating a domain-specific or organisation-specific low-code platform.

However, there is a balance to this approach. Achieving the level of modelling mastery that Dean demonstrated on the Department of Defence commercial tracker project requires significant time, training, and effort. While we have meticulously documented this process and linked it to the Codebots platform using an automated, model-based documentation approach, the reality is that this is a complex process. It’s not something that delivers immediate out-of-the-box results—it requires skilled “craftsmen” like Dean to truly unlock the platform’s potential.

Once the models are created, the power of this system can be democratised, allowing even non-technical users to configure and manage them. However, this process is still not intuitive for everyone, presenting a challenge as we strive to make the toolset more accessible without sacrificing its flexibility and power.

At present, our hypothesis is that we need to bring all system meta-modelling into a single, unified visual library and canvas. This would allow users to filter and navigate dependencies with ease, eliminating the confusion of managing multiple system models and their cross-references. By creating one “playground” for model management, and offering easier visualisation, we believe we can make it simpler for both technical and non-technical users to control and configure models effectively.

Reflection

As we reflect on the journey we’ve taken, several important lessons have emerged, which we’ve now woven into our company values. These values not only guide our day-to-day decisions but also shape the direction of WorkingMouse as we continue to evolve.

1. Balance with Direction

One of the most significant lessons we’ve learned is the need for balance in everything we do. Every decision comes with both intended and unintended consequences. While we strive for the highest quality in our work, both we and our customers operate within commercial constraints. There’s always a trade-off between time and quality, and we must carefully assess where to draw the line on each project. We’ve learned not to overcompensate, but also not to underdeliver—ultimately ensuring that we align our work with our customers’ commercial objectives.

2. Connection with Empathy

Connection is crucial, both internally and with our customers. At one point, we grew too quickly, and not everyone even knew each other’s names. When that happens, you lose the sense of connection that drives projects forward in the right direction. Now, we ensure that our team stays tightly connected, and we bring our customers into that collaborative space. By working closely with them and using our tools together, we can make better, more informed decisions that balance time and quality.

3. Play with Purpose

The software industry is unregulated and constantly evolving, which means there’s always a new way to solve a problem. To discover the best path forward, we need time to experiment, play, and explore. This experimentation is essential for innovation and risk management. By allowing ourselves to play in our work, we not only improve outcomes but also foster more enjoyment in what we do—leading to better results for both our team and our customers.

4. Mastery with Practice

Mastery comes not just from practice but from teaching and sharing that knowledge. You need to understand the rules before you can break them, and only through sharing and collaboration can we achieve true mastery. As an organisation, we’ve gained a solid grasp of how our people, processes, and tools combine to deliver great results. However, we are still on the path to mastering how to share this knowledge with the wider market and train others to achieve the same level of excellence.

Looking ahead, the biggest challenge we face is converting these hard-earned lessons into something that resonates with the broader market. When the industry is focused on quick solutions and forward-looking web frameworks, how do we convince others to slow down in order to speed up? It’s a complex task, but one we’re committed to solving as we continue to refine our approach and share our expertise with the world.