Recommendations for Engineering
TLDR (get to the point)
The Lossless Group recommends:
- An all-in commitment to Reproducible Builds, using Containers and Ephemeral Environments alongside appropriate onboarding, training, and Documentation.
- An exploration and selection of a Backend-as-a-Service platform, which significantly reduce the developer time required to build functional prototypes as well as production level applications that do not need to design for massive, rapid scale (think billions of records per day.)
- An all-in commitment to the React Stack, including adoption of StyleX and Skip for styling and back-end data movement, respectively. In addition, it seems Tinybase is the best way to implement super-fast Local-First experiences. We don’t really care about the React ecosystem in particular, but the sweat of maintaining everything doesn’t need an extra headache of coping with various stacks.
- Assuming it’s all in React, Laerdal should converge on a single Headless CMS that’s State of the Art.
- A wholesale commitment to Component Based Software Architecture, starting with organization-wide love for the Life Design System, with celebrated and heroic team members that translate that into an always current, always upgraded UI Kit and Component Library.
- A dedicated team member to apply the Component Library to legacy products and services, likely reporting to the Digital Business Unit and almost embedded with the Life Design System team.
- Collaborate with executive team members to articulate and visualize a Concept Model, which then aligns the development of an organization, all vendor-inclusive data model, and the development of an organization-wide content model.
- Initiate a long-term, higher-order goal of having a Unified API, and take the time to implement Platform Mechanisms across every initiative.
- Create and uphold an Internal Standard Developer Stack using Documentation First development, while somehow making room for Convergence and Divergence Cycles.
- Initiate and oversee the rewrite of every legacy product or service to an Internal Standard Developer Stack.
- Create and maintain a very small but high-caliber team who is on point, or the SPOC to simply keep up with upgrades to the Internal Standard Developer Stack and all its dependencies.
- Develop internal processes with Protected Play, iteration, testing, for additions to and transitions within the Internal Standard Developer Stack.
- Align on and use by default an engineering tool for Workflow Management, accessible to the Product and Design teams. The current State of the Art is Linear.
A Brief comment on the React Stack
For solid reasons, the Component Library (derived from the UI Kit, derived from the Design System) is implemented in React and published as an Node Package Manager package. Good news, people are using it. It's being implemented. This seems to be working and is Market Standard practice.
React is created and maintained by Meta (aka Facebook). In any technology choice, there are subtle, often extensive, benefits of compatibility and interoperability. So, there are implications of choosing React that are all fine, but should be illuminated and understood widely.
For instance, the most beloved CSS Framework is Tailwind. However, the styling framework created and maintained by Meta is StyleX.
And in 2025, Meta also released Skip. Skip is an Open Source Framework to streamline Back-End implementations. Why the need for a whole other framework? Largely because React is maintained as a Front End library for interactive, dynamic, optimistic data loading for Component Based Software Architecture, and it is the Market Standard.
There are several Cross Platform Frameworks that take React code and transpile it to native applications across all mobile and desktop native environments. A Market Standard is Expo.
So, if Laerdal was to assume that there are many, valuable, and indecipherable reasons to align on the same stack, there should be at least a few people trying to figure out Skip and StyleX, and migrating or transitioning projects and products towards them.
A Primer on AI
Engineering has an outsized role to play in assuring that AI impacts the whole organization. Organization-wide benefits from the AI revolution are not possible without Deep Work that can be performed at senior-most roles within any organization. The default trajectory for every company is that top-performers use AI tools to radically improve their individual productivity. Anything beyond that needs a strong vision.
Bite-Sized code-bases.
Our experience thus far, while limited, is that AI Models, even the ones that reason, do not have a long-term memory outside of an immediate context. Therefore, Code Generators are prone to rewrite parts of any application that work while trying to develop new parts of the application. This necessitates a Microservices architecture in building complex applications with Code Generators.
The tendency for Code Generators to rewrite code that should be preserved makes writing anything complex purely with AI models unlikely as of now. However, there are some ways around this we are just figuring out this. In addition to the Microservices architecture, getting back to Test-Driven Development has a very strong rationale. Acceptance Testing. [[Testing Frameworks
A suite of tools is using AI for Code Review. Examples include CodeAnt AI. One way to make the output of Generative AI be useful is:]]
Key people need to be active on Hugging Face, a Developer Community for those working on AI. It is the largest repository of AI Models.
Many market entrants promise to help write code. While there is still much left to be desired, progress is happening at astonishing speed.
Text Editors or IDEs include Cursor, AgentFarm and Windsurf IDE.
Terminal Emulators include Warp. Terminal assistants include Aider.
Opsless Deployment Providers that can provides a Code Generators, includes Bolt.new, v0, Replit and Lovable.
The Only Constant is Accelerating Change
We now have Opsless Deployment Providers, Reproducible Builds, Backend-as-a-Service, Multi-Model Databases, not to mention an explosion of Web Frameworks. All of these are part of a Tectonic Shift that fundamentally changes, nay -- profoundly changes -- the realm of the possible. For everyone.
How GitHub Changed Everything. Some strange combination Enabling Technology has really changed everything for software developers in the last few years. An amorphous, multi-variate blend of GitHub, Open Source projects, Reproducible Builds with Containers, (especially with Docker Hub), added to worldwide convergence on JavaScript, Web Framework paradigms, and Python, all create a whole new world for anyone with Internet access.
Add to this Reddit forums, YouTube influencers and tutorials, and AI Copilots that are huge breakthroughs in Code Generation, well they amount fundamental, game-changing shifts in how software is conceived, teams assemble, ideas spread, and traction won.
There are two fundamental beliefs that need to be assimilated as a result:
- There is a greater need to be watching whatever might be State of the Art and is in the process of Crossing the Chasm to widespread market adoption.
- There is a greater need for Continuous Refactoring code that is maintained by the company, to such an extreme it might as well necessitate a fierce commitment to Continuous Rewrites.
investing for S-Curves
In Michael Staton's visits with many across the Laerdal organization, there seems to be a pervasive need to meet defined goals, impact the top line, grow grow grow and go go go. Yet, an urgent need for growth now on existing product lines and with existing technology stacks create a rationale for hiring to fuel growth. Beware, proceed with caution.
The perverse irony of both grinding on goals, or hiring to fuel growth, then, is that people that are hired to add fuel to and grind on an existing Business Configuration. So, all new hires who fuel the pace towards existing goals on an existing set of processes and with an existing set of tools are inherently behind any |Tectonic Shift that may be occurring.
Irony squared: investing quickly in innovation and piling on budgets, resources, and people, have the effect of slowing down innovation because the most profound innovations follow an S-Curve.
S Curves are a simple visual that describes a slow and gradual start, a fast and often exponential rise, and then a plateau. It is often used to describe the Diffusion of Innovations, with Market Adoption often seeming small and gradual for prolonged periods before taking off at an inflection point.
Typical idioms about creating new products and services, and understanding the S Curves paradigm, are primarily focused on marketing and sales. Particularly in light of understanding and having deep respect for the dynamic of Crossing the Chasm.
A less discussed bit of wise practice is to keep teams and investments small -- to the extent it feels counterintuitive -- even if there is a mandate to invest more.
[1]
It's become common wisdom in the Startup ecosystem that the number one reason companies fail is Premature Scaling, when ambitions and goals outpace reality, and organizations don't follow a Consistent Go to Market playbook.
towards a Unified API
It's beyond extremely important that Laerdal move towards an Unified API. API design is a skill set, but it's also more of a reasoning skill set than a technical one. Therefore, most anyone that can enjoy mathematical reasoning and has a basic understanding of the REST API conventions, and how a Data Model should look can contribute or even drive the process. There's even a common standard to follow, OpenAPI.
More importantly, it's only going to become as valuable as it can be if its designed with a foundational Concept Model of the organization. Having the full context of the Laerdal organizations, its activities, and its data, is paramount. It's important to use practices from Domain Driven Design.
Having a Unified API is, ironically, even more important for moving away from (or avoiding) a Monolith. If Laerdal would move towards Microservices and Component Based Software Architecture, and Unified API is the roads and bridges infrastructure that brings it all together.
There are tools to assist with this, many you are probably already using... such as Postman 1
Stack Engineering
Stack Engineering is the term we are using to propose the mission critical, but quite newfangled role of Software Developers to manage Information Flows across the organization using modern conventions that have formed around REST APIs and between software systems.
We propose that this is, in fact, a new role that requires a new kind of talent. Most prideful Software Developers -- and most good ones mostly are prideful -- do not want to spend their time Stack Engineering. If they agree to it to be a team player, they will want to get out of it as soon as the opportunity arises.
To get something out of the box, check out iPaaS vendors. Apparently, you already use both Boomi and Fivetran, which could be redundant. They may also not be State of the Art, we really don't know. Based on marketing alone, we would guess that Merge is the standout provider.
Convergence and Divergence Cycles for a flexible, Unified Stack
In trying to use Cognitive, Collaborative Tooling, people and teams adopt many technologies. Over time, this can lead to issues with Stack Compatibility.
Here are some incongruous things happening:
- Someone somewhere is still using AdaptCMS, which is a Content Management System for teams developing in Laravel. However, I have yet to meet any team developing in Laravel or using PHP.
- Sanity is a modern, Headless CMS and is a Market Leader. However, Sanity seems to only be used in a specific product, which I believe is Scenario Cloud. (Headless CMS are almost always designed around JavaScript, and universally use REST APIs to move around JSON data.)
- Eloqua is, at this point, an out-of-date Marketing Automation System. It was acquired and is thus maintained by Oracle. The Sales Marketing and Services team use Salesforce as their primary workflow tool and data system. Salesforce and Oracle do not play nice, and their rivalry is well known and comical.
Developer Tools like Graphite, which is a value-added layer on top of Git and GitHub, are known to add to developer productivity.
Opsless Deployment Providers remove the headaches involved with deploying code on core cloud hosting services like Azure and AWS. Netlify and Vercel have become the go-to, early market leaders. However, even more fancy ones exist like Render and Replit.
Extreme Replication
Someone should have the informal or formal role of obsessing about eliminating the "works on my machine" problem, assuring that anything being done on anyone's computer can be replicated in as few steps and with the least frustration possible. Thus enter the concept of being radically dedicated to Reproducible Builds.
There are many different approaches to this, and even more tools, services, and stacks to achieve it.
The market standard is a full commitment to Docker, using it to make Containers for all software development. Some influencers have been raving about ContainerD, though it has much less adoption as of this writing. Microsoft, of course, has created their own variant, along with an attempt at a standard, called Devcontainer. There are creative ways to use Containers for many goals or preferences within Engineering.
Recently, the dev influencer community has been raving about Nix, which seems to add a "pop-up" aspect to the Containers paradigm that's being called Ephemeral Environments. Engineering teams love Nix so much that there is a meme about a "Nix God Complex"
Follow a blog tutorial on using Nix with Docker written by Mitchell Hashimoto, the founder of HashiCorp, (about 1hr with installations, 15 minutes without).
Intersection with Product & Design
New developments in Enabling Technology have flipped the constraint of Software Engineering on its head. Up until quite recently, the constraint was Back-End engineering. But today, the constraint is on the Front End.
The Product & Design teams should be working from one Unified Design System. This design system should be followed religiously, and as it is developed into an interface it becomes a UI Kit. Most often, the design system is slightly ahead of the UI Kit. Regardless, the entire UI Kit should be reflected in the design system.
The UI Kit needs to be helpful enough to gain Grassroots Adoption. This is already happening, and there is an owner. However, there is not an owner that can take the UI Kit and Component Library and apply it to legacy systems.
Footnotes
[1] On Premature Scaling
Idea Bin
The New New Engineering Toolkit
On Standards and their Institutions
The most recognized seems to be the ISO. However, most of the standards related to progress on the Internet seem to come from The Internet Society, yet some seem to come from OASIS Open. When it comes to progress in graphics, the standards body seems to be both OpenGL and the International Color Consortium. Standards Organizations.