Yemaya
End-to-end product build for a climate-monitoring startup — from schema to shipping.
- Role
- Product strategy, data architecture, full-stack engineering, interface design
- System type
- Product engineering
- Disciplines
- Strategy · Design · Engineering · Operations
- Technology
- TypeScript, React, Postgres, Time-series data, Sensor ingestion, Geospatial mapping
Key challenge
Turn raw sensor feeds into a product a non-technical customer could act on — while building the whole thing, schema to interface, with a founding team and no legacy decisions to lean on.
The situation
A climate-monitoring startup had sensor hardware in the field and a compelling pitch, but no product: the data arrived as raw feeds, and everything between ingestion and a customer's screen still needed to exist.
The problem
The founding team needed a real, sellable product — not a prototype — built from zero. Data modelling, ingestion, storage, alerting, and the entire customer-facing interface had to be designed together, because at this stage each decision constrains all the others.
The constraints
Small team, hard deadline pressure from early commercial conversations, and sensor data that was messier than the pitch suggested — gaps, drift, and units that varied by device generation. The product had to absorb that reality without exposing it.
The system
Yemaya is the full product: an ingestion pipeline that normalises sensor feeds, a time-series data model designed for both live dashboards and historical analysis, alerting rules customers can configure, and an interface that makes environmental conditions legible at a glance.
Architecture
Sensor feeds land in a staging layer where they are validated, normalised, and gap-handled before touching the primary store. Postgres holds both the time-series readings and the product's relational model, keeping the operational stack small enough for a founding team to own.
Interface
The dashboard leads with the map and current conditions, lets customers drill into any sensor's history, and surfaces alerts as decisions rather than log lines. A pipeline status panel keeps the health of the data itself visible — because trust in the readings is the product.
Execution
Owned the build end to end: schema design, ingestion, API, frontend, and deployment. Worked directly with the founders to sequence the roadmap so commercial conversations could start before every feature existed.
Lessons
The most important architectural choice was the boring one — a conservative data model and a small stack. The product survived its first year of pivots because the foundation was easy to change, not because it was clever.
Outcome
The startup shipped a working product customers could put in front of their own stakeholders — live monitoring, alerting, and reporting — and gained a technical foundation designed to grow rather than be replaced.
Architectural insight
An early-stage product's real deliverable is optionality: every schema and interface decision either keeps the company's options open or quietly closes them.