AI Contractor Pal

Pay for what ships: AI builds your app, independently verifies agreed outcomes, which you can also verify with sneak peak and unlocks the source code only after PayPal confirms payment.

Comment

Inspiration

Ever since I first heard Alex Karp, CEO of Palantir Technologies, discuss the challenges of making AI commercially viable, I have kept thinking about one question: How can we turn AI from an expensive service into a product that delivers measurable value?

Whenever I use AI features on a company’s website or application, I wonder how much every request costs the company providing it. AI inference can be expensive, especially when users repeatedly make requests without paying for the value they receive. This is one reason companies introduce usage limits, subscriptions, and paywalls.

As an AI and Machine Learning undergraduate student, I dream of working in an AI company and contributing to solutions that make AI more commercially sustainable. I believe one promising approach is to make AI deliver tangible products instead of charging customers indefinitely for access to an AI service.

AI agents can already generate websites and software, but many customers are reluctant to commit to expensive subscriptions for software they may only need once. What if customers could describe the software they need, have AI build it, and pay according to what actually works?

That question inspired AI Contractor PayPal: a project that combines AI-powered software development, automated verification, and outcome-based payments.

My vision extends beyond websites. With access to a properly configured virtual machine and suitable execution environments, the same concept could eventually support desktop software and applications for specialized devices.

The most important part is transparency. Instead of presenting a failed or incomplete application as a finished product, the system identifies which acceptance criteria passed and which remain unavailable because of implementation issues or technical errors.

The goal is to help customers avoid paying for functionality they did not receive while giving AI-generated software a practical path toward commercialization.

The principle behind the project is simple: Pay for what ships.

What It Does

AI Contractor PayPal transforms a plain-language software brief into a browser-based application with an approved acceptance contract and outcome-based payment.

Customers describe the product they want and set a budget. AI proposes specific acceptance criteria, which the customer reviews and approves before development begins. The system then generates the application, verifies the deliverable, and attempts to repair failed criteria.

Customers pay only for acceptance criteria that pass verification. The full budget is not automatically charged just because the AI generated an application. Instead, the server calculates the payable amount from the approved budget and the latest criterion-level verification results.

For example, consider a customer with a $10 budget and four approved acceptance criteria. Each criterion is allocated $2.50. If three criteria pass and one fails, the amount payable is $7.50. If all four pass, the amount is $10.00. If none pass, checkout is unavailable.

PayPal checkout handles the payment process, while server-side capture validation protects the final delivery. The source-code ZIP becomes available only after the application records a validated completed payment.

The goal is to connect AI-powered development, observable results, and payment-gated delivery in one workflow.

How I Built It

I built the project using Python and FastAPI for the backend, with HTML, CSS, and JavaScript for the dashboard. SQLAlchemy and SQLite manage jobs, approved contracts, verification results, generation history, and payment records.

The main workflow uses NVIDIA NIM for contract analysis, application generation, and targeted repairs. LangChain and LangGraph organize the AI workflow into specialist stages:

  • Contract analyst: Converts the customer's brief into structured acceptance criteria.
  • Architect: Generates the application's HTML structure and acceptance markers.
  • Stylist: Creates responsive CSS and considers reduced-motion preferences.
  • Engineer: Implements client-side JavaScript interactions.
  • Repair specialist: Uses failed verification results to guide targeted corrections.

The generated product consists of three files: index.html, style.css, and script.js.

I added HTML-based acceptance checks and optional Playwright browser verification to inspect visible elements, interactions, responsive behavior, and JavaScript errors. Verification results and generation versions are persisted so the customer can review the outcome instead of relying solely on the AI's claim that its work is complete.

How Customer Payment Is Calculated

The payment calculation is handled by the server using the customer-approved budget and approved acceptance criteria.

  1. Split the budget: The approved budget is converted into cents and divided across all acceptance criteria. If the division leaves a remainder, the extra cents are allocated to the earliest criteria in their approved order.

  2. Evaluate each criterion: The verifier determines whether each criterion passed. A skipped criterion does not count as a pass, and browser smoke checks do not override the criterion-level result.

  3. Calculate the payable amount: The server adds the allocated shares for criteria whose latest criterion-level results passed and were not skipped.

  4. Apply the checkout rule: If no criteria pass, payment cannot proceed. If some pass, the customer can pay for those successful outcomes. If all pass, the full approved budget becomes payable.

  5. Validate and deliver: The server creates the PayPal order for the calculated amount, validates the subsequent capture against the job, expected amount, and USD currency, and records completed payment before unlocking the ZIP.

