Development Agency
Contact Sign in Get a project quote

Service

Service comparison platform development

For comparison sites and switching services that compare plans, tariffs, subscriptions or packages against what a user enters, and need the plan term schema, matching logic, results ordering, disclosure blocks, provider hand-off and update workflow designed around their categories and provider agreements.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A service comparison site usually begins as a set of tables maintained by hand from provider websites.

  • A broadband plan has a monthly figure, a contract length, a speed and a setup fee typed into a page, and when the provider changes the terms nobody notices until a user complains that the figure on the site is wrong.
  • The "compare" function is a filter over those typed rows, so a user who enters their postcode and usage gets a list ordered by whatever the editor put first.
  • Which provider pays the site a commission, and whether that affects the order, is not written anywhere a user would find it.

Where it gets harder

The hand-off is a link to the provider site.

  • The site does not know whether the user signed up, whether the provider counted it, or whether the commission statement that arrives a month later matches the clicks that were sent.
  • Provider account managers email spreadsheets of new plans in different layouts, and someone retypes them.
  • Reviews are collected in a plugin with no check that the reviewer is a customer of that provider.
  • The operator cannot say which plans are current, which inputs users enter most, which results get clicked, or which provider's terms changed last week without being updated.

Scope of the service

What the build covers

A custom service comparison build normally covers:

  • Provider and plan records with a term schema per category So an energy tariff carries unit rates, standing charges and exit fees while a broadband plan carries speed, contract length and setup fee, each term stored with the date the provider supplied it and the source
  • An input form per category that captures what matching needs Such as postcode, usage, household size or preferences, with branching
  • A matching and calculation layer That turns inputs and terms into a comparable figure per plan, with the calculation method published on the site
  • A results page whose ordering rule is disclosed in plain words beside the list, with any commercial relationship labelled on each result and a disclosure block that explains how the site earns
  • Provider hand-off that records the click Passes a reference to the provider and accepts a confirmation back by API, file or portal so the outcome can be reconciled against commission statements
  • A provider data workflow Where feeds or submitted plan sheets land in an update queue, differences are shown to a provider manager and nothing changes on the site until approved
  • User reviews tied to a hand-off where possible and moderated
  • Saved comparisons for returning users

How discovery works

Discovery follows one user from inputs to a reconciled hand-off with you: which categories you compare and what terms each needs, how the comparable figure is calculated and how that is explained, how results are ordered and what the page must say about it, how providers deliver plan changes and who approves them, how hand-offs are confirmed and matched to statements, whether reviews are collected and from whom, and what disclosures must appear and where. Each answer becomes a named stage in the scope document: define terms, collect inputs, calculate, order, disclose, hand off, confirm, reconcile, update.

Deliberately out of scope

  • Completing the switch or contract on the platform where the provider does that, holding any payment, and advising a user which plan to choose beyond the published calculation. We also make no promise about where category pages appear in search engines
  • They are built crawlable with structured plan data and our claim stops there

When the scope grows

Scoping scenario

A switching service covering three household utilities with providers who deliver plan sheets monthly, a results page that must explain its ordering and commission, and hand-off confirmations arriving from providers in three different ways. That is a different build from a single-category site with typed tables and a plain outbound link, and the scope document says which is being built.

Deliverables

