Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Case Study
GitHub Logo

How Harper Modernized a Retail Website with 94% Less Engineering Effort and 85% Lower Cost

See how Harper’s unified runtime and supervised AI agents modernized a production storefront while engineers retained control of quality and releases.
Digital Commerce
Case Study
Digital Commerce

How Harper Modernized a Retail Website with 94% Less Engineering Effort and 85% Lower Cost

Harper
at Harper
October 27, 2026
Harper
at Harper
October 27, 2026
Harper
at Harper
October 27, 2026
October 27, 2026
See how Harper’s unified runtime and supervised AI agents modernized a production storefront while engineers retained control of quality and releases.
Harper

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.

Estimated conventional engineering effort of 3,800 hours compared with 211 tracked Harper delivery hours, approximately 94% fewer human hours; estimated range 2,600–5,200 hours.
Figure 1  Estimated conventional human effort compared with Harper’s tracked delivery-team hours

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%.

Traditional modernization quote of $262,000 compared with Harper’s $40,000 fixed fee, about one-sixth of the quoted price and $222,000 less.
Figure 2  Commercial outcome of the modernization engagement

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.

Migration from Next.js 9.5 Pages Router, React 16, Node 16, and Harper v4 to Next.js 16 App Router, React 19, Node 24, and Harper v5, preserving routes, rendering, data fetching, caching, and integrations.
Figure 3  Framework and runtime migration scope with customer-facing behavior preserved

‍

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.

Harper unified runtime brings application logic, API access, cache, and database together in one Node.js process beneath storefront requests.
Figure 4  Shared runtime capabilities provide a common foundation for application work

‍

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.

Storefront performance at p75: TTFB falls from 1.59 to approximately 1.07 seconds, LCP from 2.78 to 2.00 seconds, and page load time from 3.99 to approximately 3.07 seconds.
Figure 5  Storefront performance improvements at p75 following the modernization on Harper

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.

Engineering manager agent coordinates planning, development, QA, and review; verified work proceeds to separate human merge and deployment decisions.
Figure 6  Supervised delivery workflow with agent verification and separate human merge and deployment 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.

Among 132 classified customer defects, 59% involve visual and layout parity, 24% UI functionality, and approximately 17% other categories; none originated in the Harper platform.
Figure 7  Migration parity dominated the classified customer defects

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.

Five verification stages: unit tests for component behavior and data flow; adversarial QA and review; real-browser checks; staging verification; and product-owner confirmation under exact customer conditions.
Figure 8  Verification progresses from code checks to the exact customer experience

‍

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.

Delivery timeline: kickoff on day 0, initial cutover target on day 38, successful cutover with no rollback on day 53, and final release at contractual close on day 61; 15 days of schedule allowance used.
Figure 9  Delivery milestones and schedule allowance from kickoff to contractual close

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.

‍

‍

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.

Estimated conventional engineering effort of 3,800 hours compared with 211 tracked Harper delivery hours, approximately 94% fewer human hours; estimated range 2,600–5,200 hours.
Figure 1  Estimated conventional human effort compared with Harper’s tracked delivery-team hours

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%.

Traditional modernization quote of $262,000 compared with Harper’s $40,000 fixed fee, about one-sixth of the quoted price and $222,000 less.
Figure 2  Commercial outcome of the modernization engagement

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.

Migration from Next.js 9.5 Pages Router, React 16, Node 16, and Harper v4 to Next.js 16 App Router, React 19, Node 24, and Harper v5, preserving routes, rendering, data fetching, caching, and integrations.
Figure 3  Framework and runtime migration scope with customer-facing behavior preserved

‍

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.

Harper unified runtime brings application logic, API access, cache, and database together in one Node.js process beneath storefront requests.
Figure 4  Shared runtime capabilities provide a common foundation for application work

‍

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.

Storefront performance at p75: TTFB falls from 1.59 to approximately 1.07 seconds, LCP from 2.78 to 2.00 seconds, and page load time from 3.99 to approximately 3.07 seconds.
Figure 5  Storefront performance improvements at p75 following the modernization on Harper

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.

Engineering manager agent coordinates planning, development, QA, and review; verified work proceeds to separate human merge and deployment decisions.
Figure 6  Supervised delivery workflow with agent verification and separate human merge and deployment 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.

Among 132 classified customer defects, 59% involve visual and layout parity, 24% UI functionality, and approximately 17% other categories; none originated in the Harper platform.
Figure 7  Migration parity dominated the classified customer defects

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.

Five verification stages: unit tests for component behavior and data flow; adversarial QA and review; real-browser checks; staging verification; and product-owner confirmation under exact customer conditions.
Figure 8  Verification progresses from code checks to the exact customer experience

‍

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.

Delivery timeline: kickoff on day 0, initial cutover target on day 38, successful cutover with no rollback on day 53, and final release at contractual close on day 61; 15 days of schedule allowance used.
Figure 9  Delivery milestones and schedule allowance from kickoff to contractual close

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.

‍

‍

See how Harper’s unified runtime and supervised AI agents modernized a production storefront while engineers retained control of quality and releases.

Download

White arrow pointing right
See how Harper’s unified runtime and supervised AI agents modernized a production storefront while engineers retained control of quality and releases.

Download

White arrow pointing right
See how Harper’s unified runtime and supervised AI agents modernized a production storefront while engineers retained control of quality and releases.

Download

White arrow pointing right

Explore Recent Resources