/lm.png
Fractional CTO for Hardware-Enabled SaaS & Operations
Helping founders ensure their technology can handle the chaos of real-world operations.
I connect Physical and Digital Assets to deliver Business Outcomes.

Iteration isn't the problem. Uncontrolled iteration is.

This diagram illustrates a pattern I see in hardware-enabled SaaS initiatives. You start with initial requirements and an (optimistic) roadmap. Then reality shows up: ❌ The field data disagrees. ❌ Ops workflows change. ❌ Customers/stakeholders ask for “just one more adjustment." ❌ The team constantly refactors APIs, reshapes the data model, rewrites logic, etc. Each iteration does improve the product… …but it also creates iterative debt: leftover code paths, half-migrated schemas, compatibility layers, rushed fixes, duplicated logic.

Infrastructure Drift usually indicates an issue.

In a properly managed environment, the delta between your Infrastructure-as-Code (IaC) and your actual cloud environment should be zero. When your monitoring solution triggers a drift alert (you do have automated drift detection, right?), it typically points to one of two scenarios: 🔴 Scenario A (The Rogue Operator): Someone bypassed the governance and manually modified resources in the AWS Console. This is problematic as manual actions are error-prone and hard to track (and even harder to revert).

Building a simple home automation system is very rewarding, but only for a short moment.

Recently, I created a simple solution that automatically turns the hall’s light on and off. Yes, I know, nothing fancy, but please don’t stop reading just yet. I could have bought a lamp with that functionality built in, but that simple solution had several shortcomings: Searching for a lamp that matches the hall design. Fitting the new lamp in the same spot. What about my other lamps? Upgrading a single piece of hardware does not improve the overall user experience, as legacy devices remain non-smart.

How to Actually Disconnect a Device from AWS IoT Core

There are various cases when you need to disconnect a specific device from your IoT system. An attacker might have compromised that device. Maybe the device started behaving strangely and you want to isolate it until you investigate. Or perhaps your customer stopped paying and you need to suspend service until they clear the debt. Here’s the thing: disconnecting a device from AWS IoT Core is not as simple as one might think.

How I Became a Full-Stack IoT Developer

Here’s the thing - I didn’t plan to become a full-stack IoT developer. It just happened, one AWS service at a time, one project at a time, one challenge at a time… It Started with AWS IoT Solutions My journey began with designing and building AWS IoT solutions for real-world deployments. I wasn’t just reading documentation - I was experimenting, connecting thousands of devices to the cloud, managing their lifecycle, and ensuring secure communication at scale.

The Hidden Security Risk When Deleting AWS IoT Things

You just finished testing your IoT device. Time to clean up. You navigate to AWS IoT Console, find your Thing under Manage → All devices → Things, and hit delete. Done, right? Wrong. Here’s the thing: deleting an IoT Thing only removes the logical representation of your device. The certificate (your device’s proof of identity) remains active with policies attached. That’s a security hole. What Actually Happens When you delete a Thing in the AWS console, you’ll see a helpful summary of related resources.