Case study — Plane Sales Global

One operator. A fleet of AI crews.
A marketplace in eight weeks.

Plane Sales Global rebuilt its aircraft marketplace — three portals, Stripe billing, advertising inventory, data migration — with one human operator running Maestro fleets, for roughly $2,300 of tracked model spend.

3 portalsStripe end-to-end2026-05-20 → 2026-07-12up to 5 crews in parallel
31
Voyages (sprints) completed
185
Work orders delivered
~8 weeks
Part-time, one operator
US$2,299
Tracked model spend
undercount — see the honesty section
1
Human operator
126
QA reports
42
Security reviews
2.15B
Tokens processed (tracked orders)

Every number on this page is read directly from the project's own delivery artefacts — the voyage manifests, order records, usage ledgers and reports that Maestro writes as it works. Nothing is estimated after the fact.

The problem

A legacy platform, and a familiar quote

Plane Sales Global (PSG) runs an aircraft marketplace: aircraft, parts and aviation property, listed by private sellers and dealerships, browsed by buyers. The existing site was a legacy platform — dated stack, dated UX, and a growing backlog of things it simply couldn't do: modern listing workflows, self-service seller tooling, online payments, dealer subscription billing, advertising inventory, analytics.

A conventional path would be familiar to anyone who has commissioned software: engage an agency or hire a team, scope a multi-month build, and staff it with several engineers plus a project manager. For a three-portal marketplace with payments, that path is typically quoted in months and in six figures. PSG took a different path: one human operator running Maestro, Anthropic's Claude models doing the engineering work, organised as a disciplined software team rather than a single chat window.

How it worked

A crewed ship, not a chatbot

The Captain is the human operator. They decide what to build and review what ships. They do not write the code.

Orders are individual work items — a feature, a bug fix, an investigation. Each is a small JSON file with a description and acceptance criteria. PSG completed 185 of them. Voyages are sprints: a bundle of related orders that travels on its own git branch and ships as one reviewable pull request. PSG completed 31.

Crews are independent Claude sessions that Maestro dispatches in parallel — up to five at a time, each in its own isolated working copy of the code, so they never trip over each other.

The human stays in the loop at the points that matter: review gates pause work between roles for Captain approval, and every voyage lands as a pull request the operator reviews before merge. PSG additionally ran at least eleven numbered UAT rounds, each spawning remediation voyages the fleet worked through.

The role sequence

The part that makes this engineering rather than prompting: every order passes through a chain of specialist roles, each a fresh Claude session with its own instructions, permissions and deliverables — handing the next a written handoff document.

PLN
Planner designs the change and writes an implementation plan
BLD
Builder implements it
TST
Tester writes and runs tests against the implementation
DOC
Documenter updates the documentation
SEC
Security Auditor reviews the change read-only — it cannot edit code, only report
REL
Release signs off and ships

The same discipline you would demand of a human team — plans, tests, security review, documentation, PR review, UAT — enforced by the framework rather than by hoping everyone remembers.

What shipped

The delivery record, not a marketing reconstruction

The feature narrative below is taken from the titles of PSG's 31 completed voyages and 185 completed orders.

The marketplace itself

Three listing kinds — aircraft, parts and property — each with its own multi-step listing journey, a public search experience with a fully reorganised filter sidebar, standardised aircraft category taxonomy across all portals, and listing lifecycle automation with notification emails.

The seller portal

Self-service listing creation and editing for all three kinds, draft handling with “Pay & Publish”, per-seller listing-type capabilities, dealership profiles with branding, and a shared-component rebuild of the listing forms so seller and admin surfaces can never drift apart again.

Payments and billing — Stripe end to end

Listing fees, paid featured listings with homepage rotation refreshed daily, dealer subscription billing (subscribe, monthly invoicing, upgrade/downgrade, cancel), and price/product sync from the platform’s admin pricing straight into Stripe.

Advertising inventory

A banner-advertising system built, then deliberately rebuilt when requirements matured: seven canonical placements, scheduled creatives with a calendar view, rotation on the public site, monthly per-slot repricing, and per-banner impression/click reporting wired into Google Analytics 4.

Buyer accounts and identity

Three account tiers (Buyer, Private Seller, Dealership) with self-service upgrade paths, dealership applications with admin approval, save-a-listing hearts across the public site, and seamless single sign-on between the public and seller portals.

The admin portal

