Development Agency
Contact Sign in Get a project quote

Service

Product comparison platform development

For affiliate publishers and comparison brands who review and compare physical products and need the attribute schemas, retailer feed handling, comparison tables, editorial workflow and disclosure rules designed around their categories rather than a generic review theme.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A comparison publisher typically grows from a blog.

  • Each review is an article; specifications are typed into a table block by the writer, so the same laptop has a different battery figure in three articles and the "best of" roundup was last updated when someone remembered.
  • Prices are typed into the text with an affiliate link pasted beside them, which means every price on the site is wrong within a fortnight and nobody knows which ones.
  • When a retailer changes an affiliate programme, someone searches the site for old links by hand.
  • A comparison table between two products is built in a spreadsheet and screenshot into the article.

Where it gets harder

Disclosure is a line in the footer that nobody connects to the product it applies to.

  • Sponsored placements are negotiated by email and inserted by an editor, so the same product may be sponsored in one roundup and reviewed "independently" in another with no record of which.
  • User ratings sit in a comments plugin that cannot be moderated properly and are averaged by whatever the plugin does.
  • The publisher cannot answer the questions that matter: which products have a current price from which retailer, which attributes are missing per category, which comparisons readers actually build, and which affiliate clicks come from which page.

Scope of the service

What the build covers

A custom product comparison build normally covers:

  • An attribute schema per category with units Allowed values and a version history, so a change to the schema never silently breaks old product records
  • Product records with a source and date against each attribute value Whether that source is a manufacturer sheet, a retailer feed or an editor
  • Retailer feed imports That supply prices and availability with the feed name and fetch time stored against every offer, so a price is never typed and every displayed price shows where it came from and when
  • Affiliate link handling that stores the programme Rewrites links centrally and shows a disclosure beside each outbound link rather than only in the footer
  • Comparison tables generated from the schema With differences highlighted and the data sources and dates printed beneath the table
  • An editorial workflow For reviews and verdicts with a dated changelog on the page
  • User ratings submitted under a published rule and moderated
  • Price history per offer
  • Sponsored placements that are labelled on the page Recorded with dates, and kept apart from editorial verdicts in the data model

How discovery works

Discovery follows one product from a feed row to a published comparison with you: which categories and attributes matter and who maintains the schema, which retailer feeds you have access to and how often they update, how affiliate programmes are tracked and disclosed, how editorial verdicts are written and revised, whether readers rate products and how those ratings are moderated and aggregated, and how sponsored placement is sold and labelled. Each answer becomes a named stage in the scope document: define schema, import feed, normalise, match, compare, review, disclose, publish, revise.

Deliberately out of scope

  • Selling products on the platform, holding stock, or promising that a retailer price is still correct at the moment a reader clicks through, which is why every price carries its source and fetch time. We also make no promise about where comparison pages appear in search engines
  • They are built crawlable with structured product data and that is where our claim ends

When the scope grows

Scoping scenario

A publisher covering six consumer electronics categories with feeds from four retailers, editorial reviews with a verdict, reader ratings and a sponsored slot in each roundup. That is a different build from a single-category site with one feed and no editorial, and the scope document says which is being built.

Deliverables

