In April 2026, combotto.io is live as the focused direction for my work in IoT, embedded software, and Rust systems programming.
This update matters to me because Combotto is not a project that appeared overnight. It is the continuation of a longer direction I have been moving toward for several years, and I want that to be visible for people who follow my work through thomasbonderup.com.
This has been a long time in the making
Back in April 2022, I published Combotto – Aggregator Software, where I described Combotto as a new project connected to my work on aggregator software and virtual power plants, and that post was a direct extension of my master’s thesis, which I finished earlier that year.
The thesis focused on digital twin data modeling and IoT streaming telemetry for peak shaving in virtual power plants. In practical terms, it was about how connected devices, telemetry, and software models could be used to represent and coordinate energy assets more intelligently.
That matters as background because the original Combotto direction did not come out of nowhere. It grew out of real academic and technical work around connected systems, telemetry, and software for distributed physical infrastructure.
At that point, the direction was still centered much more narrowly around energy, digital twins, aggregator software, and virtual power plants. The April 2022 Combotto post was my first attempt to continue that thesis-related work into something longer-term.
What has happened since then is not that I abandoned that path. It is that the underlying technical interest became clearer and more mature:
- edge-to-cloud system design
- reliability in real distributed systems
- secure transport and operational hardening
- evidence-driven audit and remediation workflows
- practical systems programming for IoT infrastructure
That is the direction Combotto now represents.
The professional side of this is also not new to me. I worked full-time as a freelance consultant from August 2015 to August 2018, where I started out doing work such as web design and broader software-related client work.
What has changed over time is the direction of my specialization. As my skills developed through university, through my bachelor’s and master’s studies, and through work in telecom and secure communication, I moved much deeper into distributed systems, secure communication, and IoT-related software.
IoT was also not something I discovered only recently. It had already become a deeper specialization during my Datamatiker / AP Computer Science studies in Aalborg from 2013 to 2016, where I focused on robotics.
That direction continued when I moved from Aalborg to Odense in 2018 to complete my Professional Bachelor’s degree in Software Development. There, I went deeper into the systems side through coursework and projects around Linux environments, ROS and robot-oriented software, white-box testing in C++, microservice-style backend design, and later Kafka-based data systems. You can see that progression in the broader background I describe in Migrating an IoT Audit Engine from Scala (ZIO) to Java 21 + Spring Boot and in my Scalable IoT Data Streaming Platform for the Transportation Industry with Apache Kafka & Confluent Platform bachelor project.
That is why Combotto feels natural to me. It is not a random reinvention or a sudden jump in a new professional direction. It is a continuation of earlier client work and earlier technical specialization, now tightened much more intentionally around the IoT niche and edge-to-cloud systems.
What I have been building more deeply since August 2025
Since August 2025, I have been deliberately going deeper into IoT and embedded software rather than only talking about it at a high level.
Part of that shift has also been influenced by AI. As software becomes easier to build with the help of stronger AI tools, I think it becomes even more valuable to understand the hardware side better and to work more deliberately with hardware-software co-design in integrated systems.
That is one reason I have been spending more time strengthening my understanding of the stack below application software as well. Onur Mutlu’s online course material on digital design and computer architecture has been especially helpful here, because it has pushed me to think more clearly about the full stack from lower-level hardware fundamentals up through the software layer.
That has meant spending time on the parts that matter most when connected systems have to work in the real world:
- embedded Rust
- deeper hardware fundamentals
- sensor integrations
- secure device-to-cloud paths
- OTA update flow
- gateway runtime behavior
- auditability
- secure software development and vulnerability handling
I did not want Combotto to become a site built on generic positioning. I wanted it to be built on real work I had done myself and could explain in detail.
What I have built around Combotto so far
The main things I have built so far are concrete technical assets that support how I want to work long term.
1. From embedded learning into a real device path
One important shift for me has been moving from architecture interest into more hands-on embedded and device-level work.
I have been working with STM32-based hardware, learning Rust more deeply in an embedded context, integrating sensors, and building a fuller firmware lifecycle around my own device path. That has included secure boot assumptions, signed firmware, over-the-air updates, and getting telemetry from physical devices into the cloud.
I describe that part of the journey in more detail in Operational lessons from running an edge IoT gateway 24/7.
That work matters because it forced me to learn not only software architecture, but also the physical and operational realities behind IoT systems: sensor quality, reconnect behavior, certificates, message durability, and what actually happens once a device runs continuously instead of only during a local demo.
2. My own Rust-based gateway and the deeper system architecture behind it
From there, I built my own gateway as the boundary between device and cloud.
That work is described in Designing a Secure Rust-Based IoT Gateway: Architecture from Edge to Cloud, and it became a major turning point for how I think about my consulting direction.
The gateway work pushed me deeper into:
- Rust systems programming
- MQTT and edge-to-cloud messaging
- durable buffering and WAL-backed recovery
- observability with traces and metrics
- secure transport with TLS and mTLS
- runtime behavior on more realistic edge hardware
This is exactly the kind of systems work I want to keep doing: practical, close to the runtime, and grounded in how things behave under real failure conditions.
3. An audit engine to inspect my own work and make it more evidence-based
One of the most important next steps was building an audit capability that could inspect the kind of systems I was working on.
I wrote about that in Designing an Evidence-Based Audit Engine for IoT Security & Reliability.
The short version is that I wanted more systematic tooling and methodology for secure software development rather than ad hoc analysis and screenshots. I wanted an audit flow that could:
- collect technical evidence from real systems
- evaluate findings more consistently
- produce a prioritized backlog
- support reruns, deltas, and follow-up verification
That matters to me because it changes the work from “here are some thoughts” into a more disciplined path from evidence to findings to hardening.
4. Secure development, vulnerability handling, and compliance-oriented readiness
Another reason Combotto has become more focused is that I have increasingly been connecting the technical work to the security and compliance pressure real connected products now face.
That includes work around:
- SBOM and release evidence
- vulnerability handling workflows
- secure reporting paths
- more explicit secure software development lifecycle discipline
- practical readiness for NIS2-, CRA-, and buyer-driven security pressure
I wrote about that direction in IoT Cyber Resilience Act readiness: security reporting, release evidence, and verified fixes.
This is not because I want to turn Combotto into a generic compliance service. It is because I think more IoT systems work will increasingly sit at the boundary between architecture, runtime behavior, software supply chain evidence, and secure delivery discipline.
5. IoT field prototypes: from one device to three, and now toward sub-GHz telemetry
I also wanted proof of how IoT systems behave in more realistic field-oriented setups.
I am also a big believer in having my own hardware and IoT systems available in a laboratory-style environment where I can practice, make mistakes, and build hands-on experience by seeing how the systems actually behave.
That led to building and documenting a three-device field setup with a Raspberry Pi 5 gateway and STM32 devices, including a CO2 sensor path and a more realistic multi-device telemetry story. The clearest public example of that is Rust IoT Gateway Field Demo: Raspberry Pi 5, 3 STM32 Devices, MQTT/TLS Recovery.
That kind of IoT field prototype work matters because it is where reliability questions start to become real: identity, backlog growth, recovery behavior, and whether the evidence trail still makes sense after failure and return.
The current next step for me is practicing longer-distance telemetry with sub-GHz radio. I have described that direction in Planning a Longer-Range 868 MHz STM32 Telemetry Demo with SPSGRF-868 and Raspberry Pi 5.
That is the kind of progression I want Combotto to keep reflecting: not just cloud-adjacent software, but real device, transport, gateway, and evidence questions across the full edge-to-cloud path.
6. A focused site and delivery model
The visible packaging layer for all of this is the live combotto.io site itself.
It now presents Combotto as a focused home for this IoT systems direction with a clear delivery path:
- Audit
- Sprint
- Retainer
That matters because I do not want the work to stop at general advice or turn into open-ended hourly billing. I want it to follow a more structured consulting and freelance delivery model where each phase feeds into the next: practical, evidence-backed work that starts with an audit, moves into focused hardening or implementation sprints, and can continue into a retainer when teams need longer-term follow-through on security, reliability, and observability across the edge-to-cloud stack.
If you want the direct commercial entry point for that work, that is now the role of combotto.io and especially the IoT audit page.
7. Proof assets, technical writing, and reusable authority
Another important part of Combotto is that I have been turning real implementation work into reusable proof:
- technical blog posts
- architecture diagrams
- case studies
- audit/report examples
- field and gateway reference material
That is intentional. I want Combotto to be backed by visible engineering depth, and I want thomasbonderup.com to keep serving as a place where that depth can be explained more fully in a founder-led voice.
Another major shift: agentic-first development from November 2025 through mid-February 2026
Another important layer in this transition has been how I now build software.
In late November 2025, I discovered better AI models that gave me much more leverage than what I had been using before. Over the winter break, I practiced working in a more agentic way, and by mid-February 2026 I had moved much more seriously into agentic-first development with Codex.
That changed my workflow significantly.
Instead of treating AI as autocomplete or a chat window on the side, I started treating it as part of the development system itself:
- Codex paired with ChatGPT Pro as a serious implementation workflow
- multi-agent orchestration for bounded parallel work
- repo-specific SKILL.md workflows to keep execution repeatable
- Beads as the issue/state layer with Dolt-backed persistence
- PLAN.md, AGENTS.md, and specs as durable memory for future iterations
That has made a real difference in how quickly I can move from idea to implementation to verification.
I am not interested in using agents to produce more random output faster. I am interested in using them to improve development velocity while also making the process more structured:
- clearer planning
- more explicit issue tracking
- better handoff state
- tighter review loops
- more repeatable verification
- better security discipline in the development pipeline itself
In practice, this has become a meaningful part of why the Combotto work has accelerated. A lot of the current implementation work is now happening in an agentic engineering style, and I am actively exploring how to make that style safer as well as faster:
- how planning should work
- how review should work
- how multi-agent execution should be bounded
- how queue state and memory should stay trustworthy
- how the pipeline should stay secure as agentic engineering takes over more of the day-to-day development work
That shift may look separate from IoT on the surface, but for me it is not. It is part of the same longer-term direction: building difficult technical systems with more leverage, more structure, and a more deliberate engineering process.
How I now think about the split between these two sites
I want the distinction to be clearer going forward.
thomasbonderup.com is still my broader professional site.
It is the place for:
- broader architecture and software work
- founder context
- technical essays
- systems thinking
- longer-form reflections on reliability, design, and implementation
combotto.io is now the focused site for my IoT-related systems and systems-programming direction.
It is the place for:
- edge-to-cloud IoT systems work
- security, reliability, and observability audits
- hardening work tied to concrete findings
- proof and references related to connected systems
That means the relationship between the two sites is now much more deliberate:
- thomasbonderup.com shows how I think and the broader professional context
- combotto.io shows where that thinking is being concentrated for IoT work
My long-term direction
Looking ahead, I see Combotto as the main vehicle for my IoT-focused systems direction.
That includes work around:
- IoT security and reliability reviews
- gateway and edge architecture
- operational hardening
- evidence-based technical audits
- systems programming work where software quality and runtime behavior matter
So while thomasbonderup.com remains important to me as my broader professional presence, Combotto is where I am tying together the more specific direction I want to compound over the coming years.
If you are reading this from thomasbonderup.com
If you are coming to this site because you are interested in my broader work around software architecture, reliability, or technical direction, that still fits here.
But if your problem is specifically about IoT, connected devices, gateways, telemetry pipelines, or edge-to-cloud security and reliability, then combotto.io is now the most relevant next step.
That is where I am concentrating the more specialized part of my work, and I wanted this post to make that visible.
