slashwhy develops Linux applications and builds embedded Linux images for complex embedded systems.
slashwhy develops Linux applications for embedded systems and, when needed, builds the right embedded Linux image using Yocto as the build system. As your partner, we handle application development, image creation, and the integration of security requirements for companies that develop complex hardware products.
Embedded Linux is a Linux operating system tailored to embedded systems. It runs on resource-constrained hardware and is built for devices that need to perform a defined task reliably, sometimes for years without a restart.
Embedded Linux makes sense when a device handles multiple tasks in parallel, accesses complex hardware, or needs a demanding application layer. For tight real-time requirements or very limited resources, bare metal firmware or a real-time operating system (RTOS) is often the better choice.
At slashwhy, security is part of the architecture from the start. For connected devices, the Cyber Resilience Act (CRA) sets concrete requirements: signed updates, encrypted data, a secured boot process. You can't bolt this on afterwards, so we account for it from the very first sprint.
Embedded Linux is a core part of our embedded services and of our overall portfolio for custom software development. Devices running Linux often also need a user interface, a cloud connection, or a well-thought-out user experience. That's why slashwhy's embedded experts are part of an interdisciplinary team with solid expertise in areas such as graphical user interfaces, IoT & cloud, and UX & UI design.
Interested? Then you'll find everything you need to know about slashwhy as your embedded Linux development partner right here on this page.
Your starting point
Companies come to slashwhy from very different starting points. Some have already chosen embedded Linux and need a development partner to handle the implementation, from Linux application development to the finished system image built with Yocto. Others are still facing the architecture decision, whether Linux, RTOS, or bare metal, and want to make that choice on a solid technical basis. In both cases, slashwhy brings the experience needed to make these decisions soundly and move them straight into development.
Just as often, customers come to us with an existing product. A prototype works but isn't production-ready yet. A proven device is set to be connected and suddenly needs an update concept and a security architecture. Or the in-house team is too small to deliver the roadmap at the planned pace. slashwhy steps in across all these situations, as a complete development team or as an extension of an existing one. The most common starting points are:
slashwhy develops applications that run on embedded Linux. These are standalone Linux processes with isolated memory regions, defined resource limits, and a clear responsibility within the overall system. Unlike bare metal firmware, a Linux application is largely hardware-independent and can be reused on other Linux-based systems. We develop in C, C++, and Rust, integrate existing open-source libraries, and make sure applications run reliably, even when other processes access the same resources.
slashwhy builds embedded Linux images with the Yocto Project. Yocto is our standard, not Buildroot, not a self-assembled system. The reason: Yocto produces reproducible builds, supports a wide range of hardware architectures, and can be configured precisely through a structured layer model. On top of that, Yocto automatically generates a Software Bill of Materials (SBOM) and checks open-source licenses, both mandatory under the Cyber Resilience Act (CRA). You get an image that another team or another partner can keep building on without any onboarding, or we take it seamlessly into our own development team.
Security can't be bolted onto an embedded Linux system afterwards; it has to be part of the architecture from the start. slashwhy accounts for secure boot, data encryption, and signed updates from the very first sprint. For connected devices, this has been a legal requirement since the Cyber Resilience Act. That includes an automatically generated SBOM, a documented update path, and a secured boot process. These are all components that slashwhy delivers as standard.
Devices in the field have to stay updatable, securely, reliably, and without production downtime. slashwhy designs and implements over-the-air (OTA) update concepts based on A/B partitions: at any point in time, there is a working image on the device, so a failed update causes no downtime. The update infrastructure itself sits on the customer's side. slashwhy implements the update mechanism on the device and makes sure it works with the existing or planned infrastructure.
All source code written by slashwhy, including tests, build scripts, and the system images for the respective hardware, belongs to the customer. That's not a given in this market, but for slashwhy it's standard. The customer can keep developing the code in-house or continue it with another partner, with no dependency on slashwhy. On request, we support the handover with documentation and targeted knowledge transfer to the in-house team.
Programming languages: C, C++, Rust
Build systems: Yocto Project, Buildroot (prototypes)
Debugging & profiling: GDB, Valgrind, perf, strace
Communication interfaces: Ethernet, Wi-Fi, Bluetooth, USB, UART, I2C, SPI, CAN
Protocols: MQTT, REST, OTA/FOTA
Security: Secure Boot, SBOM generation, SELinux, data encryption
We often get inquiries from companies that have already decided on embedded Linux and simply need someone to implement it. But just as often, customers come to us who don't yet know whether Linux is even the right choice. Both are a good starting point for us. The technology decision is part of our work, and we're happy to help with it.
Dr. Joachim Wilharm
Managing Director at slashwhy
Our development standard
Building an embedded Linux image is a process: source code has to be downloaded, compiled, and assembled in the correct dependency order. The result is a file system that gets packaged into a flashable image, including the bootloader, kernel, and all applications. On top of that come license checks, SBOM generation, and scanning for known security vulnerabilities. If you attempt this without a structured build system, you end up with a home-grown project that hardly anyone but the original developer can maintain.
That's why slashwhy relies on the Yocto Project in many projects. Not Buildroot, not a self-assembled toolchain. Yocto produces reproducible builds: the same input always yields the same output. Library updates are deliberately not applied automatically. This is a controlled, manual step that prevents a dependency update from changing system behavior unnoticed. The layer model makes the system highly configurable and, at the same time, portable. If you want to carry on after a project with another partner or your in-house team, you'll quickly find your own Yocto developers on the market.
Yocto also automatically generates a Software Bill of Materials (SBOM) and checks open-source licenses. Both are mandatory under the Cyber Resilience Act. Buildroot can make sense for early prototypes when speed matters. For production systems, Yocto is the right choice.
slashwhy regularly works as an extension of existing teams. We adapt to existing processes, tools, and communication channels. How close the collaboration is depends on the project: some customers want a self-contained team that takes over a defined part. Others want daily exchange at the developer level. Both work. It works best within the same cross-functional team, with short lines of communication and nothing getting lost in the hand-offs.
slashwhy doesn't take on hardware development. The boards we develop on should already be commissioned by the manufacturer. Beyond that, we need a clear picture of the product and its requirements. A finished specification isn't a prerequisite, but a shared understanding of the goal and the overall constraints is. If you're still facing the architecture decision, you can start there too.
The customer receives the complete source code and can keep developing it in-house or with another partner. Follow-up projects for new features, bug fixes, or platform migrations are possible, but not required. slashwhy deliberately develops in a way that keeps you independent: clean documentation, established tools, reproducible builds with Yocto.
The complete source code, including tests, build scripts, and documentation, belongs to the customer. On request, we support the handover with a structured knowledge transfer: code reviews, documentation of architecture decisions, and joint sessions with the in-house team. If you want to keep developing in-house, you can do so without any onboarding effort.
Yes. At slashwhy, embedded Linux is part of a larger portfolio. For the user interface, we have experts in graphical user interfaces; for cloud connectivity and IoT integration, our IoT & cloud experts; and for the user experience, our UX & UI design team. If you want everything developed under one roof, you don't have to coordinate several different partners.
Nice to know
In embedded Linux projects, a lot of energy goes into system startup and boot time. A clean shutdown, on the other hand, regularly gets attention too late. Yet a missing shutdown concept has concrete consequences: file systems that aren't closed correctly can leave inconsistent data behind at the next startup. Processes that aren't terminated cleanly block resources or leave lock files behind. On devices in the field that are switched off by cutting the power, these errors can be hard to reproduce and expensive to debug. A well-thought-out shutdown concept should therefore be a fixed part of every system architecture.
Our approach
Every embedded Linux project is different. Some customers come with a clear specification and finished boards. Others are still facing the architecture decision or have a prototype that isn't production-ready yet. slashwhy develops in an agile, iterative way, in short sprints with regular customer feedback. The following process describes our basic approach; the specific shape it takes always depends on the project, the hardware, and what's already in place on the customer's side. What stays constant: you're actively involved in every phase, and the product takes shape iteratively, in dialogue.
1 | Kickoff and architecture decision
Together, we clarify what the product needs to do, what hardware is available, and what requirements exist for resources, connectivity, and the runtime environment. On that basis, we decide: embedded Linux, RTOS, or bare metal, or a combination? If you've already made a decision, you get a verification. If you're not sure yet, you get a reasoned recommendation.
2 | Setup and system architecture
slashwhy sets up the development environment, establishes the Yocto base, and defines the system architecture. Which processes run on the system, how are memory regions isolated, how do applications communicate with each other? These decisions are made once and have consequences for the entire course of the project. A clean foundation here saves considerable effort later.
3 | Iterative development with continuous testing
Development runs in sprints. Tests are written in parallel with the implementation, not only at the end. Unit tests and integration tests catch errors early. At the end of each sprint, there's working software running on real hardware. The customer tests regularly and gives direct feedback. Requirements that change flow into the next sprint: no waterfall, no brief-and-wait.
4 | Handover, documentation, and next steps
The customer receives the complete source code, including tests, build scripts, and system images. Everything is ready for further development in-house, together with slashwhy, or with another partner. If the product also needs a user interface, a cloud connection, or a well-thought-out UX, slashwhy takes that on without things getting lost at the hand-offs between different partners.
A memory leak that only shows up after weeks of operation? A process that isn't terminated cleanly at shutdown? An OTA update that introduces bugs that weren't there before? Embedded Linux systems often run for years without a restart. Errors that go unnoticed during development get expensive later in the field. That's why, at slashwhy, testing is a fixed part of every iteration.
Intuitive operation through a modern UI matters a lot to us. Our customers shouldn't have to wrestle with the technology, they should have fun with the products and the application.
Oliver Kortekamp
Team Leader & PO at Oase
We always feel that slashwhy takes ownership of the product. Everyone involved fully identifies with it. That's different with other service providers.
Dr. Melanie Schuh
Product Management at W&H
With slashwhy, we have a partner that doesn't just deliver code, but supports the entire process from concept to implementation, a partner that identifies with the product and actively improves it.
Friedrich Laube
Director Digital Products & Services Smart Home at Miele
The agile mindset of everyone on the slashwhy project team is impressive and contagious in the best way. We work with slashwhy as equals in agile project teams and reach our goals together, faster.
Markus Rose
Director CHARX control Division Charging Infrastructure at Phoenix Contact
The big benefit of the solution we developed with slashwhy is that we can continue developing our production products in parallel with new development projects.
Axel Schröder
Director Advanced Engineering at CLAAS E-Systems
We can save a completed commissioning in the app and, especially on large construction projects, reuse that template again and again to set up identical gates. That's a clear advantage and a real benefit of the app.
Tobias Lange
Projectmanager at Hörmann
Working with us
We build software by people, for people. And all these people have very different needs. Users want to get their tasks done efficiently; our customers want to create real value. And us? We want to build software that solves real challenges, simplifies everyday life, and is fun to use.
Global players and hidden champions
Embedded Linux runs in very different products that, at first glance, have little in common: industrial HMI panels, medical diagnostic devices, agricultural control units, and connected home appliances. slashwhy brings not only the technical expertise but also the domain knowledge needed to correctly assess requirements for reliability, safety, and regulatory compliance from the start. That's why market leaders like Phoenix Contact, CLAAS, and Miele rely on working with slashwhy.
In industry and HealthTech, long-term availability, secure OTA updates, and regulatory requirements are at the forefront of embedded Linux development. In AgriTech and CleanTech, devices are created that have to work reliably under harsh conditions and with long service intervals. In Consumer Electronics and Building Technology, our embedded team works directly with the in-house experts for graphical user interfaces. Here, the Linux application layer and the HMI are created in a single development process.
With bare metal, only your own code runs on the controller: no operating system, no process management. An RTOS adds a thin layer that manages tasks and guarantees real-time behavior. Embedded Linux takes a different route: the Linux kernel handles hardware initialization, process management, and memory isolation. Applications run as standalone processes with clearly separated memory regions. This makes Linux more powerful and flexible, but also more resource-hungry. If you have hard real-time requirements or are working with very limited resources, an RTOS or bare metal is often the better fit.
Technically, Android is a Linux system, but it comes with a complete application framework, an app store mechanism, and a UI layer that leaves you little freedom. That makes sense when a product needs consumer apps, touch interfaces, or Play Store access. For industrial controllers, field devices, or systems without a display, pure embedded Linux is the leaner and more controllable choice. slashwhy develops on embedded Linux. For Android-based products, we refer you to specialized partners.
That depends heavily on the scope of the project: whether a finished Linux image already exists or is built from scratch, how complex the application layer is, and how many iterations it takes to reach production readiness. At slashwhy, embedded Linux projects typically start with a workshop or a joint architecture phase in which effort and scope are assessed concretely. We're happy to put together a solid quote after a no-obligation conversation.
For production systems, Yocto is the right choice. It produces reproducible builds, supports a structured layer model, and automatically generates an SBOM along with a license check. Buildroot is easier to set up and can make sense for early prototypes, but in the long run, Yocto is the better system. It's more widely supported, better documented, and established on the market: if you're looking for Yocto developers, you'll find them quickly. If you leave behind a self-assembled build system, you create a dependency.
That varies considerably. A project that builds on an existing Yocto base and develops a clearly defined application can be production-ready in a few months. A greenfield project with new hardware, a complex application layer, and CRA security requirements takes considerably longer. What matters is when the customer first sees working software on real hardware: at slashwhy, that always happens after the first sprint.
Do you already have a concrete project idea and want to find out whether slashwhy is the right partner for your embedded Linux development? Or are you still at the beginning of your journey and looking for the ideal starting point? Either way, our team of experts looks forward to hearing from you and is on hand for a no-obligation consultation.
slashwhy is a software development company with locations in Osnabrück, Hamburg, Bielefeld, and Kiel, developing custom software for complex hardware products. Embedded Linux development is part of our embedded software portfolio, which covers firmware development, real-time applications, IoT & cloud integration, and graphical user interfaces. The embedded area, in turn, is one pillar of our overall portfolio, which ranges from UX & UI design and application development to AI-driven solutions. Companies developing a complex embedded Linux system find in slashwhy a partner that handles all disciplines under one roof.
slashwhy develops Linux applications for embedded systems and, when needed, builds the right embedded Linux image with the Yocto Project as the build system. Yocto ensures reproducible builds, automatic SBOM generation, and open-source license checks. These are requirements that the Cyber Resilience Act mandates for connected embedded Linux devices. We make the choice between embedded Linux, RTOS, and bare metal together, based on concrete requirements for hardware architecture, resources, and the runtime environment. Secure boot, data encryption, signed OTA updates, and system hardening are fixed parts of embedded Linux development at slashwhy.
Embedded Linux projects at slashwhy run iteratively. The customer tests regularly on real hardware, and requirements can change without putting sprint results at risk. All source code, including tests, build scripts, and Yocto layers, belongs to the customer. slashwhy develops embedded Linux systems for companies in industry, HealthTech, AgriTech, CleanTech, Consumer Electronics, and Building Technology, from hidden champions to global players like Miele, CLAAS, and Phoenix Contact.