For example, with a $10 budget and six criteria, the budget is allocated in cents: four criteria receive $1.67 each and two receive $1.66 each. If the first three criteria pass and the remaining three do not, the payable amount is $5.01. The amount can vary slightly depending on which criteria pass because remainder cents are assigned in criterion order.

This approach makes the billing rule transparent and reproducible: the model does not set the final price, and a failed criterion does not earn its allocated share. The approved contract defines the criteria, while the server calculates payment from the persisted verification results.

For payments, I integrated PayPal Orders API v2 using Developer Sandbox credentials. The server calculates the payable amount from passed criteria, creates the order, and validates the completed capture, job association, amount, and currency before recording payment completion. The download endpoint independently checks the stored payment state before releasing the source ZIP.

The project also includes a runtime settings interface, Docker support, database migration utilities, automated tests, and a GitHub Actions CI workflow.

Challenges I Faced

One of the biggest challenges was turning subjective software requirements into acceptance criteria that a program could actually evaluate. A model can generate a convincing interface while still missing a required interaction or feature. To address this, I designed a structured contract and added acceptance markers, criterion-level checks, browser verification, and a limited repair loop.

Another challenge was making partial payment fair and predictable. Simply charging the full budget whenever an application was generated would not reflect incomplete work. I designed a per-criterion calculation so that the amount due depends on successful checks, with the budget split in cents to avoid floating-point rounding issues. This also required keeping the approved contract, verification results, payable amount, and PayPal order aligned.

Connecting AI-generated deliverables to payment safely was another important challenge. A successful redirect from PayPal is not sufficient proof of payment. I therefore kept payment calculation and validation on the server and made the download endpoint check persisted payment completion rather than trusting browser-side state.

I also had to account for inconsistent model outputs, provider failures, optional browser dependencies, repeated payment requests, and Sandbox currency restrictions. Structured response validation, explicit failure handling, idempotency support, and a mock payment adapter for local testing helped make the application more predictable.

These challenges also clarified the boundaries of the prototype. Its generated products are static browser applications, the Sandbox integration does not process real production payments, and automated verification cannot guarantee complete software correctness or security.

What I Learned

This project taught me that building an AI-powered product involves much more than connecting a model to an API. Reliable systems need explicit state transitions, validated data, clear acceptance criteria, error handling, persistent records, and security checks around every consequential action.

I gained practical experience combining NVIDIA NIM with LangChain and LangGraph, designing backend APIs with FastAPI, persisting workflow state with SQLAlchemy, using Playwright for browser-based verification, and integrating PayPal's order and capture lifecycle.

Most importantly, I learned to treat AI output as something that must be evaluated rather than automatically trusted. Verification, payment, and delivery each need their own controls. I also learned that an outcome-based billing system must make its calculation understandable to customers before they proceed to checkout.

The project strengthened my understanding of a broader business challenge: generating software is only part of the problem. Making the output reliable, communicating its value, and creating a sustainable way to sell it are equally important.

What's Next

The next steps are to strengthen user authentication and job ownership, add PayPal webhook signature verification, isolate generated applications in restricted execution environments, and move long-running generation tasks to a durable queue.

I also want to expand the verification framework beyond basic acceptance checks and improve the handling of more complex software requirements.

Beyond browser-based applications, I envision integrating secure virtual machines and isolated execution environments so the system can eventually support desktop software and other forms of software automation. This would require additional testing, stronger sandboxing, and platform-specific verification.

My long-term goal is to explore how AI agents can build useful digital products, demonstrate that those products meet agreed requirements, and connect their delivery to a transparent payment process.

The Vision

AI Contractor PayPal is a prototype exploring a broader idea: software work should be evaluated against agreed outcomes, and payment should reflect what was actually delivered.

By bringing together AI development, explicit acceptance criteria, automated verification, transparent partial billing, and PayPal payment-gated delivery, the project explores how trust can become a measurable part of the software contracting process—not merely an assumption.

Rather than treating AI exclusively as a service customers subscribe to, this project explores a model in which AI produces a deliverable that customers can evaluate and purchase.

AI Contractor PayPal — Pay for what ships.

Built With

Share this project:

Updates

Submission history