Flower Bridge is a cloud platform connecting distributed energy assets to the Swedish electricity market, handling contract lifecycle with the market operator, grid-frequency prequalification with SvK, real-time power dispatch, and multi-partner asset onboarding.
My contribution to this project is a deliberate step into software and backend engineering, a domain extension beyond my core GNC background. I joined at an early stage of the product and contributed to specific areas: the full market operator integration, the asset onboarding state machine, and the operator dashboard. Across the wider platform I contributed to prequalification reporting, power dispatch, and infrastructure, working alongside the broader engineering team.
On the prequalification side I worked on the SvK-formatted CSV reporting pipeline in Go: data extraction via SQLC queries, field mapping to the grid authority's schema, and file generation for the data quality artefacts submitted to Svenska kraftnät. On the real-time dispatch side I contributed to the mFRR power allocator and MQTT publish frequency scaling for dispatch signal throughput. Infrastructure contributions included JWT token validation middleware for internal service authentication and HMAC-SHA256 request signature verification on inbound webhook endpoints, ensuring only authenticated partner callbacks are processed.
I worked on OEM partner API integration for new inverter brands: defining HTTP REST integration contracts, webhook callback shapes, and control logic mapping so new hardware partners can connect to the platform's market control layer. The integration receives telemetry over REST, normalises it into a unified internal data model, and translates outbound commands to each partner's specific API interface.
Bridge introduced domains I had not worked in directly before.
On the integration engineering side: building inbound webhook receivers with HMAC validation, designing idempotent event pipelines that handle retries and out-of-order delivery, writing backfill jobs for external systems that don't guarantee exactly-once semantics, and structuring Go service boundaries so state stays consistent through upstream failures.
On the OEM API side: working at the REST and webhook contract layer rather than at register or protocol level, and what it takes to onboard a new hardware partner without coupling the control layer to partner-specific implementation details.
On production operations: this was my first sustained experience working on a live system with real customers and commercial obligations. Staging and production are separate environments with formal promotion procedures. A broken deployment isn't an experiment to iterate on, it has downstream consequences. That structural discipline, writing migrations that are safely reversible, keeping changes small and observable, thinking about rollback before merging, was a different kind of rigour from anything I had built in a research or early R&D context.
External integrations accumulate conditional logic when edge cases surface in production that weren't anticipated upfront. I would approach this differently from the start: before writing any code, map every possible callback sequence with the external system, define explicit flowcharts for all exception paths, and agree on exact state transitions for every corner case. A full integration contract agreed before implementation produces a cleaner and more maintainable result than logic added reactively across the sync path.