Connecting Engineering to Commercial Value
The growth workflow turned generated output into a sales conversation, not just a deliverable. I did not want generation to end as a technically impressive artefact with no obvious business outcome attached to it. The growth workflow connected the AI output to a real sales process while keeping verified facts and human approval in the loop.
- Why you added the agency growth workflow
- Turning audits into proof-of-value redesigns
- Separating verified facts from generated claims
- Human approval in customer-facing automation
The situation
A generated redesign was technically impressive but had no commercial path attached to it for an agency trying to win new business. In Connecting Engineering to Commercial Value, I wanted to capture the real operating situation rather than describe the problem in abstract terms. What mattered to me was the moment the existing approach stopped being sufficient in normal use, because that was usually the point where the next architectural requirement became obvious.
The naive solution
Leave commercialization entirely to the user; the platform's job ends at "here is your generated site." The naive option was attractive precisely because it was faster and easier to explain. I could have pushed further in that direction and probably improved the demo, but it would have optimised the visible symptom rather than the underlying system constraint.
The hidden constraint
Agencies needed the generated artifact to function as a proof-of-value inside a sales process: research, audit, redesign, review, outreach. This constraint was easy to miss early because it did not show up in the first successful run. It appeared once the workflow had to survive repetition, failure, another user, another provider, or a return visit, which is why I now look for these second-order requirements much earlier.
The decision
Build a growth workflow around the generation feature: research and audit prospective businesses, generate redesign proof pages from real audited screenshots, and manage the outreach that follows. I treated this as an architectural or product decision rather than a prompt tweak. The aim was to create a boundary I could reason about later, instead of relying on model behaviour to remain consistent as providers, templates, and user requests changed.
The implementation
Website audits capture concrete signals (slow pages, broken links, mobile overflow); the redesign prompt is instructed to preserve verified company facts and never invent testimonials, awards, prices, guarantees, or accreditations. Customer-facing WhatsApp responses stay as drafts until a human approves them. I also tried to make the implementation concrete enough that the decision could be inspected in code and runtime behaviour. That meant explicit state, explicit policy, and observable transitions rather than a collection of hidden assumptions spread across prompts and handlers.
The tradeoff
Significant additional product surface (research, audits, inbox, meetings, deal tracking) beyond the core generation engine. I did not treat the decision as free. In most cases I was deliberately accepting more engineering, state management, or operational complexity in exchange for a smaller failure surface and a product that could survive realistic use.
The evidence
Generated proof pages could be traced back to real, verified audit data rather than model-invented claims, with human approval gating anything customer-facing. I use this evidence as a practical signal, not as a claim that the architecture is universally correct. The useful question was whether the new design changed what the system could reliably do under the conditions that had previously broken it.
The reusable lesson
An AI feature becomes commercially potent when it is wired into the workflow that turns output into a business outcome, not just a better artifact. The part I would carry into another build is the decision rule behind the implementation, not the exact technology choice. Vendors and frameworks will change; the underlying question about state, control, isolation, feedback, or user trust is much more reusable.
The consultant's questions
- What business process is supposed to happen after this AI output is produced, and does the product support it?
- Where could this system generate a false claim, and what stops it from reaching a customer unreviewed?
- What assumption in this part of the system would become dangerous if usage or tenant count increased?
- What evidence would tell me this decision needs to be revisited rather than defended indefinitely?