Technical note · Product engineering

Build the workflow first. Add AI where it earns its place.

My working rule for AI-enabled applications is simple: the product still needs to make sense when you describe the workflow without saying “AI.”

By Sanjai Syamaprasad · Software Engineer & AI Application Developer · September 29, 2026

AI is useful when it reduces a real source of friction. It is much less useful when it is added before the application has a clear user, state model, or next action.

1. Start with the job the user is trying to finish

Before choosing a model or prompt, I write down the sequence the user is actually moving through. What comes in? What state needs to be stored? What decision or action happens next? That usually reveals which parts belong to ordinary application code and which parts may benefit from a model.

2. Keep deterministic rules deterministic

Authentication, authorization, database ownership, required fields, routing, status transitions, and calculations should not become probabilistic just because an application includes AI. Those are places where predictable code is easier to test, explain, and maintain.

3. Put AI at the unstructured edges

One pattern I use is to place AI between messy human input and a structured application model. In RentNinja, for example, the useful AI boundary is around reviewing or extracting information from documents and pasted text. The application still owns the applicant record, workflow state, access rules, and the place where the result is reviewed.

Messy input
text · file · context

AI assist
extract · summarize

Validate
schema · rules

Application state
database record

Human review
inspect · decide

Next action
workflow continues

4. Treat model output as input to the system

A model response should not become trustworthy merely because it is formatted cleanly. I prefer structured outputs that can be validated, displayed in context, and corrected. The application should know what to do if the output is incomplete, malformed, or simply not useful.

5. Design for an obvious fallback

If a user cannot continue when the model is unavailable, the feature may be too tightly coupled to AI. A good fallback can be manual entry, a saved draft, a retry path, or a simpler deterministic flow. The exact fallback depends on the product, but it should be considered during design rather than after an outage.

6. Measure the product outcome, not the presence of AI

The question I care about is whether the workflow became clearer, faster to operate, or easier to understand—not whether the application can advertise another AI feature. That keeps model choice secondary to product behavior.

How this shapes my projects

RentNinja is the clearest published example of this approach. QuestNinja and ShiftNinja are still development projects, but the same principle applies: define the learning or coordination loop first, then decide where AI can add useful context without taking control away from the user.