DEV Community: ESTROLABS

The Problem with Modern Computing

ESTROLABS — Tue, 03 Feb 2026 14:44:58 +0000

Introduction

When I refer to modern computing, I mean the technological world we live in today and how systems have evolved to their current state.

The core problem is that features, security, and performance are often bolted on over time, resulting in fragile systems with unpredictable behaviour and unreliable performance.

This pattern has been visible since at least the early 2000s, as technology has advanced by layering new abstractions and versions on top of old foundations rather than rethinking those foundations entirely.

Many people do not notice this problem because systems appear to work well enough most of the time. Issues are only addressed when failures occur, and fixing individual problems creates the illusion that the approach is sustainable.

In reality, this leads to an endless cycle of patches, increasing security risks, and growing system complexity. As more technology is built on top of already fragile systems, especially with the introduction of AI, the potential impact of failures becomes larger and more difficult to control.

This article focuses on explaining how modern systems reached this state and why continuing down this path creates long-term technical and security risks.

Complexity Built on Complexity

Systems usually grow by reacting to problems as they appear. When an issue is found, it is added to a list of fixes, and in many cases the solution becomes an add-on or a temporary patch that works well enough to ship and eventually becomes part of production.

When new features are added on top of older foundations, unnoticeable bugs begin to appear. These bugs can cause strange behaviour or introduce security issues where attackers can bypass certain layers because there is no clear or consistent relationship between them.

As systems grow larger, security vulnerabilities, performance issues, and design failures become more common. This leads to increasingly fragile systems. As technology advances, attacks become more frequent and more sophisticated, making it easier for attackers to disrupt operations or cause real harm.

To compensate, systems demand more powerful and expensive hardware just to maintain acceptable performance. In many cases, this cost is unnecessary, as better-designed systems could run efficiently on cheaper hardware, reducing pressure on both companies and consumers.

Once complexity reaches a certain point, understanding how a system truly works becomes extremely difficult. When layers are bolted on without clear structure, the system turns into a web of disconnected parts where reasoning about behaviour can take years, even for simple changes.

Why "Working" Is Not Enough

When people say a system “works”, they usually mean it has minimal bugs and can complete the task it was designed for. This does not mean the system is effective, secure, fast, or pleasant to use.

Fixing issues only when they appear often creates more problems than it solves. The fixes are rarely integrated into the system’s foundations and instead sit on top, increasing complexity and hiding deeper issues.

Fragile systems are often accepted because they are cheaper and easier in the short term. The mindset becomes “don’t fix it until it breaks”, even though many problems could be prevented by designing solutions that are built into the system rather than bolted on later.

Over time, this leads to predictable outcomes: weak security, slow performance, frustrating user experiences, and poorly designed systems that are difficult to maintain or improve.

Why This Is Becoming More Dangerous

Modern systems operate at a scale far larger than in the past, often forming the foundation for entire industries, governments, and daily life.

For example, operating systems like Windows have evolved over decades. While parts of the system have been redesigned and reworked over time, much legacy code and structure remains, which can lead to inconsistencies and limitations when new features are added. Changes such as major UI redesigns demonstrate that some problems cannot simply be bolted on forever and eventually require foundational rework.

When fragile systems are used at massive scale, small bugs can cause widespread outages, and hidden vulnerabilities may remain undiscovered until serious damage has already occurred.

Automation often operates without a full understanding of a system’s foundations. As a result, it tends to encourage additional abstraction and layering, which can amplify existing structural problems rather than resolve them.

When failures occur in these environments, the consequences are no longer small. People lose money, lose access to critical services, and in some cases lose their ability to work altogether.

What Needs to Change

The mindset needs to shift from “I want a new feature” to asking how that feature fits into the existing system, how space is made for it properly, and what testing is required to ensure it does not introduce vulnerabilities or failures.

Time and automation should not be used to bolt solutions on faster. They should be used to identify risks early and help integrate changes into the system’s foundations, where security, performance, and usability can be strengthened rather than compromised.

Systems should be designed around security, design, and performance from the start, not treated as concerns to address later.

Continually patching problems creates more work over time and increases the risk of causing harm to users or to the system itself.

The deeper the understanding of a system’s foundations, the better decisions can be made about integrating new features with minimal side effects.

Rushing solutions skips important considerations and leads to repeated rework later. Slowing down to build solutions that fit properly results in more stable and future-proof systems.

Why This Matters Now

This problem is harder to ignore today because technology has advanced to a point where fragile foundations are being pushed to their limits. Continuing without change risks widespread failure rather than isolated issues.

If systems continue to grow without fixing their foundations, outages will become more frequent, more severe, and affect far more people across critical platforms and services.

Now is the right time to rethink how systems are built because we have both the experience and the tools to do so. Technologies such as AI can help analyse systems more deeply, but they also demand high performance and reliable foundations to operate safely and effectively.

Without stronger foundations, advanced systems amplify existing weaknesses rather than solving them.

The goal is a future where technology is strong, understandable, and reliable, rather than fragile, unpredictable, and difficult to trust.

ESTROLABS Website

What is ESTROLABS?

