How AI Products Software Development Actually Runs

Most AI product projects fail before the first model call. Not because the model is bad, but because the team treats the model as the product. AI Products software development is not prompt engineering wrapped in a UI. It is a compound system where data pipelines, schema enforcement, approval gates, and the model itself have to work together, and every component has to be right. This is how an engagement actually runs when I take it on.

The scoping call is where the architecture starts

The first conversation is not about which model to use. It is about what the output has to be, and who is responsible for it. Those two questions decide almost everything else.

I ask the founder or product lead to describe the worst thing that could happen if the system returns a wrong answer. If they say 'users would be annoyed,' the architecture looks one way. If they say 'a user books the wrong visa route and gets refused at the border,' it looks completely different. Fursa was the second kind. The product covers eligibility across 170-plus destination countries. A confident wrong answer is worse than no answer at all. That constraint shaped every layer of the system, not just the retrieval step.

By the end of the first call I want to know: what data exists, who owns it, what the approval chain looks like, and whether the team has any tolerance for latency in exchange for accuracy. Budget and timeline come after that, because they depend on those answers.

Week one is research, not building

I do not open a code editor in the first week. I map the data sources, trace the user journey end to end, and write a short architecture document that names the components and their failure modes.

In 2026 the production standard for agentic workflows is compound systems, not single-prompt chains. Frameworks like LangGraph and LlamaIndex Workflows are built around the idea that the model is one node in a graph, not the graph itself. That is the right mental model. Each node has a defined input schema and a defined output schema. If a node returns something outside the schema, the system does not guess. It stops and escalates.

Strict schema enforcement is not optional. It is the mechanism that makes the rest of the system trustworthy. I have seen teams skip it to move faster and then spend three weeks debugging silent failures where the model returned a plausible-looking but structurally wrong object that propagated through downstream steps before anyone noticed.

The architecture document I write in week one names every node, every schema boundary, and every place where a human has to approve before the system continues.

Human approval gates are not a workaround for bad models

This is the thing I have to explain most often. Teams assume that approval gates are a temporary measure while the model improves. They are not. They are a design decision about who is accountable for an output.

On Job Hunter, the system crawls over 185 career pages daily and generates outreach drafts. The model is good at this. But the outreach goes out under a real person's name, to a real recruiter, with real consequences for that person's reputation. So the draft goes to the user before it goes anywhere else. That is not a limitation. That is the product.

The approval gate also generates training signal. Every time a user edits or rejects a draft, that is data about what good looks like for that user. Over time the system improves on the dimension that actually matters, fit for the specific person using it, not fit for an average benchmark.

Building the approval gate well means thinking about it as a UI problem as much as a systems problem. The gate has to show the user enough context to make a fast, confident decision. If the gate is slow or confusing, users approve everything, and the gate stops working.

Verification against sources is an engineering problem

For any AI product where the output is a claim about the world, retrieval has to be traceable. The user needs to be able to see where the answer came from. The system needs to be able to fail gracefully when the source is missing or out of date.

This is a harder engineering problem than most teams expect. It is not just attaching citations. It means the retrieval step has to return structured metadata alongside the chunk, the generation step has to be constrained to what the retrieval returned, and the output format has to surface the source in a way the user actually reads.

On Fursa, every eligibility result is tied to the source document that supports it. If the source document is stale, the system flags the result rather than presenting it as current. That required building a freshness layer into the data pipeline, not just the model step. GritGateway had a similar requirement across talent data from 25-plus African countries, where source quality varies significantly by region.

Testing an AI product is different from testing software

Unit tests cover the schema boundaries. Integration tests cover the workflow paths. But neither of those tells you whether the outputs are actually good.

I build an eval set early, before the first model is wired in. The eval set is a collection of inputs with known-good outputs, agreed with the client. Some of those inputs are edge cases. Some are adversarial. The eval set runs on every deployment and the results go into a dashboard the client can see.

This matters because the model will change. The underlying API will update. The retrieval index will drift as new documents are added. Without an eval set, you find out the system degraded when a user complains. With one, you find out before the deployment goes live.

The eval set also makes the approval process faster. When a client asks 'is this safe to ship,' I can show them a number, not a feeling.

What the engagement looks like from your side

You get a scoping document after the first call. You get an architecture document after week one. You get a staging environment with a working eval dashboard before we discuss production readiness. Every decision that affects accountability, data ownership, or the approval chain is documented and signed off before it is built.

The MVP Sprint is the right shape for most AI product engagements: fixed scope, eight to twelve weeks, a working system at the end. If you are still deciding whether to build at all, the Technical Due Diligence engagement is the faster path. It gives you an honest assessment of the build complexity and the risks before you commit budget.

If you are close to starting and want to talk through the architecture before anything else, the contact form is the fastest way to reach me.