Inspiration
July 2026 – Where It All Began
The idea for Sarah was born during a computer repair training course.
One of my classmates was trying to repair a laptop belonging to someone they knew. The laptop had a keyboard-related problem, but they couldn't access the operating system to properly test the keys.
To investigate the issue, they needed to prepare a new bootable USB drive. Downloading and setting up the necessary tools took a considerable amount of time.
Watching this situation gave me an idea: What if I could create a program that would let someone test a computer's keyboard immediately, simply by booting from a USB drive?
At the time, I wasn't thinking about artificial intelligence or autonomous computer repair. I simply wanted to build a practical diagnostic tool that could save people time.
What it does
The first prototype was called SarahShell, a Windows-based diagnostic environment built using WinPE.
One of its earliest working features was a keyboard tester capable of detecting individual key presses and keyboard combinations.
Sarah also received her first visual identity: a playful character that could stick out her tongue.
By July 28, I had begun developing basic drive and partition diagnostic capabilities.
Sarah was still a relatively simple tool, but the original idea was becoming a working application.
How we built it
As development continued, I decided to move away from Windows PE and rebuild the project around Debian Linux.
This was a significant change in direction.
Instead of creating a tool focused primarily on keyboard testing, I wanted to develop a complete, independently bootable diagnostic environment.
The project became SarahDiagnostic.
Development expanded toward hardware inspection, memory testing, storage diagnostics, network checks, and diagnostic reporting.
The goal was to provide technicians and ordinary users with a portable environment capable of investigating computer problems without depending on the installed operating system.
Challenges we ran into
Over the following months, Sarah evolved into a more complete USB-based diagnostic system.
I worked on a Debian Live environment, an ISO-to-IMG build process, and a Windows application designed to download, install, and update Sarah on USB drives.
The project also expanded to include licensing infrastructure and release distribution mechanisms.
However, development was far from straightforward.
I encountered problems involving USB partitioning, boot compatibility, firmware behavior, unreliable builds, download integrity, and system resource limitations.
Some problems required redesigning entire parts of the installation and build workflows.
These challenges taught me that developing diagnostic software is not just about implementing individual tests. The entire environment must be reliable, especially when the computer being examined may already be malfunctioning.
Accomplishments that we're proud of
What started as a simple keyboard testing idea gradually evolved into a bootable diagnostic environment.
I'm particularly proud of building Sarah Lite on Debian Linux, developing diagnostic features, creating an ISO/IMG build process, and working on a Windows-based USB installer and updater.
Another important achievement was developing the infrastructure for distributing releases, verifying downloads, and managing licenses.
As an independent developer, I had to learn many technologies, investigate unexpected failures, and repeatedly redesign parts of the system.
I'm also proud that Sarah continued evolving despite technical setbacks, eventually becoming the foundation for Sarah Nexus.
Although the autonomous AI recovery features are not yet complete, the project has progressed far beyond its original purpose.
What we learned
Developing Sarah taught me that creating reliable software is much more complicated than simply writing code.
I gained practical experience with Linux, bootable environments, hardware diagnostics, partition management, build automation, and software distribution.
I also learned how difficult it can be to maintain compatibility across different computers and firmware configurations.
One of my most important realizations was that detecting a problem is not the same as solving it.
This changed my approach to the project. Instead of focusing only on diagnostic tools, I started designing a system capable of collecting evidence, planning troubleshooting steps, and eventually assisting with recovery.
I also learned the importance of testing, safety controls, and being transparent about which features are complete and which are still experimental.
What's next for Sarah Nexus
My long-term ambition is to make Sarah Nexus a globally accessible computer diagnostics and recovery platform that people around the world can trust.
Security is one of my highest priorities. I understand the risks associated with software that boots directly from a USB drive and operates outside the computer's installed operating system. Such software may have extensive access to hardware, storage devices, firmware interfaces, and sensitive user data.
For this reason, I want Sarah Nexus to be designed with security at its core, rather than treating protection as an additional feature.
My plans include digitally signed releases, verified updates, strict permission controls, protected diagnostic evidence, encrypted logs, and carefully restricted access to potentially dangerous operations.
I also want the system to follow a safety-first approach: diagnostic operations should be read-only whenever possible, and potentially destructive actions should require explicit user authorization, appropriate safeguards, and verification.
As artificial intelligence becomes more deeply integrated, I want to ensure that Sarah cannot freely execute dangerous operations simply because an AI model suggests them. Sensitive actions must pass independent security checks.
My immediate priorities are stabilizing the bootable environment, developing reliable AI-assisted diagnostic workflows, and validating the system on real hardware.
My goal is to make Sarah Nexus available internationally, with multilingual support and a security architecture that users and technicians can confidently rely on.
I believe a powerful diagnostic tool should not only be capable of helping repair a computer — it should also be designed to protect the computer, its data, and the person using it.
These protections are development objectives and will require extensive testing and independent security validation before the platform can be considered ready for widespread use.
Log in or sign up for Devpost to join the conversation.