ESTROLABS — Mon, 02 Feb 2026 11:37:17 +0000

Introduction

ESTROLABS is a bare metal technology lab.

This lab is theory and practice based, focused on better understanding of the modern systems we use today and exploring whether they live up to the standards they could reach, or if better approaches exist.

Modern computing has a serious issue where systems are built by bolting layers on top of each other, creating environments so fragile that a single bug can take down large parts of the stack.

We need to better understand low-level elements and ask whether, with the knowledge and technology we have now , these systems could be built differently.

This will be a long term process, but it is necessary to ensure we are building and living in a technological world that is effective, understandable and resilient.

Core Principles

Design

Design is not just about art or unique visual twists.

Design is about UI that is intuitive and focused on user experience.

It also includes architecture, structure, and how logic processes data within a system.

In simple terms, design is UI/UX and how the system is structured to work correctly, securely and efficiently.

Design ensures that features are not bolted on, but fit together as part of a coherent jigsaw.

Security

Security is not a feature, an add-on or an optional component.

It is a fundamental building block of any system or application.

Security must be treated as a foundational requirement, not something added later.

Without security built into the systems structure you create fragile defence, easier attack paths and predictable vulnerabilities.

Performance

Performance is about efficiency and effectiveness, not just raw speed.

Relying on speed alone is unpredictable and unreliable in real-world use.

Systems should aim for predictable, measurable performance.

Performance should allow hardware and software to operate efficiently, without software unnecessarily limiting what the hardware is capable of.

How Work Happens

Every project starts as an idea that is investigated and researched.

Each project uses a version-based system, where every project begins with a default version called the MVP (Minimum Viable Product).

If a project is improved, extended, or explored in a new direction, a new version is created rather than changing the original.

Each version can move through the following stages:

Research - understanding the topic and background
Prototype - building small experiments to see how ideas work in practice
Requirements - defining scope and constraints
Design - designing logic, structure, and UI/UX
Implementation - writing the code / Creating the product / system
Testing - validating functionality, behavior and quality
Review - reviewing code, documentation, and whether ideas align
Deploy - tasks related to releasing a usable product
Marketing - documentation or materials related to communicating the work

These stages do not follow a strict order.

Work can move back and forth between stages as needed to support flexibility and adaptation.

All work across these stages are documented to show progress, reasoning, trade-offs and real-world decisions.

Readers can follow a project from its first version through later iterations or focus only on the latest version and its documentation.

What it is not

ESTROLABS is not an open source project and it is not a SaaS.

ESTROLABS is experimental by nature. Only released products are intended for general users, while the lab work itself is aimed at engineers and technical enthusiasts who care about systems at a deeper level.

Experiments and ongoing projects are not designs for general consumers. Only products that have been proven to be secure, efficient and intuitive are released for broader use.

Code is not released as traditional open source. While users have the right to inspect the code running on their systems, usage of that code requires a commercial license and explicit permission.

This lab does not optimise for third-party integrations as doing so would undermine its core values and long-term goals.

The work here is slow, experimental and imperfect by design.

Why it’s Public

Work is documented publicly because technology is not owned by one person. It is built by a community of people who improve it by sharing ideas and learning from each other.

If this work were done privately, it would take years to progress without real feedback or external perspective. By working in public, I can receive feedback, discover gaps in my understanding and improve decisions based on reality rather than assumptions.

Public documentation allows others to follow a small lab from its earliest experiments even if they do not have the time or expertise to do this work themselves. This gives visibility into different approaches and ways of thinking about systems.

Writing decisions down forces deeper research and clearer thinking. It turns vague ideas into concrete reasoning and reduces the risk of mistakes made purely in isolation., Feedback from others further helps shape and challenge those directions.

Readers should expect regular articles, including dev logs, general technical discussions and occasional tutorials.

How it’s Funded

This work is not sold as a product in its raw form. The research, documentation, and thinking are published openly and remain accessible.

ESTROLABS is funded through a combination of support, donations, and income from released products. People who value this work and want to see the lab continue help fund ongoing experiments and research.

Some projects result in usable products that are made available through a commercial license. Income from these licenses helps sustain the lab and fund future work.

Supporters enable long-term experimentation and allow ideas to be explored, refined, and turned into real projects and products while the process is documented publicly.

Supporters do not dictate direction or decisions. This funding model protects the work by keeping it accessible to everyone, while ensuring that commercial use contributes back to the lab through licensing.

What's Next

Design systems will be a long-term area of work, as a solid design system is essential for everything built on top of it. This work will evolve alongside other projects as it matures.

Work will also focus on low-level bare-metal programming using x64 assembly with FASM on Intel CPUs. This includes building core libraries and development tooling such as memory managers, allocators, and networking components, forming the foundation of the lab’s kernel work.

Readers will see a mix of tutorials, dev logs, and research articles, where specific topics are explored and discussed in detail.

All work is published on the ESTROLABS website, with additional ways to follow along via platforms such as Medium, dev.to, and Patreon.

Content is intended to be published daily in some form. When that is not possible, shorter updates will be shared through Patreon or other channels such as YouTube or X.

ESTROLABS Website