ShipCheap

Project-aware backend hosting decisions without billing jumpscares—powered by WebMCP.

Comment

Inspiration

Choosing a backend host looks simple until a developer has to reconcile runtime support, database needs, region availability, credit-card requirements, sleeping services, free-tier limits, and surprise usage bills. Most comparison pages make people translate one real project into dozens of filters and pricing tables.

ShipCheap began as a human-first backend hosting decision board. For the WebMCP Challenge, I turned it into a shared workspace where a person can describe or link a real project, let an agent do the repetitive analysis, and still review every important result in the same visible interface.

What it does

ShipCheap helps developers:

  • rank backend hosts from runtime, budget, database, uptime, card access, region, and risk tolerance;
  • compare providers in a visible decision table;
  • simulate 1,000 deterministic monthly billing scenarios;
  • inspect percentiles, budget-overrun probability, and likely cost spikes;
  • review provider-specific launch checks;
  • sign in and link a public GitHub repository by URL;
  • approve a read-only GitHub App for private repositories;
  • detect a repository's stack and save project-specific hosting recommendations.

Why WebMCP

Hosting selection is structured but multi-step. Without WebMCP, an agent must guess which controls to click, scrape result cards, and reconstruct application state. ShipCheap exposes eight purpose-built tools instead:

  • open_project_workspace
  • list_linked_projects
  • list_available_github_repositories
  • start_github_app_installation
  • analyze_github_repository
  • recommend_backend_hosts
  • open_backend_host_comparison
  • preview_billing_risk

The agent can turn plain-language constraints into ranked recommendations, open the exact comparison or simulator, and—after the user chooses a repository—build a project-aware analysis. The person and agent share the same visible state throughout.

Human control and data protection

The agent advises and configures; it cannot silently create an account, approve GitHub access, attach billing, spend money, or deploy infrastructure. Private repository access uses a read-only GitHub App. Project reads and writes are authorized server-side against the signed-in Clerk user ID, and the database enforces repository and installation constraints.

How I built it

ShipCheap is a Next.js 16 App Router application written in TypeScript and React, styled with Tailwind CSS, and deployed on Vercel. Prisma stores data in PostgreSQL on Neon. Clerk provides authentication, and a GitHub App provides read-only repository access.

The WebMCP layer lives in src/components/WebMCPTools.tsx and registers tools through document.modelContext.registerTool. Each tool uses a strict JSON Schema, validates inputs during execution, cleans up registrations with an AbortController, and returns concise structured results. The integration is progressive enhancement: the site and public decision workflow still work when WebMCP or authentication is unavailable.

What I changed during the challenge

ShipCheap existed before the challenge. During the submission period I added the eight-tool WebMCP layer, expanded the provider catalog and comparison surfaces, connected the tools to the existing recommendation and billing-risk logic, added Clerk authentication, created the project workspace, integrated the read-only GitHub App, added repository stack detection and project-specific recommendations, migrated persistence to Neon PostgreSQL, documented the public testing flow, and verified all eight tools on the deployed app in ChatGPT's in-app browser.

Challenges

The hardest design problem was deciding where agent authority should stop. A hosting assistant that can silently install integrations, deploy, or spend money would be risky, so ShipCheap keeps approval and consequential actions with the person.

The second challenge was maintaining one source of truth. WebMCP tools reuse the same provider data, recommendation functions, repository analyzer, and billing simulator as the visible UI instead of maintaining a separate agent-only model.

Accomplishments

  • A working deployed product rather than a WebMCP-only proof of concept.
  • Eight non-trivial tools spanning public decisions and authenticated project analysis.
  • Visible shared state between human navigation and agent actions.
  • Repository-aware recommendations for public and approved private GitHub projects.
  • Strict validation, server-side ownership checks, and explicit safety boundaries.
  • A public MIT-licensed repository with reproducible setup instructions.

What I learned

Useful agent-native design is less about exposing many actions and more about exposing the right decision boundaries. Structured tools compress repetitive analysis, while visible state and explicit approval keep consequential choices understandable and human-controlled.

What's next

Next steps include live pricing-source verification, richer project reports, additional providers, and deeper authenticated end-to-end testing. These are future directions, not claims about the current submission.

Built With

Share this project:

Updates

Submission history