BoostSR: building the platform behind an Amazon growth service

BoostSR is a growth service for brands selling on Amazon. Its team finds what is holding a listing back, makes the creative, ships listing and advertising changes, and tracks what happens. It is software and a managed service together: the platform connects each seller’s Amazon data, and BoostSR’s people use it to do the work.

We designed and built the whole platform end to end, and we continue to develop it. This is how it came together, how it is built, and what it suggests for any service business thinking about software of its own.

The client and the problem

The service BoostSR sells depends on reading a lot of data well. To decide what to change on a listing, you need search demand, impressions, clicks, cart adds and purchases, alongside the listing itself, the advertising results and some market context. Amazon provides most of that, but spread across separate reports, consoles and campaign views.

Many Amazon sellers track performance the same way: exports from Seller Central and the advertising console, assembled into spreadsheets and read alongside reports scattered across different places. It works, up to a point. Every new question means another export, the numbers are only as current as the last pull, and much of the time goes on preparing data rather than acting on it. BoostSR’s platform is built to replace that way of working: the data arrives on its own, and the analysis is already done when the team opens an account.

A growth service has a second need. Clients need to see what is happening on their account and sign off changes before they go live. Doing that over email and shared files is hard to keep clear, and harder to keep consistent across accounts.

So the platform also had to be one place where BoostSR’s team and its clients work from the same view.

What we built

The platform has three parts.

Ingestion. Sellers connect their accounts through Amazon’s official authorisation for the Selling Partner API (SP-API) and the Amazon Ads API, so no Amazon password is ever shared. From there, the platform keeps listing data in sync on a schedule and collects daily advertising reports at campaign, targeting and placement level.

Analysis. Daily advertising data is rolled up into account, campaign and placement views, so the team can see where spend is working and where shoppers drop out without rebuilding the numbers each time. Listing changes are run as structured, scheduled tests, with an approval step before anything reaches Amazon.

The client dashboard. Clients and the BoostSR team share one workspace for advertising performance, campaign and placement management, and planning, approving and reviewing listing changes. It also includes a workspace for developing and reviewing listing creative. The point is that a decision, the data behind it and its result all sit in the same place.

We also did the product and interface design. Advertising data is dense, and the people using it need to make decisions quickly, so the screens are designed around those decisions rather than around the raw reports.

How it’s built

For technical buyers, here is the shape of it.

The platform is TypeScript end to end. The application uses TanStack Start (React), with Effect for structuring the server-side logic, particularly error handling and retries. Data lives in MySQL on PlanetScale, accessed through Drizzle ORM. It runs on Cloudflare: Workers for the application, Queues and Workflows for background work, Durable Objects for coordination, and R2 for file storage.

Keeping to one language and one platform matters for a small team. The same types run from the Amazon integration to the screen, and there is very little infrastructure to look after.

Two problems took most of the engineering effort.

Large, slow, changing advertising reports

Amazon’s advertising reports are not a simple request and response. You ask for a report, wait for Amazon to prepare it, then download what can be a large file. Amazon also restates recent days as attribution settles, so yesterday’s figures may not be final.

A naive import, which downloads the file, loads it into memory and writes everything, breaks on all three counts. It runs out of memory on big accounts, fails part-way with nothing to show for it, and either duplicates or misses restated data.

So the import runs as a durable workflow. Reports are streamed and processed in chunks rather than loaded whole. Each step can be retried on its own, so a failure halfway through resumes rather than starting again. Writes are idempotent, which means running the same step twice leaves the data in the same state as running it once, so retries are safe. And the pipeline recognises days whose data has not changed and skips them, so restatements are picked up without reprocessing everything.

Dashboards that stay fast as accounts grow

Advertising data grows quickly. A busy account produces a large number of rows per campaign, per placement, per day, and a dashboard that is fast on a small account can become slow on a large one.

We handled this in two ways. Common views read from daily rollups that are calculated in advance, rather than adding up raw rows each time a page loads. The queries behind them are backed by indexes designed for exactly those queries.

We test performance changes against a seeded benchmark: a large synthetic account built from test data, not customer data, so we can show a change is faster before it ships rather than guess.

Scale today

BoostSR reports $17.2M a month in combined sales across the 38 accounts it manages (boost-sr.com, October 2026).

These are BoostSR’s own published figures, not results Aquila produced, and they change over time; the current figures are on boost-sr.com.

The clearest change in the day-to-day work is listing creative. The platform’s creative workspace produces a first set of listing images in minutes, which BoostSR’s team then reviews and refines before anything goes live.

What this means for your service business

BoostSR is an Amazon business, but the pattern is common to a lot of service firms. The expertise is the product. The work depends on data from other systems. And a growing share of the team’s time goes on gathering and checking that data instead of using it.

A few things from this project carry over.

Build around the service, not the data. The platform is organised around what BoostSR’s team does: read the account, find an opportunity, make a change, check the result. The data integrations serve that loop. If you start from “let’s put all our data in one place”, you tend to end up with a warehouse nobody uses.

Give clients a view, not a report. Moving approvals and results into a shared dashboard did more than save on email. Clients can see what is happening on their account and why, which is part of what they are paying for.

The hard parts are in the plumbing. The interesting engineering here was not the charts. It was making slow, large and changing third-party data arrive reliably, and keeping the screens fast as accounts grew. That is most of what Amazon seller software development comes down to. If your service relies on someone else’s API, expect the same, and plan for retries, restated data and growth from the start.

You don’t have to start with everything. A platform like this can begin with one integration or one reporting workflow that removes the most manual work, then grow from there.

If your team is spending its expertise on spreadsheets, we’re happy to talk through what a sensible first phase could look like.