AI Integration: Workflow First, Features Second

The fastest way to add an AI feature to your product is to skip the harder question: where in the work does this AI actually belong?

The board has been asking for an AI plan. A competitor announced something recently that made your own progress feel slower than it is. 

The path of least resistance is to add a chatbot to the product you already have, or a copilot button somewhere visible enough to count as progress.

You also already sense that path is wrong, even if you cannot quite say why.

The cost of getting this decision wrong is not abstract. It is the AI roadmap that does not produce the result everyone is counting on, the team that loses confidence in the build, and the user trust that breaks the first time an AI feature lands in the wrong place.

‍

Why Feature-First Happens, and Why It Feels Productive

Feature-first thinking is the default because it produces something visible by the next status update. 

The team picks a tool, the feature gets scoped, the build goes into the sprint, and everyone leaves the meeting with the sense that progress was made.

The decision that actually mattered was made earlier, and nobody was in the room for it. That decision was where AI belongs in the workflow that already exists, and whether that workflow is even the right one to be amplifying. 

The decision goes unnoticed at the time it gets made. The consequences show up later, and the team owning them is rarely the team that made the call.

‍

What Feature-First Costs at the Company Level

Builder.ai is the most public version of this failure mode. The company raised roughly $445M from Microsoft, SoftBank, and others on the premise that AI could build software more efficiently than human teams could. The marketing put AI at the center of the value proposition. The architecture underneath the marketing could never deliver what the pitch promised, and by May 2025 the company had filed for administration.

The investors lost their stake. The customers who had hired Builder.ai to build their software were left holding code they could not maintain. 

Hundreds of engineers lost their jobs. The lesson lands at the company-strategy level. When AI is what is being sold and the architecture is being figured out behind the scenes, the gap between what is promised and what can be delivered eventually closes. 

It rarely closes in a way that protects the people on the other side of the contract.

‍

What It Costs at the Feature Level, Even at Scale

Apple announced personalized Siri features at WWDC in June 2024 to substantial fanfare. The marketing showed Siri understanding personal context, taking actions across apps, and operating with a level of awareness the existing assistant had never had. 

By spring 2025, Apple announced that the most ambitious of those features were delayed indefinitely because the underlying architecture was not ready to support them.

This is Apple, the most resourced product organization on earth, with effectively unlimited engineering capacity and the deepest pockets in the industry. 

Even Apple could not deliver AI features on top of an architecture that did not yet support them. The press cycle around the delay was painful for Apple in a way the company is not used to, and the message for everyone watching was clear. 

The architecture decision precedes the feature decision. Even Apple cannot get around it.

‍

Workflow First, Defined

A workflow-first conversation does not start with which AI tool to use. 

It starts somewhere earlier:

• Where decisions get made inside the product
• Which of those decisions cost the user time, accuracy, or attention
• Where a model trained on the right data could meaningfully change those decisions
• Where AI would only add a second place for the user to look without giving them anything new

The answers to those questions determine whether AI belongs anywhere in the build at all, and if so, in which moments. 

By the time the team gets to the question of which model, the architecture is already mostly designed. 

The conversation about tooling becomes a much smaller conversation than it usually is, because the harder thinking has already happened.

‍

What This Looks Like in a Real Build

Witherspoon Rose Culture came to us needing software no off-the-shelf platform could deliver. They are a wholesale rose grower with a specific operational texture: orders, inventory and spray mix tracking, automated end-of-month financial processes, mobile access for field staff, e-commerce sync with Shopify. 

The work spans multiple departments with handoffs that have to land cleanly.

Before AI was on the table, we built Quickrose, the operations platform that mirrors how the business actually runs. The platform was the architecture. Once it existed, the AI conversation became answerable. 

The synthesis work involved in reporting, where patterns across the operations data inform decisions about growing cycles and customer relationships, was the place where a model added something the existing workflow could not deliver on its own. 

That is where AI lives in the build.

What is worth naming is where AI was not used. Several places looked like obvious AI candidates, and we said no:

• The order entry flow needed deterministic accuracy, not synthesis
• The mobile field app needed speed and clarity for staff working in the rose fields
• The end-of-month financial automation produces outputs regulators expect to be deterministic

The no in those places mattered as much as the yes.

‍

Why This Decision Has to Be Made Before Code Gets Written

The window for getting AI architecture right is the period before development starts. After launch, the cost of changing direction climbs steeply. 

The system is already in production, the team has moved on, and any change has to unwind decisions other parts of the product depend on.

We have watched several engagements in the past year where a client came to us with an AI feature already in production that was not working, and the conversation was always harder than it would have been at the architecture stage. 

The tradeoffs are worse, the options are narrower, and the version of the integration that gets to live is rarely the one anybody would have designed if they were starting fresh.

We believe that business is built on transparency and trust, and that good software is built the same way. AI integration decided before the workflow is mapped almost never honors that standard, regardless of how impressive the technology behind it is. 

The team that ends up living with the build is the team that pays for the shortcut.

‍

What to Do in Your Next AI Conversation

If your team is about to scope an AI feature, the questions worth pushing onto the table before anyone picks a model:

• Which decision in the workflow is this AI feature meant to change, and what does that decision cost users today?
• What happens to the user if the AI is wrong in this moment?
• Where in the product would AI feel obviously useful but actually create more friction than it removes?
• What does the cost model look like at real usage rather than at demo usage?
• What does the team plan to do if six months in the feature is not being adopted?

If the answers are vague, the build is not ready. 

Slowing down to answer them is the cheapest version of this conversation you will ever have.

The pressure to add AI to your product is real and it is not going away. 

What you can control is whether the architecture conversation happens before the build, with a partner willing to make it harder than it would otherwise be. 

The firm worth working with is the one that will tell you where AI does not belong inside your product, and why, before any of it gets built.