Handing Over the Keys
Building for someone else to drive
There’s a version of a tool that works perfectly as long as the person who built it is in the room. They know which buttons to press, which edge cases to avoid, and what to do when something behaves unexpectedly. That version isn’t finished. It’s just well-accompanied.
The next few weeks are about closing that gap — and doing it while there’s still time to do something about what we find.
Why now matters
The co-op ends. That’s not a surprise — it’s been the timeline from day one. But the pressure of it lands differently when the tools are real, the users are real, and the people who will be relying on them after we’re gone are sitting in the same building right now.
A software product ships with a support line. A patch can go out next week. If you hire someone to build something and keep them on, you can pull them back in when something breaks. We don’t have that option. When the placement ends, it ends. Which means the tools need to be genuinely complete — not mostly done, not functional with caveats, not held together by our presence. Complete.
That’s a different kind of pressure than building something impressive. Impressive is easy to fake in a demo. Complete is harder to fake when your coworker is trying to onboard a new brand on a Tuesday afternoon with no one to ask for help.
What real testing actually surfaces
Image AI is in the hands of the social team now. Web AI is about to follow. The approach is deliberate — hand it over with an explanation, then step back. Not hover, not answer every question, not jump in the moment something looks unfamiliar. Step back and watch what actually happens.
Because the things that surface when someone uses a tool differently than the person who built it are exactly the things that need fixing:
- The button that’s hard to find because it made sense in the architecture but not on the screen.
- The feature name that’s obvious when you know what it does and opaque when you don’t.
- The flow that works perfectly for one type of brand and quietly falls apart when a new one gets onboarded.
Testing with new brands is part of this too. Every brand that gets added is another stress test on the assumptions built into the system. Different logo formats, different colour structures, different amounts of existing creative to work from. Some of those will expose things that TruPoint and Goose Digital never did, simply because they’re different.
The bugs that come from real usage are different from the bugs that come from internal testing. They’re less predictable and more important. And the only way to find them is to stop being the one using the tool.
What the SOP has to do
Alongside the testing, both projects are working on documentation — the kind that actually works for someone who wasn’t there for the build.
That’s harder than it sounds. Documenting an AI workflow isn’t like documenting a form. The outputs vary. The right prompt for one brief isn’t the right prompt for another. The system makes decisions that a static instruction manual can’t fully anticipate. So the documentation has to teach judgment, not just steps. It has to explain why things work the way they do, not just what to click.
The user guide built into Image AI exists for the same reason. The goal was always that someone could pick it up without us in the room. The testing happening right now is the first real proof of whether that’s true.
The difference between done and ready
There’s a version of done that means all the features work. And there’s a version of ready that means someone else can use it, maintain it, and get value from it without the people who built it.
The next few weeks are about closing the gap between those two things. Not adding features — making sure everything that’s there is solid enough to stand on its own. Because the most important user of both these tools isn’t us. It’s the person who opens it on a Wednesday morning three weeks after we’re gone and needs it to just work.