October 30 marks my last day at UBITECH. It is a useful moment to reflect on the work I have been doing and the direction I intend to keep pursuing.
Ed Byrne recently described three waves of software: custom systems, SaaS, and a new generation of adaptable software built with the customer. His post resonated with me because I have worked through all three.
In my comment, I added that the first wave also included internally developed software. That matters. The history is not simply a succession of ways to buy a product. It is also a history of how much of a system an organization can understand, shape and develop for itself.
The third wave is the co-development model I have been working on. Building Gaia for UBITECH gave that direction a concrete expression. As I move on, I intend to continue working on co-development and enterprise AI beyond UBITECH. I am not announcing my next destination yet.
The first two waves left an important question open
Byrne's framework is a useful lens, rather than a complete history or three periods with clean boundaries. Custom systems, internal development and SaaS coexist, and I expect them to keep doing so.
The first wave brought software close to a particular business. An internal team or an external builder could shape it around the organization's processes. That freedom also meant taking responsibility for understanding, maintaining and changing the system.
SaaS offered a different arrangement: use a provider's application and let the provider operate the shared product. The NIST definition of SaaS captures that division of control: the customer uses the application while the provider controls the underlying infrastructure and most application capabilities.
There are good reasons to choose that arrangement. A business should not have to build every common capability for itself. But when its needs diverge from the product's priorities, the question returns: who can change the software, and on whose timetable?
Having worked through these waves, I find that question more useful than deciding whether one delivery model has won permanently. Sometimes a shared product is exactly what a business needs. Sometimes the way the business works deserves more influence over the system.
Co-development changes the relationship
The part of Byrne's argument that interests me most is the builder working alongside the customer and helping its team develop the ability to modify and extend the result.
I see AI as an opportunity to make that relationship more practical. Faster implementation can shorten the distance between an operational problem, a working version and feedback from the people who will use it. Whether it does so reliably still depends on engineering and on the people involved.
Co-development, as I mean it, requires the customer to participate in shaping the system. The builder contributes architecture, implementation and delivery judgment. The customer contributes knowledge of the operation, its exceptions and the consequences of getting something wrong. Both need a shared view of what the software should accomplish.
For example, imagine a team building an approval workflow. The first useful conversation is about the decisions: which cases follow a rule, which need judgment, what evidence is required and who is responsible. A working version makes those choices easier to test. As the process changes, the customer should understand enough of the system to help change it responsibly.
That is an illustrative example, not a customer case study. The principle is the point: delivering software should also build the organization's ability to evolve it.
What this meant in Gaia
I built Gaia for UBITECH. Gaia is UBITECH's platform and intellectual property, and its public site describes both the company behind it and my role as product and technology lead.
The co-development pillar was central to the work I was doing: bringing business understanding and technical delivery into the same process, with enough visibility for people to participate meaningfully in how an application takes shape.
That direction is reflected in Gaia's public material. Its delivery process moves through planning, exploration, development and evaluation, connecting business objectives, design work, implementation and evidence for release. The platform overview describes workflows, evaluation and delivery management as connected parts of operating enterprise AI applications. Its commercial description explicitly includes co-development and solution-specific engineering scoped per engagement.
For me, the significance of that work is the connection between a reusable platform and the particular organization using it. A platform can provide common capabilities and operating discipline. Co-development brings those capabilities into contact with the customer's actual decisions, systems and ways of working.
These are my reflections on work I carried out at UBITECH, informed here by Gaia's public documentation. They are not an announcement of UBITECH's future plans or commercial commitments.
Adaptable software still needs a disciplined foundation
I would not read the third-wave argument as proof that SaaS is over, that every custom system will be cheaper, or that generating code removes dependency on suppliers.
The meaningful test is what the customer can actually do after delivery. Can its team understand the important decisions? Can it make a permitted change, test it and recover if it fails? Are responsibilities clear when an integration or model changes?
Owning application code and owning the underlying platform are different questions. A credible co-development engagement should make those boundaries explicit, alongside access, documentation, support and the practical ability to change providers. The model's name alone guarantees none of them.
I would want three things from the work:
- A system that fits the operation. Its behavior should reflect the real process, including the awkward cases.
- A customer team that can participate in change. Understanding and capability should grow alongside the application.
- A dependable way to evolve it. Testing, review, access controls and accountability should remain part of delivery after the first release.
AI can help with implementation. The responsibility for creating those conditions remains with the people designing the engagement.
The work continues
My time at UBITECH is ending; my commitment to this direction continues.
Working across these waves has brought me to a clear position: the most interesting opportunity is to combine the fit of custom software, the reusable foundations of platforms and the speed AI can bring to development, while keeping the customer involved in shaping the result.
That is the co-development work I intend to keep pursuing beyond UBITECH. I will share more about the next chapter when I can.
Sources
- Ed Byrne's LinkedIn post on software's third wave — the framework prompting this reflection and my comment; inspected October 28, 2026.
- NIST, Software as a Service, drawing on SP 800-145, September 2011 — the division of control in the SaaS service model.
- About Gaia — UBITECH ownership, the platform's origins and the publicly listed product and technology role.
- Gaia delivery process, platform overview and commercial packages — public descriptions of delivery stages, operating capabilities and co-development. Checked October 28, 2026.
The account of my career, departure date and intended direction is personal. The interpretation of the three waves and the criteria for co-development are my own judgments.