Web application

AI interprets. Code does the math.

A benefits web application: AI interprets input, code calculates. Scope, payments, access control and lessons from real failures.

← Back to projects

Project scope

From a conversation to a working web application.

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.

9,097automated tests passed in the source review
Local project Vitest run, 11 September 2026: 579 test files. Eight browser-test files were excluded from that run. Test counts are not user counts or proof that the application is defect-free.

What did the workflow do?

  1. Describe the situation

    The user writes about their circumstances. Free text is not yet a collection of verified facts.

  2. AI extracts fields

    AI converts the narrative into structured fields. Personal-data scrubbing and field validation check the input; these safeguards are not infallible.

  3. Code calculates

    The rules engine uses structured fields and defined rules. AI does not compute or alter monetary amounts.

  4. Check before delivery

    Code recomputes headline amounts. Unclear or complex situations are routed to a person rather than filled with an invented number.

  5. Results and access

    The user receives an explanation and, with the appropriate entitlement, a personalised roadmap. Payment handling and preservation of paid access are separate engineering tasks.

What failed, and what changed?

A silent substitute can be worse than a visible error.

A broken staging API key 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.

Payment documentation is not a real event payload.

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.

Green tests are not permission to release.

At the source-review snapshot, a later fix remained unshipped and browser tests had not run in this check. Test results must be tied to a particular version and verification scope.

My role and the AI contribution

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.

Where did the data go?

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.

This case is based on a review of project source and local checks on 11 September 2026, not an independent production audit. Examples are illustrative, not customer data.

Next step

Want to build something similar?

Let us talk about how to build with AI while you keep control of the result.

Get in touch