Services
Five ways to engage Telekinetik, across every service line below.
Full project. A defined problem, a defined deliverable, and Telekinetik owning the approach and execution end to end. This is the default.
Senior specialist augmentation. A senior engineer embedded with your team, when that fits the situation better than a fixed scope: an ongoing platform-ownership role, a development cycle that needs a resident architect, a program that runs too long for a fixed scope. Augmentation carries the same seniority floor and inclusion criteria as project work; we do not place generalist contractors.
Proof-of-concept and de-risking. We engineer the hardest, riskiest part of a build first, early and at low cost, so you know whether the full build will hold up before you commit a team and a budget. You get a working result you can run and measure.
Escalation and deep-debug. For a problem your team cannot crack on its own: the hard bug, the performance cliff, the intermittent field failure, the integration deadlock, the certification blocker. We find the root cause and fix it. A short, time-boxed triage can come first to scope the work.
Requirements and scoping. We turn a product idea into concrete, testable requirements, structured and ready to build from. Often the first step before a full project.
Linux Device and Gateway Engineering
BSP development and maintenance across Yocto, Buildroot, OpenWrt, Ubuntu Core (confined snaps), and AOSP. Board bring-up. Driver development through kernel modules, including read/write-to-registers work. Kernel migration and extension of the kernel TCP/IP stack for comms-to-network interfacing. OTA infrastructure: custom A/B-partition update mechanisms, Ubuntu Core Brand Store integration. Reverse engineering when documentation runs out, including the OpenWrt toolchain on one engagement.
Embedded application services built on top of the platform layer, grouped by theme:
Connectivity and resilience. Network services for robust modem connectivity with recovery modes, populating network and modem state into the system. Custom transport protocols where standard ones don't fit, including a UDP-based implementation with separated control and data planes.
System integration. Platform abstraction over /proc, /sys, kernel interfacing, and D-Bus into a single unified interface. UART communication between MCUs across both AOSP and Yocto. Cloud integration with AWS, Azure, and custom backends, including server-side work.
Operational substance. OTA with A/B partitions including Brand Store delivery. Power management covering wake locks, sleep modes, and power state transitions. Network stability observability. Configuration provisioning.
One integration example worth naming: an SPI master/slave key exchange between two MCUs, linked via an internal switch. For security, the actual communication runs over SSH. SPI is used to exchange public keys; SSH carries the protected traffic. It is a small example of how security and integration come together at the platform layer.
OTA and network need to be flawless. With those two right, you rarely need a technician in the field. The pattern that goes wrong: teams leave too many troubleshooting options on the device, and every one of them is a security surface. A maintenance tunnel can be the right tool, but it should be opened on demand, for a brief window, and closed again. Treating field debug access as a permanent fixture is how devices ship with a posture that would not survive a serious security review.
The founder has direct IEC 62304 Class B software development experience from an EEG diagnostic device program. Platform work can be aligned to the documentation and verification discipline IEC 62304 requires.
Secure-by-Design / CRA and NIS2 Readiness
The engineering work required to meet the EU Cyber Resilience Act by December 2027, and to operate under NIS2 supply-chain security obligations already in force. Specifically:
- Secure boot chain design and implementation
- Attestation and device identity infrastructure
- Certificate lifecycle management and PKI infrastructure. CMP (RFC 4210) via gencmpclient is one approach we have used in practice; the right solution depends on the product's deployment model
- SBOM generation, management, and tooling integration
- Supply-chain security: dependency auditing, reproducible builds, component provenance
- Vulnerability response infrastructure: disclosure process, update delivery, patch lifecycle
- OS and firmware hardening: kernel CONFIG-level hardening, immutable rootfs, signed packages, confined snaps (Ubuntu Core), SELinux configuration, iptables configuration, read-only filesystem
Every item above is build work, with a delivered artifact at the end. Where a gap assessment helps, it runs as the first phase of the build.
The most common mistake teams make on CRA readiness is treating SBOM as an end-of-project deliverable instead of a continuous build artifact. Modern package tooling makes pulling dependencies effortless, which is precisely the problem: packages and crates accumulate during development without anyone vetting them. By the time the SBOM is generated for compliance, the team is facing a list of unvetted dependencies and has to backfill security review under deadline pressure. The right configuration-management discipline is a pre-vetted internal repository (Artifactory or equivalent) that developers pull from. Pulling directly from public registries brings risk that compounds invisibly until SBOM time.
For US device makers
The CRA applies to every product sold in the EU market, regardless of where it was built. US OEMs with EU-distributed product lines face the December 2027 deadline without the in-house EU regulatory expertise that EU manufacturers have had years to develop.
There are three reasons US companies engage a Warsaw-based embedded partner for this work. Some lack the EU regulatory context and need a partner who already has it. Some have the depth internally but not the capacity to run a compliance program while a product cycle is also in motion. And some need specialist security engineering (secure boot architecture, PKI infrastructure, attestation systems) that is genuinely hard to hire for in the US market.
We work fully remote for US engagements. No European office or team required on your side.
Systems Programming for Network and Cyber
Linux kernel networking code, including TCP/IP stack extension for comms-to-network interfacing. Production eBPF and XDP program development and optimization. Custom dataplane software and packet-processing pipelines. Full MQTTv5 broker implementation. Hardened Linux distributions to a defined security posture. Custom telemetry and observability tooling. Userspace packet processing for troubleshooting. Network appliance software architecture.
Whether your product runs on specialized hardware or a commodity server platform, the engineering discipline is the same. This service line is not limited to embedded systems: telco infrastructure work, network appliance software, and cybersecurity product engineering that runs on x86 infrastructure is fully in scope.
A failure pattern that shows up consistently in Linux-based product work: access-control rules written too wide. SELinux policies, iptables, snap confinement, capability sets, teams configure them to make the system work, then leave them that way. The discipline of starting from deny-all and tightly scoping each allow rule is harder than blanket permission, so it gets skipped under deadline pressure. The device ships with a security posture too generous to defend at review time, and the team that wrote the original rules has rotated out by then. The right pattern is the discipline itself: deny-all by default, every allow explicit, every rule reviewed when it lands.
RTOS Product Engineering
RTOS architecture decisions, vendor-RTOS migration, firmware bring-up on new SoCs, scheduler and driver work for resource-constrained targets, and certification-aware design for products where a safety standard will apply. In-house depth on Zephyr and FreeRTOS. ThreadX, QNX, and VxWorks available for engagements that require them.
The reason to engage early: RTOS architecture decisions made at the start of a product's development propagate through its entire lifetime. Board abstractions, driver models, task structures, memory layouts, and IPC patterns are all harder to change later. Getting this layer right from the start is the cheapest decision a product company can make.
The in-house hardware-in-the-loop test rig lets us validate scheduling and timing behavior against system models without depending on the client's lab. This matters early in a program: it is faster to catch a priority-inversion bug in simulation than after the first hardware spin.
The founder has worked under ISO 26262 and ASPICE process discipline on Linux-based automotive systems, specifically an automotive gateway program. That work built the documentation, traceability, and verification discipline that ISO 26262 demands. That discipline is directly applicable to RTOS architecture engagements requiring safety-process rigor, regardless of whether the target is Linux or a microcontroller. Formal ISO 26262 training is completed.
For medical device programs under IEC 62304: the founder's IEC 62304 Class B experience was on an EEG diagnostic device. Architecture and documentation practice can be aligned to the standard from the start of the engagement.
Owning the full vertical
Embedded devices compute more at the edge every year. A modern endpoint aggregates, reasons, and displays on the device itself, which makes the application layer above the platform matter as much as the platform.
We own that layer. Business logic running on the device, data modeling and on-device analytics, inter-subsystem communication (the common pattern where one unit measures and another displays, with a protocol and data flow between them that someone has to specify and build), and the display layer in Qt or Android.
If you need the full vertical built once rather than coordinated across three vendors, we can take ownership of the whole thing, from BSP through application logic to the UI your field technician or operator sees.
On-site integration and commissioning
Some systems cannot be finished from a bench. A vessel system is commissioned at the quay and on sea trials. A factory-edge system is brought online on the production floor. A subsystem under a site acceptance test is proven where it runs. We are on site to integrate, commission, and troubleshoot the systems we engineered or integrated.
The Warsaw lab carries the bulk of bench work. On-site time is scheduled for the integration weeks, commissioning, and debug sessions that genuinely require presence. For US and global engagements, devices ship to the lab and we travel for the phases that cannot be done remotely.
Get in touch
contact@telekinetik.eu
+48 573 111 388
Describe the problem. We will tell you whether we can help.