diff --git a/src/content/blog/2026-05-11-modbus-vs-eebus-spine.md b/src/content/blog/2026-05-11-modbus-vs-eebus-spine.md
new file mode 100644
index 0000000..5efe6cf
--- /dev/null
+++ b/src/content/blog/2026-05-11-modbus-vs-eebus-spine.md
@@ -0,0 +1,44 @@
+---
+title: "Modbus TCP vs. EEBUS SPINE: A Technical Comparison for Device Architects"
+description: "Every device architect I talk to already knows Modbus. That's precisely where the comparison gets interesting."
+publishDate: 2026-05-11
+author: "David Aragón"
+tags: ["EEBUS", "Modbus", "IoT", "protocols", "energy-management"]
+category: "technical"
+featured: true
+draft: false
+---
+
+*Originally published on [LinkedIn](https://www.linkedin.com/pulse/modbus-tcp-vs-eebus-spine-technical-comparison-device-arag%C3%B3n-galiana-qagje/)*
+
+Every device architect I talk to already knows Modbus. That's precisely where the comparison gets interesting.
+
+## Protocol vs. Data Model
+
+Modbus TCP is a communication protocol. SPINE is a data model with communication semantics. Mixing those two categories is where most evaluations go wrong.
+
+In Modbus, **meaning is external**. Register 40031 might hold the current setpoint temperature on one manufacturer's heat pump. On another manufacturer's product, that same value lives in a different register entirely. The register map lives in a vendor PDF, and every integration is a one-off mapping exercise.
+
+In SPINE, **meaning is in the protocol**. A `HeatPumpAppliance` entity exposes features with defined data types and semantics. The EMS doesn't need a vendor manual to understand what `operationMode` means: it's specified, discoverable, and identical across every EEBUS-compatible manufacturer.
+
+## Communication Model: Polling vs. Subscription
+
+The communication model is also inverted. Modbus is **polling-based**: your EMS asks, the device answers, on a schedule you define. SPINE is **subscription-based**: you subscribe to the features you care about, and the device notifies you on change. For real-time energy coordination, the difference in latency and network load is noticeable.
+
+## Security
+
+Security is another axis. Modbus TCP has none natively. SHIP, the transport layer EEBUS runs on, includes TLS and device pairing as defined components of the spec, not optional additions.
+
+## The Complexity Trade-off
+
+The tradeoff is real: SPINE is more complex upfront. The data model takes time to internalize, and the SHIP pairing flow alone has caught more than one integration team off guard.
+
+But the comparison isn't Modbus complexity versus EEBUS complexity for one device. It's **Modbus complexity per device, per manufacturer, per firmware version**, versus **EEBUS complexity once**.
+
+## Why "Once" Matters
+
+That "once" is where the stack choice matters. We built the KEO stack with both SHIP and SPINE fully abstracted: no pairing flow to implement, no data model to interpret, no spec ambiguity to chase down. The integration starts at the use case level.
+
+---
+
+If you're stuck on a SHIP pairing issue, a SPINE feature that's misbehaving, or sizing up the build-vs-buy decision for an EEBUS stack, feel free to reach out. Always up for comparing notes.