What you receive

  • Discovery notes from following one user from inputs to a reconciled hand-off
  • A written scope document naming each stage from terms to update, with the ordering and disclosure rules written out and what is out of scope
  • Design of the input form, the results page with its disclosure block, the plan detail page, the provider manager update queue and the reconciliation screen, on mobile for users and desktop for the operator
  • The build, deployed to your hosting or ours
  • Migration of current plan tables into the term schema, with a report of plans missing required terms
  • Training for the provider manager and the editor, with a short written guide for the update queue and disclosures
  • 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, current plan tables, provider agreements describing commission and confirmation methods, and existing disclosure wording.

    Project stage: Onboarding

  2. Planning

    Discovery with the operator, the provider manager and an editor; the scope document, the term schemas, the ordering rule and the milestone plan are agreed.

    Project stage: Planning

  3. Design

    Clickable designs of the input form, the results page with disclosure block, a plan page and the update queue, reviewed with two provider contacts.

    Project stage: Design

  4. Development

    Built in stages: term schemas and plan records first, then inputs, calculation and results, then hand-off and confirmation, then update queue, reviews and reconciliation.

    Project stage: Development

  5. Client review

    Your team enters real inputs, checks calculated figures against provider documents, runs a provider update through the queue and matches test confirmations.

    Project stage: Client review

  6. Revisions

    Term fields, calculation wording, ordering disclosure and confirmation mappings are adjusted from the review and re-checked against the scope.

    Project stage: Revisions

  7. Ready for launch

    Plans migrated, old URLs redirected, hand-off references tested with each provider, confirmation channels tested, 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.

  • Provider plan feeds and submitted plan sheets by API, file or portal
  • Provider confirmation channels for hand-off outcomes by API, file or portal
  • Postcode and address services for availability by area
  • Email and SMS providers for saved comparisons, reminders and review invitations
  • Affiliate and commission reporting platforms for statement reconciliation
  • Accounting software for commission invoices
  • Analytics for input patterns and result clicks per category

How we would approach it

Worked example

Concept demo

A three-utility switching service with monthly plan sheets

The situation

A switching service compared energy, broadband and mobile plans from providers who sent plan sheets monthly in their own layouts, and had no record of which hand-offs became customers.

Why it is a custom build

This needs a custom build because the three confirmation channels and the per-provider parsers are specific to the operator, and because the ordering and disclosure rules have to be enforced by the results page rather than by editorial habit.

The scope we would propose

  • A term schema per utility with a parser per provider layout feeding an update queue, where the provider manager sees each changed term beside the current one and approves before anything changes on the site
  • An input form per utility with postcode availability checks
  • A calculation layer that produces an annual figure per plan with the method published
  • A results page with the ordering rule and a commission label on each result, plus a disclosure block
  • Hand-off references passed to each provider and confirmations accepted by API from one, by weekly file from another and by portal entry for the third
  • A reconciliation screen matching confirmations to commission statements

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 term schema
  • Calculation complexity and how the method is explained on the page
  • Ordering rules and the disclosure and labelling required
  • Provider data formats and the parsers and update queue needed
  • Hand-off confirmation channels per provider and reconciliation depth
  • Availability checks by postcode or area
  • User reviews, their tie to hand-offs and moderation
  • Saved comparisons and reminder messaging
  • Hosting choice: your own hosting or ours

Start from a package

Service comparison package

Provider and plan records with term schemas per category, input forms that drive matching and calculation, results with a disclosed ordering rule and commission labels, tracked provider hand-off, an update queue for plan changes, moderated reviews and saved comparisons.

Custom build
View the package

FAQ

Frequently asked questions

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

A site comparing one or two categories with plan sheets entered through the update queue, a published ordering rule and link-based hand-off is usually covered by the service comparison package through configuration. A custom build is the honest answer when providers deliver data in many formats, when confirmations arrive by several channels and must be reconciled, or when the calculation has regulatory wording you must reproduce exactly. Discovery is where we tell you which.

How is the results order explained to users?

The rule is written in plain words beside the results, such as "ordered by estimated annual cost, lowest first", and any result where the site earns a commission carries a label. If you choose to offer a sponsored position it is labelled as such and limited by configuration. The rule is a setting, not an editorial choice made per page.

Are plan terms checked by the platform?

No. Terms are shown as supplied by the provider, with the date supplied, and the plan page says so. The update queue makes sure a change is seen and approved by your provider manager before it appears; it does not make the platform responsible for the provider being right.

How is a hand-off tracked?

The click is recorded with a reference, the reference is passed to the provider, and the provider confirms outcomes back by whichever channel the agreement allows. The reconciliation screen matches confirmations to statements so you can see which hand-offs were counted and which were not.

Who owns the platform afterwards?

You do. Source code and your data, including plan records, inputs, hand-offs, confirmations, reviews and reconciliation history, are handed over at delivery; hosting and maintenance are optional and separately agreed.

Get a project quote for service 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