[{"_1":2,"_111":-5,"_112":-5},"loaderData",{"_3":4,"_85":-5,"_86":87},"root",{"_5":6,"_7":8,"_9":10,"_11":12,"_13":14,"_70":71,"_15":72,"_73":74},"cart",["P",6],"isLoggedIn",["P",8],"footer",["P",10],"footerCustomData",["P",12],"header",{"_15":16,"_30":31},"shop",{"_17":18,"_19":20,"_21":22,"_23":24,"_27":28},"id","gid://shopify/Shop/63092686899","name","SomnusLab","description","Optimal sleep. Powered by science.","primaryDomain",{"_25":26},"url","https://checkout.somnuslab.com","brand",{"_29":-5},"logo","menu",{"_17":32,"_33":34},"gid://shopify/Menu/205641809971","items",[35,46,54,62],{"_17":36,"_37":-5,"_38":39,"_40":41,"_42":43,"_25":44,"_33":45},"gid://shopify/MenuItem/488273707059","resourceId","tags",[],"title","Home","type","FRONTPAGE","https://checkout.somnuslab.com/",[],{"_17":47,"_37":48,"_38":49,"_40":50,"_42":51,"_25":52,"_33":53},"gid://shopify/MenuItem/506275561523","gid://shopify/Product/7592254734387",[],"Sleep Pad","PRODUCT","https://checkout.somnuslab.com/products/somnus-lab-sleep-pad-us-version",[],{"_17":55,"_37":56,"_38":57,"_40":58,"_42":59,"_25":60,"_33":61},"gid://shopify/MenuItem/512561184819","gid://shopify/Blog/88682463283",[],"Blog","BLOG","https://checkout.somnuslab.com/blogs/blog",[],{"_17":63,"_37":64,"_38":65,"_40":66,"_42":67,"_25":68,"_33":69},"gid://shopify/MenuItem/512561217587","gid://shopify/Page/130659811379",[],"About","PAGE","https://checkout.somnuslab.com/pages/about",[],"publicStoreDomain","5zthtm-rd.myshopify.com",["P",72],"consent",{"_75":76,"_77":78,"_79":80,"_81":82,"_83":84},"checkoutDomain","checkout.somnuslab.com","storefrontAccessToken","4f5d6b85a26f3cc97a3b611daa56b7e1","withPrivacyBanner",false,"country","US","language","EN","routes/($locale)","routes/($locale).blogs.$blogHandle.$articleHandle",{"_88":89},"article",{"_90":91,"_40":92,"_93":94,"_95":96,"_97":98,"_100":101,"_109":110},"handle","from-firmware-to-cloud","From Firmware to Cloud, Code to Bedside","contentHtml","

We like to share not just what we're building, but a bit of how we think — we believe it's a good way to communicate with the community and build something that lasts. In this article, I'm sharing a few thoughts on how we approached technology on the software/firmware side, with reasonings and examples of how we made some of the key technical decisions.

Why our definition of \"full stack\" wasn't full enough—until we built a physical product

We used to call ourselves full-stack developers.

We could move from frontend to backend, work on the database layer, optimize data pipelines, and even push into algorithm design. That felt like the whole universe.

Until it wasn't.

When we started Somnus Lab, we realized something big: all those things we thought were \"full stack\" existed in a bubble—a bubble built on top of layers we never truly touched. We were shipping code into the cloud. Now we had to ship to a piece of device people would actually sleep on.

Embedded programming. Firmware. Hardware. Thermodynamics. Timing crystals. PCBs. Pumps.

All those things we barely glanced at in university textbooks? We never expected to ship them. Suddenly, we had to. And not just individually—we had to connect them into a coherent chain that couldn't break.

That chain was way longer than we thought.

And here's the kicker: we didn't want to rewrite the universe from scratch. We didn't want to drop into assembly. We didn't want to write deeply inefficient low-level code just to track the sleep mode of a water pump.

We still believed in clean abstractions. We still believed in developer experience. We just had to bring those beliefs lower into the stack.

Turns out, the stack goes deeper. And longer.

🛠️ So We Built a New Stack

When we first mapped out the Somnus Lab Sleep Pad, we realized we weren't just designing a product — we were designing an ecosystem.

Suddenly, the data flow we needed to handle was no longer a neat loop from frontend to backend and back. It became a long, physical-to-digital chain that stretched across layers we'd barely touched before.

Here's what that chain looked like:

\nCapture the world. We needed to collect raw data from a range of sensors: temperature, motion, heart rate, heart rate variability (HRV), respiratory rate, and snore detection.
\nProcess at the edge. We couldn't just stream everything to the cloud — we had to process key signals locally on the device to make instant decisions: adjust the pump speed, stabilize temperatures, or respond to movement, all without needing a cloud handshake.
\nSend it upstream. Once the important data was distilled, it traveled over MQTT, a lightweight messaging protocol that's perfect for low-bandwidth, reliable communication between devices and the cloud.
\nOrchestrate the backend. On the server side, we ran classic backend services to store data, manage user profiles, run analytics, and keep everything in sync.
\nDelight at the surface. Finally, we surfaced all this in a mobile app that gave users real-time insights, controls, and a sense of confidence over their sleep environment.

Key data flow of Somnus Lab Sleep Pad:

The No-Internet Rule

One of our non-negotiable principles: the system must not depend on the internet to keep you safe and comfortable.

It's pretty dumb (and frankly unacceptable) if your bed keeps blasting heat or freezing cold just because your router goes down or your Wi-Fi is spotty. So we engineered the system to fail gracefully and work offline, keeping core functions running locally even when cloud connections are unavailable. That's not just a technical choice — it's a user trust decision.

And here's another reason it matters: Many people now deliberately have a no-internet rule in the bedroom. They turn off their Wi-Fi after 10 p.m., not because they live off the grid, but because they choose to protect their sleep space — even if they still have 5G on their phones. For a product designed to optimize sleep, respecting that choice isn't just thoughtful — it's essential.

Rethinking \"Full Stack\"

What started as a hardware project turned into an end-to-end system that spanned sensors, firmware, network protocols, cloud services, and user-facing apps.

We had to blend embedded constraints with modern software practices — edge computing, state management, modular architecture, and adaptive control loops.

In short: We didn't just build a device. We built a stack that redefined what \"full stack\" really means — and added resilience as a first-class feature.

💡 Why MicroPython?

We were trying to avoid battling low-level languages just to move fast. We didn't want to feel like we were writing drivers just to blink an LED.

In our past life, we came from the Ruby on Rails world.

We built apps fast, deployed on Heroku, and felt spoiled. Clean syntax. Sensible defaults. Convention over configuration. It just worked.

So naturally, when we started working with embedded systems, we joked:

\n
\"Wouldn't it be nice if there were a MicroRuby?\"
\n

But alas—no luck.

We settled on MicroPython—and to be fair, it's pretty amazing.

Yes, the Python 2 vs 3 saga still gets chuckles (and groans). But jokes aside, Python has earned its place at the center of AI and automation. For embedded prototyping, MicroPython is light, expressive, and just powerful enough.

We chose it because it gave us:

High dev velocity
Familiar syntax
Real-time execution on ESP32
The flexibility to build abstractions on top—like our state layer

So we leaned in. And built a framework on top of it.

Ps: We've even considered contributing back to MicroPython—it's still maintained by just a few devs in Australia.

🔄 Why We Needed State Management

Sleep isn't static. The temperature you want at 10:30 p.m. is not what your body needs at 4:00 a.m. or 6:45 a.m.

Our system needed to:

Follow scheduled temperature curves\n
Sync in real time between user, app, and hardware
Recover gracefully from disconnects or power glitches
Allow manual overrides without breaking things
Adapt to user behavior over time via AI-driven personalization\n

We needed a framework that could model transitions, edge cases, and sync rules across components.

So we built our own Redux-inspired state management system, in MicroPython. It's lightweight, predictable, and designed for the unique constraints of firmware.

🔧 Why We Deleted Kubernetes

At first, we went full infra muscle memory:

AWS EKS
Kubernetes clusters
EMR pipelines

Why? Because we could.

We'd spent years building for systems with millions of users, global rollouts, and real-time personalization. Setting up K8s was reflexive.

But soon we realized:

We were burning $500/month before launch
We wouldn't need that much concurrency for a long time
The mental overhead wasn't worth it

So we ditched it.

And went back to something that used to spark joy: Heroku.

Yes, it's been quieter since Salesforce acquired it. But it's still stable. It still works.

And for now, it's perfect for our backend needs.

Sometimes, the boring thing is the best thing—especially when it ships.

Thanks for following along — we're excited to keep sharing what we're learning as we build, experiment, and (hopefully) make sleep a little better for everyone.

🔜 What's Next

We'll soon update to share on: \"How We Built Redux for MicroPython\"?

","publishedAt","2025-08-01T09:25:25Z","author",{"_19":99},"weiyan shao","image",{"_17":102,"_103":-5,"_25":104,"_105":106,"_107":108},"gid://shopify/ArticleImage/127797198899","altText","https://cdn.shopify.com/s/files/1/0630/9268/6899/articles/003.jpg?v=1756789302","width",3104,"height",2070,"seo",{"_21":-5,"_40":-5},"actionData","errors"]