Full catalogue management, user and dealer administration, create-listings-on-behalf-of-a-customer, content page management, and a rebuilt reporting suite — revenue split by source, payment-method reconciliation, AU financial-year date ranges, XLSX and PDF export.

Data migration from the legacy platform

Live-site users imported from the legacy MSSQL database and split into private and commercial sellers; the aircraft make/model catalogue re-seeded from the legacy export (2,124 active rows, where the new platform previously had 155); 28 missing parts categories restored.

Platform hardening

Transactional email integration, production secrets management, session-expiry warnings with silent token refresh, and a full regression audit that re-verified 32 previously fixed bugs across 11 UAT rounds were still fixed before go-live hardening.

Quality was not an afterthought

126 QA reports. 42 security reviews.

Two numbers in the delivery record matter more than any feature list: 126 QA reports and 42 security reviews, written by the TST and SEC roles as part of the standard sequence.

The security reviews are not checkbox exercises. Every payment-touching feature traced each trust boundary through the code — confirming, for example, that Stripe charge amounts are computed only from database-side pricing rows, never from anything a client sends. The role sequence made it non-optional.

The delivery record is also honest about rework. UAT rounds found bugs; some fixes needed a second pass ("Engine & Prop details stillnot saving" appears verbatim as a retest order). That transparency is a feature of the system: every defect became a tracked order with its own lifecycle, rather than a Slack message that evaporates.

From the SEC review of paid featured listings

"The order touches money movement, so the review centred on three questions: can a client tamper with the charged amount, can a client feature a listing they do not own, and can a listing be featured without a successful payment."
Cost versus time — the honest version

What the ledger says — caveats included

Maestro tracks token usage and estimated API cost per order. Across the 60 orders tracked, PSG's fleets consumed 2,149,635,108 tokens at an estimated US$2,299.41. The heaviest single sprints were the banner-advertising overhaul (~$332), the three-tier account signup journeys (~$312), the legacy lookup-data overhaul (~$300), dealer branding plus the admin reporting rebuild (~$282), and listing payment flow polish (~$238).

The spend figure is an undercount.

Usage tracking was added mid-project, so the $2,299.41 covers the last 60 of 185 orders. The tracked portion skews toward the later, larger voyages, but the true whole-project model spend is unavoidably higher than the tracked figure. A conservative reading: think “single-digit thousands”, not “$2.3k exactly”.

Token counts are dominated by cache reads.

The 2.15 billion tokens are mostly prompt-cache re-reads (which is precisely why the cost is low relative to the token count) — quoted for transparency, not to impress.

Model spend is not total cost.

One human operator ran this part-time for ~8 weeks — reviewing PRs, running UAT, writing orders. Their time is real and is not in the $2,299.

This was an uplift with a reference.

The legacy site provided requirements clarity that a greenfield product wouldn’t have.

The comparison. We will not fabricate a competitor quote. Instead, a clearly-labelled assumption: a three-portal marketplace with Stripe billing, advertising inventory, identity tiers, data migration and an admin suite is — in our experience and by widely published agency rate norms — a multi-month engagement for a team of roughly three to six people. At typical blended agency rates (US$75–150/hour), even a lean four-month, three-person delivery lands in the US$150,000–400,000 range before overruns. Treat those numbers as the labelled assumption they are, and the contrast still holds at any point in the range:

Eight weeks, one part-time operator, and low-thousands of model spend — versus months of calendar time and six figures of engineering cost — for a platform of directly comparable scope.

The interesting claim is not "AI is cheaper per hour". It is that the coordination overhead that normally forces teams to be large — handoffs, context transfer, review discipline, parallel workstreams — is exactly what Maestro automates. PSG ran up to five crews in parallel across 31 sprints without a project manager, because the framework is the project manager.

What this means for your backlog

The cadence of a team.
The cost profile of an API bill.

PSG is one data point, and we've presented it with its caveats attached. But the shape of the result generalises: if your backlog is well-described work — features, fixes, migrations, hardening — a Maestro fleet can work through it while you keep the two controls that matter: what gets built, and what gets merged.

Sources: all metrics in this case study are read from the PSG project's Maestro workspace artefacts — voyage manifests, order records, per-order usage ledgers, and QA/security reports — as gathered on 2026-07-14. Feature names and aggregate metrics are published with the client's sanction; no client-confidential data appears in this document.