Your first product shipped, and it sold. Now you want a second one on the same app and the same cloud.
The account, the app, and the cloud built for the first product start serving two at once, and every flow the second product has runs through code written for the first. This is the release where the app and the cloud become a platform. The teams that owned one product now own the thing two products stand on, and every decision they made for the first one is a constraint on the second.
A flow is one thing an owner does, written down as steps with what should be true after each one. Adding a device is a flow. So is switching a room off, or getting a device back after a power cut.
Groundrun runs those flows. They run on your own devices, with your app on a real phone and your test cloud in the run. When a plug joins a product line that was a bulb, it goes on the same rig, and the bulb's flows run against it from the first day. The AI coding agents doing the work read back what happened.
One app, one cloud, two products
The plug that comes after the bulb inherits an onboarding flow, an account model, a room view, and an update path.
The plug that comes after the bulb inherits an onboarding flow, an account model, a room view, and an update path.
A bulb pairs over Bluetooth, joins Wi-Fi, lands in an account, and answers to a tile in a room. The plug arrives into all of that. It also reports the power passing through it, so a room view written for devices that dim now has a new kind of tile to draw.
The update path is shared as well. The images sit in one cloud behind one update screen, and each product takes its own from there.
Which makes a room holding both devices the place where firmware, app, and cloud have to agree. The app sends one tap to the cloud, the cloud fans it out to the bulb and the plug, and each device acts on its own firmware while the app draws the room from what the cloud holds about both.
- Phone reads the setup code on the plug and pairs over Bluetooth
- App passes the Wi-Fi credentials over and the plug joins the network
- Cloud creates the plug in the account as its own product type
- App places the plug in the room beside the bulb
- App shows the plug's power reading beside the bulb's brightness
- One tap on the room switches the bulb and the plug off
- Power to the plug is cut and restored while the room is off
- Plug comes back, reports its state, and the room tile shows both devices as they are
Step five is where the inheritance runs out. The room tile was written to draw a brightness for every device it holds, because every device it had ever held was a bulb. The plug reports on, off, and watts, and the cloud stores exactly that, exactly as it was asked to. So the tile tries to draw a brightness the plug has no way to send.
Every piece is doing its job. The room is still wrong.
Step seven is the one adverse condition, and step eight is what it's there for: the plug has to come back up, report what it is, and let the room settle.
Why do the first product's flows run on the second?
Because a flow describes what an owner does. The onboarding flow written for the bulb says: scan the code, pair, hand over the credentials, join the network, claim it, show it in the account. Every one of those steps is something a plug does too, so the flow points at the plug and runs.
Where a step only makes sense for one product, the flow names that product. Dimming stays the bulb's. Switching a room takes both.
The account model works the same way. A second product type in the cloud is another row for flows the account has: claim it, remove it, claim it again.
So onboarding, the account flows, the room view, and the update path all run against the plug the day it arrives on the rig, with the app on a real phone and your test cloud behind it, the way they were for the bulb.
Every one of those steps is something a plug does too, so the flow points at the plug and runs.
Coverage travels with the product line, so a plug arrives into a rig holding the devices it has to work beside. What the plug adds on top, the power reading and what a room does with it, gets flows of its own, out of what a plug owes the person who bought it.
Two products, one piece of work
The team decides what a plug is in this product: what it reports, what a room does with two kinds of device in it, how good it has to be before it ships.
The agents get the firmware for the plug, the account model in the cloud, and the room view in the app as one piece of work. They add the product type to the cloud, teach the room tile what a plug reports, and bring the new firmware up on the shared onboarding. Then all of it goes on the rig.
The work splits the way the team splits it, by domain, while the flows run across the split. A change to the room tile is validated with the firmware on the plug and the record in the cloud, in one run.
Then the agents run the bulb's flows against the plug. The room flow fails: it expects a brightness, and the plug has none to send. The agent that changed the tile reads that result, fixes the tile, runs the room flow again, and moves on to the power reading.
Groundrun runs the first product's flows on the second
Groundrun puts the second product on the rig beside the first. Every flow written for the first one runs against it, inside the same loop the agents are working in.
They run on your boards, on a real phone, against your test cloud. The agents run it from a command-line tool and read what the plug reported, while the change is still open.
The plug starts on the flows written for the bulb, and grows from there toward every flow the plug runs.
Read how the rig is built around your product line: platform overview.