Kitpier

The app store for AI-built software. Describe your app, an AI planner picks the services, you pay once with PayPal, and Kitpier caps the spend while the service works in your app.

Comment

Try it: kitpier.com · Judges: a 3-minute guided path at kitpier.com/judges

Kitpier is the app store for AI-built software. Describe what you're building. Kitpier works out which services it needs, shows you what each one costs, waits for your approval, and connects everything. Kitpier's own services are paid for with PayPal and stop at the budget you set.

AI proposes. You approve. Kitpier executes.

Inspiration

AI coding tools can build an app in an afternoon. Making it work for real customers is a different job: a database, email, an AI service, each with its own account, keys, docs and bill, and nothing that tells you what to pick or caps what it costs. I wanted the step after "my AI built it" to feel like an app store: describe what you need, pay once, and it works.

What it does

  1. Describe what you're building. "A booking page for my barbershop that emails customers a confirmation."
  2. Kitpier builds the stack. An AI planner picks Kitpier's Booking API, Supabase and Resend from the catalog, explains why, and labels how each is billed: what Kitpier runs and caps, and what the provider bills you directly.
  3. You approve and pay. Nothing is bought, created or connected until you approve. Kitpier services are bought with PayPal credit packs ($10 / $25 / $50); Supabase and Resend connect to your own accounts.
  4. Ship it. A hosted booking page goes live, or you paste one prompt into your AI coding tool and your own site calls the Booking API. Bookings land in your database, confirmations go from your email account, and usage is counted against the project's monthly budget. At the cap, bookings pause before going over and the assistant offers a PayPal top-up.
  5. Or let your AI agent do it. Your AI coding agent (Claude Code, or any agent that can make HTTPS calls) connects to Kitpier, plans the stack and requests what it needs. Every purchase, booking page and API key still waits for you: the agent hands you an approval link, and you approve and pay there.

How PayPal is used

PayPal isn't just a checkout here. It is the buying step between an AI-planned stack and the services Kitpier runs. A verified payment creates service credits, usage spends them, and when a project's budget runs out, work pauses and Kitpier offers a PayPal top-up.

  • The server builds every order from its own price table. Amounts never come from the browser or the model.
  • After the buyer approves, Kitpier captures the order (Orders v2, intent CAPTURE) and verifies it with PayPal (merchant, amount, currency and our order id) before adding credits.
  • Three paths can confirm a payment: the browser, and the CHECKOUT.ORDER.APPROVED and PAYMENT.CAPTURE.COMPLETED webhooks (signature-verified). They converge on one function, so credits are added exactly once. Refunds and reversals take back the credits; a reversal or dispute also freezes the account until it's reviewed.
  • When a project runs out of budget, the assistant proposes a PayPal top-up in the conversation and bookings resume once it's verified.
  • Payments run in PayPal sandbox during the hackathon.

How I built it

  • Next.js 16 (App Router) on Render, Postgres on Neon, at kitpier.com.
  • Claude Haiku 5.5 through the Anthropic tool runner for two jobs: the stack planner and the Booking API's conversation (checking open times, extracting the appointment). The model can only propose: approvals, payments and database writes happen in server code it cannot reach.
  • Supabase OAuth and Management API to create the bookings table from fixed templates; Resend for confirmations.
  • A micro-USD ledger where every entry has a unique source, so each payment and each booking is counted exactly once.
  • 195 automated tests (Vitest).

How Kitpier makes money

Kitpier earns only on the services it runs itself, paid for with PayPal credits. The Booking API costs $0.02 per customer message and $0.05 per confirmed booking, priced from a server-side price card that targets at least 60% gross margin after PayPal fees (Claude Haiku costs about a cent per booking conversation).

Services in your own accounts, like Supabase and Resend, are billed directly by those providers. Kitpier takes nothing from them.

  • Today: margin on Kitpier-run services. A typical small booking site brings in about $11 a month in Booking API revenue, an estimated $9 after AI and PayPal costs.
  • Next: more Kitpier-run services that spend the same credits.
  • Later: with PayPal marketplace approval, partner services sold through Kitpier for a share.

Challenges

  • Money that is never counted twice. Browser captures and two kinds of webhook can arrive in any order, more than once. Making all of them converge on a single verified, idempotent ledger write took the most care.
  • An AI that can't spend or break things. The planner, the booking assistant and connected agents have no tools that move money or create resources. Provider actions need an approval recorded by the server, and Supabase access is confined to tables Kitpier created from templates.
  • Judging without accounts. Judges shouldn't need a login, or their own Supabase or Resend. One click on /judges gives each judge a private demo account with a project already set up on a demo connection: bookings go to a demo database scoped per project, and emails land in a Demo inbox instead of being sent. Nothing is shared between judges, and demo data is deleted automatically.

Accomplishments that I'm proud of

  • A complete path from a sentence to a working booking in someone's own database, paid for with PayPal and capped by budget.
  • 195 automated tests covering payments, the ledger, provisioning, authentication, agent access and the booking flow.
  • Security built in from the start: credentials encrypted at rest (AES-256-GCM), scoped send-only email keys, API keys that never reach a browser, one-time email codes before any confirmation is sent, and rate limits stored in Postgres.

What I learned

Trust is the product. I started out thinking the hard part was recommending the right services. It wasn't. The harder question was what an AI should be allowed to do. Kitpier ended up with a simple boundary: the AI can recommend, but it cannot spend money, create resources or write customer data. Only server code can, and only after an approval it has recorded.

Payments are not a single event. Browser callbacks, captures and webhooks arrive more than once and out of order, so the ledger had to be idempotent from the first line.

The product became less about "AI picking tools" and more about making AI-assembled software safe enough to trust: you see what it will cost, you approve every step, and the spend stops where you said.

What's next

Kitpier starts with a small catalog, but the model is built for a much larger one. Any provider could list a service with machine-readable capabilities, pricing and setup steps. An AI building software could then find what it needs, compare options, ask for approval and buy it, without the builder having to understand the infrastructure underneath.

AI coding agents can already shop Kitpier this way, with a human approving each step. Next: more listings on the same connect, approve and budget machinery (Twilio SMS reminders, then Clerk sign-in and Vercel hosting), production PayPal, and provider onboarding.

Prior work

Kitpier was built during the submission period. A few helper files (PayPal client, session and HTTP helpers, and the agent pattern) came from a prototype I wrote on Oct 13, 2026, also inside the submission period, and were adapted. The Booking API was written fresh for this project.

Built With

Share this project:

Updates

Submission history