Michelle Hoogenhout is the lead data scientist at Hydrostasis, an Edge Impulse customer company that is building a wearable personal hydration monitor to enhance human health.
As machine learning engineers, we're comfortable in the cloud. We have powerful GPUs, virtually unlimited memory, and the luxury of iterating quickly on complex models. But what happens when your business needs those models to run on a tiny device with constrained power, memory, and compute? That's the journey we embarked on in 2017 as a wearables startup focused on hydration monitoring for health and longevity.
We had reached significant milestones: a marketable product and satisfied customers. However, our next ambitious goal required a fundamental shift. We needed our hydration tracking algorithms to work anywhere, anytime — without relying on app connectivity or mobile networks. This meant moving our intelligence from the cloud directly onto the device itself.
If you're an ML engineer considering edge deployment, here's what we discovered during our transition from cloud-first to edge-native thinking.
Why We Chose Edge Impulse
Let's be honest about the reality facing many young startups: we're small, scrappy, and often can’t afford to add additional specialists, like a dedicated firmware engineer, to our teams. We needed to bridge the gap between cloud deployment and a working edge algorithm in a fast, flexible and cost-effective way.
Edge Impulse became our bridge across this chasm. The platform allowed us to continue developing models using the Python-based toolkits we knew and loved, while automatically generating optimized C++ packages for edge deployment. For most of our models, this eliminated the need to manually port algorithms or wrestle with embedded optimization techniques we hadn't mastered yet.
The key insight here isn't about any specific platform — it's recognizing when you need tools that can accelerate your team's unique constraints and capabilities.
Four Critical Lessons for Your Next Edge Deployment
1. Data Infrastructure: Your Future Self Will Thank You
What We Learned: The data practices that seem "good enough" during initial development become painful bottlenecks when you need to migrate to edge platforms or retrain models with different constraints.
The Problem: Our early data storage was inconsistent. Some datasets lived in different formats, labeling conventions varied across experiments, and preprocessing documentation lived in different places. This created friction every time we needed to import data to external platforms or adapt our models for edge-specific requirements.
The Fix: Establish rigorous, standardized processes for saving both raw and processed data from day one. Create clear naming conventions, maintain consistent data schemas, and document every preprocessing step. When you're working with sensor data destined for edge devices, this becomes even more critical because you may need to reconstruct your entire pipeline with different memory and compute constraints.
This investment in data infrastructure pays massive dividends later. Trust us — your future self will thank you when you can quickly adapt your datasets for new platforms or retrain models with different optimization targets.
2. Product Features vs. Model Performance: The Hidden Tradeoff
What We Learned: User experience optimizations can silently degrade your training data quality in ways that only become apparent much later.
Our Example: We implemented intermittent sensing to extend battery life — a clear win for customer experience. However, this created inconsistent and reduced sampling frequencies that made our training data less reliable. We had to aggregate data over longer time windows to maintain consistency, which affected model granularity and responsiveness.
The Broader Lesson: Product decisions and ML pipeline decisions are more interconnected than they initially appear. That feature that improves user engagement might be introducing data drift. The power optimization that extends battery life could be creating gaps in your training data that hurt model performance.
Recommendation: Create a feedback loop between your product and ML teams. Document how each product decision impacts your data pipeline, and maintain visibility into these tradeoffs during model development. Consider the ML implications early in product planning, not as an afterthought.
3. Go Beyond Metrics: Build Model Observability
What We Learned: Accuracy scores, precision, and recall are important, but they don't tell you why your models fail in the real world — especially on resource-constrained devices where failure modes can be different from cloud environments.
The Challenge: Edge devices introduce new variables that can affect model performance in ways that are not obvious to ML engineers used to cloud-first development. Temperature variations, power fluctuations, and hardware-specific quantization (model compression) effects can create unexpected failure and biases.
The Solution: Create systems that allow you to inspect actual predictions and failure patterns. Whether you're debugging why a regression model consistently overshoots in certain conditions or understanding which classes your neural network confuses most often, you need visibility into the model's decision-making process.
This is crucial for edge deployment because debugging on-device can be significantly more challenging than debugging in the cloud. Build observability tools that can help you understand model behavior before deployment, and create logging mechanisms that can capture edge-specific issues without overwhelming your device's resources.
4. Think Edge-First for Data Processing
What We Learned: Processing pipelines that run seamlessly in the cloud can become serious bottlenecks on edge devices, sometimes making the difference between a viable and non-viable product.
The Reality Check: Your Python preprocessing pipeline that casually loads entire datasets into memory and applies complex transformations won't work on a device with 256KB of RAM. The order of operations that seemed arbitrary in the cloud suddenly matters enormously when every computational step affects battery life.
The Strategy: If edge deployment is in your roadmap, design your data preprocessing with device constraints in mind from the beginning. This means:
- Considering memory usage at each preprocessing step
- Evaluating computational complexity with battery life in mind
- Testing whether your feature engineering approaches are feasible on embedded processors
- Designing preprocessing pipelines that can run incrementally on streaming data rather than batch processing
This doesn't mean you need to optimize prematurely, but it does mean maintaining awareness of edge constraints during your cloud development phase.
The Bigger Picture: Rethinking Your ML Pipeline
Edge deployment fundamentally changes how you think about machine learning systems. It's not just about model optimization or quantization — it's about redesigning your entire pipeline with resource constraints as first-class concerns.
In the cloud, we optimize for model performance and development velocity. On the edge, we optimize for the intersection of performance, power efficiency, memory usage, and computational constraints. This shift in thinking affects everything from data collection strategies to model architecture decisions to deployment pipelines.
Moving Forward: Start the Conversation Early
Whether you're in the early stages of considering edge deployment or facing an immediate need to move models on-device, the key is starting conversations about constraints and requirements early.
Begin by identifying your must-haves versus nice-to-haves. Understand the specific constraints you'll be working within — power budgets, memory limitations, computational capabilities, and latency requirements. These constraints should inform your development decisions long before you begin the actual deployment process.
Most importantly, recognize that edge deployment isn't just a technical challenge — it's a strategic shift that affects how you approach ML development from data collection to model design to deployment infrastructure.
The journey from cloud to edge taught us that successful edge ML isn't about cramming cloud models onto small devices. It's about embracing a different paradigm where constraints drive innovation and resource awareness shapes every decision. The result, when done well, is ML that's not just technically impressive but truly transformative for users who need intelligence wherever they are.