Wove Tech IoT Platform

Overview

Wove Tech is an IoT and technology company focused on smart water protection and building infrastructure monitoring for multi-residential and commercial properties.

The system combines connected hardware such as leak sensors and smart shut-off valves, with a centralized application that enables early detection and automated response to water-related issues. The platform is currently in the testing phase, with a working MVP and ongoing end-to-end validation across real buildings and hardware setups.

My Role

As Co-Founder & VP of Software Engineering, I owned the software side of the product end-to-end, including frontend architecture, application structure, and code quality. I also led the development of a dedicated UI component library and worked closely with design and the broader team to shape key product and UX decisions. While the product direction was highly collaborative, I was responsible for establishing the technical foundation and ensuring the system remained maintainable and scalable as it evolved.

Challenge

The project required careful coordination between hardware and software to function as a cohesive system. While other co-founders focused on sensors, gateways, and device infrastructure, the challenge on the software side was to build an application capable of handling real-time device data while representing a structured hierarchy of buildings, floors, rooms, and devices.

At the same time, the product needed to be delivered as an MVP, with a limited feature set, evolving requirements, and future team growth in mind. Maintaining consistency across a separate component library and the main application added an additional layer of coordination, requiring continuous alignment and refactoring as patterns evolved.

Technical Focus

The frontend was structured around a clear separation between application logic, UI components, and data handling, allowing the system to remain predictable as features were added. A key part of the foundation was building a dedicated component library rather than keeping reusable UI elements inside the application. I extracted core elements — buttons, icons, device cards, and theme tokens — into a shared package, enabling consistent design and interaction patterns while keeping the main application focused on composition rather than implementation details.

State management and data flow were intentionally kept simple and predictable. Instead of introducing heavier state management solutions, the application uses focused Zustand stores for distinct domains such as authentication, UI state, and device data. Side effects and data synchronization are handled through custom hooks and service layers, keeping components largely presentation-focused and reducing coupling between UI and backend logic. The application integrates directly with Firebase services, using Cloud Firestore to model hierarchical building data and the Realtime Database to power live device updates on the dashboard. This architectural split reflects the system's two distinct needs: fast, reactive updates for critical device status, and a structured, queryable representation of buildings, floors, and devices.

To support maintainability, backend interactions were separated into service and transformation layers. Raw data from Firebase is transformed into application-level data models before reaching the UI, making it easier to evolve data structures and add new device types without introducing complexity into components.

Across the codebase, several decisions were made to keep the system scalable without over-engineering. Route configuration acts as a single source of truth for navigation and layout behavior, while shared layout patterns keep the structure consistent across views. Reusable components reduce duplication and keep the codebase easy to extend as the application grows. The overall approach prioritized clarity and adaptability, establishing a foundation that supports future development while keeping the MVP intentionally lean.

Product & Engineering Decisions

Several key decisions were shaped by real-world usage patterns rather than conventional technical defaults. One example was the notification strategy. Instead of relying only on push notifications, the system includes email and SMS notifications, recognizing that property managers are more likely to respond to SMS in time-critical situations.

On the product side, I made the decision to limit the initial feature set and focus on core functionality such as device visibility and status. Additional pages and features were intentionally deferred to maintain clarity and ensure the core experience worked reliably before expanding. This approach allowed the team to move quickly while keeping the system stable and understandable.

Outcome

The result is a fully functional MVP application that serves as the control center for the Wove Tech system.

The application supports real-time device monitoring, user preferences such as theme persistence, and a structured foundation for managing building and device data. Clients have already provided access to their properties for end-to-end testing in live buildings.

On the engineering side, the project established a clean and consistent codebase, a reusable component library, and clear architectural patterns that support future contributors and feature development.

Reflection

Building Wove Tech meant shaping a system from the ground up, with all the freedom and responsibility that comes with it. One key learning was the importance of aligning conventions early, especially when working across different development backgrounds. Some inconsistencies in naming and structure required later cleanup that could have been avoided with earlier alignment.

Another insight was around development strategy. Building a component library in parallel with the application required a higher level of coordination. In hindsight, establishing the application first and extracting reusable components later would have been more efficient.

Most importantly, the project reinforced the value of intentional simplicity. By focusing on a minimal, well-functioning set of core features instead of building too much too early, the system remained clear, maintainable, and well-positioned for future growth.