A person describes their situation and receives an overview of possible benefits. AI interprets the text; separate code handles the calculations. The app does not submit applications or make official eligibility decisions.
The goal was to let a person describe their circumstances in ordinary language and receive an understandable overview of possible benefits. That required more than a chat window: input validation, rule-based calculations, explanations, payments and access control.
Implemented code covered intake, results, a paid personalised roadmap, a facility directory and an admin interface. Behind these sat a database, payment-event processing and reconciliation of access with payment status. Infrastructure existed for an encrypted document vault, but document upload was out of scope. The application does not file government applications or make an official eligibility determination.
A person explains their situation in free text.
Personal-data scrubbing and AI extraction.
Check structured fields before calculating.
The rules engine uses the checked fields.
Code recomputes the headline amounts.
Results and, with access, a personal roadmap.
The user writes about their circumstances. Free text is not yet a collection of verified facts.
AI converts the narrative into structured fields. Personal-data scrubbing and field validation check the input; these safeguards are not infallible.
The rules engine uses structured fields and defined rules. AI does not compute or alter monetary amounts.
Code recomputes headline amounts. Unclear or complex situations are routed to a person rather than filled with an invented number.
The user receives an explanation and, with the appropriate entitlement, a personalised roadmap. Payment handling and preservation of paid access are separate engineering tasks.
A broken API key in the test environment silently activated a simple fallback extractor that did not understand negation. The fix separated development mock data from the real workflow and made extraction failure visible to the user.
The payment handler assumed incorrect field names, and cancellation could remove already-paid access. The fix used the actual event shape and retained access through the paid period.
Alongside input interpretation, the product needed a results view, payment handling and access control. A useful application had to connect those parts rather than stop at an AI response.
I directed product scope, sources and priorities, and decided what was ready to release. AI agents I directed split planning, implementation and review responsibilities. This was not an application completed in a single conversation.
AI extraction uses an external model service. Payment and encryption services also have their own data boundaries. Self-hosting does not mean all processing occurs on the same server.
Sources: project source review and my operating experience. Examples are illustrative, not customer data.
The application has to understand freely written input and run a precise calculation on it. Two different risks sit side by side: the interpretation can be plausible but wrong, and the calculation still has to be repeatable.
I defined the product and its direction, and I did the final quality assurance before every release.
AI assisted with writing and reviewing the code. Final responsibility for the result stayed with me.
One fallback returned a plausible but incorrect interpreted input. The source report describes that explicit degraded-state handling was added afterwards and the fallback was narrowed. A plausible answer is not proof that the interpretation is right.
I can help you build with AI while you keep control of the result.