The Demo Was the Smallest Part

This is Part Two of my FamilyOS learning series. In Part One, What Building FamilyOS Taught Me About AI, I shared why I started building a family coordination product and what changed as the idea became something real.

Here, I am focusing on what happened as I learned to direct code generated by AI. The public demo is where several practical problems came together, including missed dependencies, rework, token limits, and prompt quality.

I wanted visitors to experience FamilyOS as a parent or one of three children. The request initially seemed straightforward: create the accounts, add a selector, and let people explore. But making something available for others to use changed the nature of the work.

My first prompt focused mostly on what visitors would see. As the work progressed, I found myself spending much more time on what they should and should not be able to do. If someone completed a chore or redeemed a reward, what would the next visitor see? Could a child reach an action reserved for a parent? Could demo activity ever touch private family data? And how would the experience return to its starting point?

The work expanded into authentication, separate parent and child identities, protected actions, data resets, environment configuration, and deployment checks. Each piece made sense when it surfaced, but I had not seen the complete chain when I wrote the original request. The account selector was, in fact, the smallest part of the demo.

My work in product leadership, complex program delivery, and quality had already taught me to ask about dependencies, risks, testing, and release readiness. With AI coding, I had to apply that thinking much faster. A request could become working code before I had fully explored its implications.

Sometimes that was useful. At other times, the result looked more complete than it was. The harder part was understanding why. Had I left the requirement open to interpretation? Had the implementation covered only the most direct path? Or had seeing the feature in use revealed a decision I had not made yet?

Answering those questions often required more than another prompt. I had to review the behavior, trace what else had changed, and decide whether a fix added value or simply more complexity. Some iterations saved time. Others created rework.

I also ran into a very practical constraint: token limits. Longer prompts and extended sessions consumed the available context quickly, and more than once I reached a usage limit while work was still underway. Continuing later meant rebuilding enough context to proceed safely without retelling the project’s entire history.

My first response was to make prompts more comprehensive. That used more tokens and sometimes buried the actual task. I eventually moved in the opposite direction: one bounded objective, only the constraints that mattered, focused validation, and a clear stopping point. Stable product decisions went into project documentation instead of every new prompt.

That same shift changed how I approached the demo. Rather than asking AI to build it as one feature, I separated the work into smaller decisions. I specified which actions needed protection, which environment could change, what had to be verified, and when the work should pause for review.

Publishing the demo introduced another layer. Something could work locally and still behave differently once it was public. Tests could confirm that a child was blocked from a parent action, but they could not tell me whether a visitor would understand the experience. A technical pass was evidence, but it was not the entire product decision.

I would not have built FamilyOS in the same way without AI, but I am less interested now in how quickly it produces code. I pay more attention to whether the result survives review, behaves correctly beyond the immediate request, and moves the product toward something another person can trust.

The public demo is one example from a much longer build. In the final part of this series, I will step back and reflect on the full FamilyOS journey, including where AI genuinely helped, where it fell short, and what I would do differently the next time.