What you receive

  • Discovery notes from following one product from feed row to published comparison
  • A written scope document naming each stage from schema to revision, with disclosure rules written out and what is out of scope
  • Design of the category page with filters, the product page, the comparison table, the editorial review layout and the data manager screens, on mobile for readers and desktop for editors and data managers
  • The build, deployed to your hosting or ours
  • Migration of existing reviews and specification tables into the schema, with a report of attributes that could not be mapped
  • Training for editors and the data manager, with a short written guide for feeds, sources and disclosure
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts, your category list, feed credentials, affiliate programme details, existing reviews and your current disclosure wording.

    Project stage: Onboarding

  2. Planning

    Discovery with the publisher, an editor and whoever manages feeds; the scope document, the schemas and the milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of a category page, a product page, a comparison table and the review layout, reviewed with two editors.

    Project stage: Design

  4. Development

    Built in stages: schemas and product records first, then feeds, offers and affiliate links, then comparison and filters, then editorial, ratings, sponsorship and reporting.

    Project stage: Development

  5. Client review

    Your team runs the live feeds for a week, checks prices against retailer pages, builds comparisons and publishes a test review with a sponsored slot.

    Project stage: Client review

  6. Revisions

    Attribute schemas, matching rules, disclosure placement and verdict layout are adjusted from the review and re-checked against the scope.

    Project stage: Revisions

  7. Ready for launch

    Reviews migrated, old URLs redirected, feeds scheduled, affiliate links tested end to end, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The platform runs on the new build; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Retailer and affiliate network product feeds by file or API
  • Affiliate link tracking and reporting platforms
  • Manufacturer specification sources where available
  • Image storage and optimisation services for product photography
  • Email providers for price alerts to readers
  • Advertising platforms for sponsored placement reporting
  • Analytics for outbound click attribution per page

How we would approach it

Worked example

Concept demo

A six-category electronics publisher moving off typed prices

In this scoping scenario, a publisher with several hundred reviews across six consumer electronics categories had every price typed into article text and no record of which affiliate programme each link belonged to. The scope we would propose: attribute schemas per category with a version history, product records matched to four retailer feeds by identifier with a manual match queue for the rest, offers stored with feed name and fetch time so every displayed price reads "from retailer X, fetched at this time", centrally managed affiliate links with a disclosure beside each one, comparison tables generated from the schema with differences highlighted and sources printed beneath, editorial verdicts with a dated changelog, moderated reader ratings aggregated by a published rule, and a sponsored slot per roundup that is labelled and recorded with dates.

This needs a custom build because the feed matching and the separation of sponsored and editorial content in the data model are particular to the publisher, and because the migration of typed specifications into the schema is a project in itself.

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of categories and the size of each attribute schema
  • Number and format of retailer feeds and the matching rules required
  • Affiliate programmes to track and the disclosure placement
  • Editorial workflow depth: review stages, verdicts, changelog
  • Reader ratings, moderation and the aggregation rule
  • Price history and reader price alerts
  • Sponsored placement rules and reporting
  • Volume of existing reviews and specification tables to migrate
  • Hosting choice: your own hosting or ours

Start from a package

Product comparison package

Attribute schemas per category with version history, product records with a source and date per value, retailer feed offers with source and fetch time, generated comparison tables, editorial verdicts with changelogs, moderated reader ratings and labelled sponsored placements.

Custom build
View the package

FAQ

Frequently asked questions

Would the package do, or do we need a custom build?

A publisher with a few categories, one or two retailer feeds, editorial reviews and disclosed affiliate links is usually covered by the product comparison package through configuration. A custom build is the honest answer when feeds need bespoke matching, when the schema changes often and needs version history across hundreds of records, or when sponsored and editorial content must be separated for an external audit. Discovery is where we tell you which.

Where do the prices come from?

From retailer or affiliate network feeds only. Each offer stores the feed, the price, availability and the fetch time, and the page shows that source and time beside the price. Editors cannot type a price; if a feed has no offer for a product, the page says so rather than showing a stale figure.

How are affiliate links and sponsorship disclosed?

Each outbound affiliate link carries a disclosure beside it, not only in the footer, and sponsored placements are labelled where they appear with dates recorded against them. Editorial verdicts are stored separately from sponsorship so a reader can see which is which and you can show that record if asked.

How is this different from service comparison?

Product comparison compares attributes of physical products from feeds and editorial testing. Service comparison compares plans and terms, such as tariffs or subscriptions, against what the reader enters about their own usage, and hands them off to a provider. Different data model, different pages, different topic.

Who owns the platform afterwards?

You do. Source code and your data, including schemas, product records, offers, reviews, ratings and sponsorship records, are handed over at delivery; hosting and maintenance are optional and separately agreed.

Get a project quote for product comparison software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences