How Harper’s integrated runtime and supervised AI agents helped deliver a faster storefront with substantially less human engineering effort
An established retailer faced a major upgrade to its production e-commerce storefront. Its application was several framework generations behind, and the migration touched routing, rendering, caching, and third-party integrations.
Harper completed the modernization with 211 tracked human engineering hours. A retrospective analysis estimated that using conventional software development methods, this project would have taken 3,800 hours, a reduction of about 94%.
Supervised AI agents performed implementation, testing, and review, while engineers controlled every merge and deployment. Production cutover succeeded on the first attempt without a rollback. The upgraded storefront also delivered 23% lower page load time and 28% lower Largest Contentful Paint (LCP) at the 75th percentile.

How the estimate was developed: A task-by-task analysis covered discovery, migration, integrations, testing, defect resolution, and rollout, with an allowance for coordination and review. It produced an estimated range of 2,600–5,200 human hours, with a central estimate of approximately 3,800. Code-volume and pull-request benchmarks provided additional context. The 94% comparison uses 211.3 tracked delivery-team hours; agent execution and customer-side QA time are separate.
Delivered for about one-sixth of the quoted cost
Harper delivered a platform upgrade quoted at $262,000 for a $40,000 fixed fee—about one-sixth of the traditional quoted cost. That put the completed engagement $222,000 below the quote, a reduction of approximately 85%.

The $40,000 fixed fee covered Harper’s delivery costs and AI usage and generated a profit. The engagement included engineering review and production verification, plus production cutover and post-launch support. For engineering leaders carrying a modernization backlog, the result shows how this approach can change the economics of a substantial upgrade while preserving human accountability for what reaches production.
A framework migration with production consequences
The storefront ran on Next.js 9.5 with the Pages Router, React 16, Node 16, and Harper v4. The engagement moved it to Next.js 16 with the App Router, React 19, Node 24, and the @harperfast/nextjs runtime on Harper v5.
That change required the team to preserve customer-facing behavior while replacing parts of the application’s foundation. The scope spanned 177 UI components, 146 page files, 44 API routes, and approximately 15 third-party integrations. Routes, rendering, data fetching, and caching needed to work with the new architecture. The engagement also included production cutover and post-launch support.
The customer already used Harper. This engagement brought the application and its runtime forward together, pairing a substantial modernization with measurable improvements in storefront performance.

Why the Harper runtime matters
Harper’s runtime helped the team focus its effort on the application. It brings the application runtime, database, cache, and API layer together, reducing the separate services and connections engineers need to configure, integrate, and troubleshoot. With fewer infrastructure boundaries to manage, engineers, and agents can devote more effort to application requirements and verifying customer-facing behavior.
This also matters when AI agents perform the implementation. Every additional service introduces configuration, interfaces, and failure modes that agents must account for and humans must review. A shared runtime gives both a more consistent environment to work within. As Jeff Darnton, who led the engagement, explains, "the team could spend its time and AI tokens on functional requirements rather than building and troubleshooting infrastructure."
For this retailer, the upgrade brought an existing deployment forward to Harper v5, with its Next.js runtime and updated caching architecture. The completed application and runtime modernization also improved storefront performance: time to first byte (TTFB) fell 33%, and LCP fell 28% at the 75th percentile.
The benefit extends beyond delivery. The retailer gained a faster storefront and a shared foundation for ongoing development, with fewer separate infrastructure services to connect and maintain. Engineers remain responsible for verifying customer-facing behavior and deciding what reaches production.

A faster storefront on Harper
The modernization delivered more than an updated technology stack. At the 75th percentile, page load time fell 23%, TTFB fell 33%, and LCP improved 28%. LCP moved from 2.78 seconds to 2.00 seconds, crossing into Google’s “good” range for that measure.

The gains extended to key shopping journeys. Median search-page load time was nearly halved, falling 48%. At the 75th percentile, product-list and product-detail page load times fell 31% and 25%, respectively.
Measurement basis: Customer real-user monitoring before and after modernization. Percentages describe reductions in measured times. The 75th percentile (p75) is the point at which 75% of measured visits were that fast or faster—the same percentile Google uses to assess Core Web Vitals using Chrome User Experience Report (CrUX) data. The search result uses the median. These results reflect the combined application and runtime modernization.
How the agentic engineering team worked
Harper’s internal agent orchestration system organized the work into bounded tasks. A planning agent turned each issue into an implementation specification. A developer agent implemented the change in an isolated working copy. A QA agent tested it against the specification, and a reviewer from a different model family examined the change after QA cleared.
An engineering-manager agent sequenced the backlog, coordinated parallel work, and escalated unresolved questions. Using a different model family for review gave the team another opportunity to challenge the assumptions behind an implementation. Deterministic scripts checked review artifacts, so a claim that review had happened was not enough to pass the gate.
Project state lived in repository history, issues, pull requests, logs, and a persistent memory corpus. Work could continue across fresh agent sessions and a change of human operator without depending on one conversation to retain the whole project. Engineers didn't need to do every implementation step themselves; they focused on exceptions, product intent, verification, and release decisions.
Two principal engineers oversaw the agentic delivery team. Over approximately 853 agent session hours, agents implemented, tested, and reviewed code. Engineers controlled merges and deployments, resolved ambiguous requirements, and verified production behavior. Each of the 589 merged pull requests represented a human merge decision. Humans also controlled credentials and security-sensitive decisions.

What required human judgment and rework
The hardest work was preserving the storefront’s behavior. Of 132 fully classified customer defects, 59% concerned visual or layout parity and 24% concerned UI functionality. First-pass customer QA acceptance was approximately 53%. Fast implementation still required repeated observation, correction, and verification. The 211 tracked human hours include the delivery team’s rework and verification, as well as implementation oversight and delivery.

One third-party integration illustrates the problem. The legacy storefront used full page reloads during pagination, which triggered a vendor script to decorate product cards. The migrated application used client-side navigation. Cards changed without the event the script expected, so the decoration did not run. Real-browser measurement established the mechanism after several plausible explanations had failed.
Other rework exposed gaps between the migration plan and its implementation tasks. Some requirements identified during planning did not survive the breakdown into smaller issues. The experience reinforced the need to check coverage from the original plan through to the delivered application.
Verifying the customer experience
Engineers verified the upgraded storefront in browsers and staging, and product owners confirmed it behaved as expected.

The production result
The initial cutover target moved by 15 days as the team resolved the customer acceptance testing backlog. The engagement’s schedule allowance absorbed that work. Production cutover succeeded on the first attempt, with no rollback, and the consolidated post-launch release shipped on the contractual close date, roughly two months after work began.

None of the 132 classified customer migration defects originated in the Harper platform. The team identified two platform issues internally before customer acceptance testing.
Performance gains were evident after cutover and sustained through post-launch refinement, with further improvements in content rendering. Across 589 merged pull requests, humans retained control of what reached production, combining agent execution with engineering judgment, verification, and accountability for release decisions.
Start with the upgrade on your roadmap
This engagement delivered a substantial production upgrade with about 94% fewer human engineering hours than conventional development would have required—and a faster storefront for customers. For engineering leaders with a modernization backlog, it shows how demanding upgrades can move forward while leaving more capacity for other priorities.
Harper provided the foundation: an integrated application runtime, database, cache, and API layer, paired with supervised AI agents and human control over production releases. Engineers and agents could focus on application requirements and the customer experience. That foundation remains after the migration, supporting ongoing development and future upgrades.
The completed engagement also cost about one-sixth of the traditional quote. Together, reduced engineering effort, lower cost, and improved storefront performance show how Harper can make modernization more achievable for teams balancing delivery demands with limited capacity and budget.
Have an upgrade on your roadmap? Talk to us about modernizing on Harper, reducing demands on your engineering team, and improving the experience your application delivers.






.webp)



