Sourceful App

• 

  01 / Optimiser

• 

  02 / Savings

• 

  03 / Vehicles

• 

  04 / History

A small product team, one app

The Sourceful App is the consumer surface for everything the Zap gateway does in the home. Live energy flow, automatic battery scheduling against spot prices, EV smart charging, savings tracking, multi-brand device control. iOS and Android, free, in front of every Sourceful customer in Sweden.

It is not a side project. It is the only thing most users ever touch.

What it is not is the work of one designer at a desk. The app shipped because a small product squad worked tightly together: one app developer doing the lion's share of the build, me on UX, UI and research, and the wider Sourceful platform team behind us. My job was to be useful to that group, not heroic about my part of it.

How we worked

Co-located on Sourceful's product squad. Same standup, same backlog, same Figma file, same build. The app developer and I paired on most screens, sometimes literally on a call with the file open, sometimes async over a Loom and a comment thread. Decisions stayed light because the loop was tight.

Two rules made the pairing work. The dev never had to wait for "final" design. I shipped the next state in Figma fast, then iterated against what was already on the simulator. And I never specced what could be answered by sitting next to the build for ten minutes. A lot of the UI was decided in the IDE, not the design tool.

Decide in the simulator, not in the spec.

What I owned

UX, UI, and the user-research loop. Information architecture across home, optimiser, devices, vehicles and history. The visual system, type, colour, iconography, motion. Empty states, error states, the whole onboarding flow from "download" to "first useful read."

User research was a constant, not a phase. We ran short interviews with new installs every week, watched first-launch sessions, and scraped App Store and Play Store reviews into a shared doc the whole team read on Mondays. Most of the IA shifts in the app, the move to a single live home screen, the savings card promotion, the EV split, came out of that loop rather than a workshop.

The home screen is the screen we returned to most. New users open the app dozens of times in the first week, mostly to check that the thing is working. That is a different need from a power user reading their schedule, and a different need again from a customer checking the savings number on a Sunday morning. We tested four versions of the home before settling on the live-flow read with a savings card pinned underneath.

Code where it helped

I am not the app developer. Most of the Dart and Flutter is not my work. But I picked up code where picking it up made the team faster, mostly the things designers usually annotate and hand back: small layout tweaks, copy strings, motion timings, the fiddly bits of empty states, theme tokens. Pull requests rather than redlines.

The point was not to claim engineering. The point was to remove the round trip when the round trip was the bottleneck. The app developer kept ownership of the architecture. I kept ownership of how it looked and felt, and committed against that ownership when it was faster than writing a ticket.

• 

  01 / Spot Prices

• 

  02 / Plan

• 

  03 / State of charge

• 

  04 / Devices

• 

  05 / Pair Zap

The harder problems

The app sits on top of a physical system that does not care about screens. Inverters drop offline. Batteries throttle. Spot prices rewrite themselves at 13:00 each day. The hard UX problems were the ones where the app had to stay legible while the underlying data was lying, late, or both.

Two examples. The optimiser schedule is computed against tomorrow's spot prices, which arrive mid-afternoon. Until they do, "tomorrow" is a forecast, not a plan. The first version of the screen treated forecast and plan as the same object. Customers told us, in research, that they did not trust a number they could not source. We split forecast and confirmed states with different visual weight, a small caption explaining what changes at 13:00, and a quiet animation when the day's plan locks in. Trust went up. Support tickets about "wrong" schedules went down.

Second, multi-brand devices. Sourceful integrates with most major inverters, batteries, EV chargers and V2X systems. The original devices screen tried to be brand-neutral and ended up unreadable, every device looked the same regardless of what it could actually do. We rebuilt the list around capability rather than brand, with the brand as supporting metadata. Same data, very different read.

The stack

Flutter on both platforms, sharing a single codebase. State managed locally, talking to the Zap gateway and Sourceful's platform APIs. Designed in Figma against a token set that mirrors the wider Sourceful design system. Distributed via the App Store and Google Play, free to download for any Sourceful customer.

• Flutter
• Dart
• Figma
• Zap gateway
• Sourceful Platform
• App Store
• Google Play

Outcome

The app is the surface a Sourceful customer touches every day, and a small team got it there by working as one unit rather than as a relay. The lesson I carried out is that on a product squad this size, the design role is partly to do the design, and partly to remove every reason for the team around you to wait.