Strategy
Shortlisting landing page software with one scorecard
Shortlist landing page software with one scorecard: same requirements, same test page, same synthetic lead and written quotes for six named candidates.
Six builders are a starting list, not a shortlist. Unbounce, Instapage, Leadpages, Landingi, Swipe Pages and HubSpot appear here as candidates to test, not endorsements. A scorecard marks each one against the same requirements and attaches evidence to every mark, so a polished demonstration cannot hide a failed requirement.
What to take away
- Decide first whether buying beats extending the current website or a manual process.
- Treat the six named builders as candidates, and confirm capabilities and terms with each supplier directly.
- Score every candidate on the same written requirements, and attach evidence to each mark.
- Do not let a strong result on one row conceal a failure on a mandatory one.
- Compare written quotes and full terms, not a headline subscription price.
Decide whether to buy at all
Compare buying a page builder with extending the current website or a manual process before naming any product. If the problem is only a preference for new software, stop or redefine the work. The strategy framework gives the wider context.
The scorecard only makes sense once buying has beaten those options on a recorded problem. Record whether the need is a standalone builder or landing-page capability inside a wider platform.
Record also whether the purchase route is direct, through a procurement framework or a competitive tender, as your organisation's rules require. Both facts change which candidates belong on the list. Name on the scorecard which job each product is being marked for. The delivery models differ in how they are bought and run.
Name the candidates and set one entry gate
Start with Unbounce, Instapage, Leadpages, Landingi, Swipe Pages and HubSpot as candidates, not endorsements. Confirm current capabilities and terms directly with each supplier, because this list says nothing about what any of them offers today. Then add any other product that meets the same requirements.
Set one entry gate before scoring. Do not shortlist a candidate that cannot publish the required page and transfer or export captured lead data to the intended destination. Scoring a product that fails this gate only uses time that the remaining candidates need.
Write the requirements before any demonstration
Use one scorecard for every candidate. Each row is a requirement, and each cell gets Meets, Partly or Does not meet, with a source attached: documentation, a demonstration or a test you ran yourself.
| Requirement | What to check | Evidence to attach |
|---|---|---|
| Page creation and publishing | The required page can be built, approved and published | The built test page |
| Forms and validation | Required and optional fields, error handling, spam controls | Valid and invalid test entries |
| CRM connection | Native connector or webhook delivers the lead record | The received test record |
| Variant testing | Variants can be set up and assigned | A recorded assignment |
| Thank-you page and goals | Completion page and goal event fire as intended | The goal event log |
| Source and campaign tracking | Traffic-source and campaign details reach the record | The stored values |
| Accessibility | Form labels, errors and navigation work for assistive use | Notes from a direct check |
| Consent controls | Non-essential tags stay inactive until a choice is made | A before and after tag record |
| Roles, export and deletion | User roles, data export and deletion routes exist | Settings pages and a test export |
| Support and licence terms | Support route and written licence terms | Supplier documents |
Documentation shows what a supplier says the product does. A demonstration shows it working once, usually on the supplier's own material. A test shows it working on your page with your synthetic lead. Prefer the test wherever a row is mandatory.
Mark each row mandatory or desirable before the first demonstration, and write that down. A requirement that becomes optional after a sales call was never a requirement.
Mark the evidence, not the pitch
Score every candidate on the same written requirements, in the same order. Mark Meets only when evidence is attached to the cell. Mark Partly when the evidence shows the requirement works in some cases only. Mark Does not meet when it fails, and say what failed.
Never let a strong result on one requirement conceal a failure on a mandatory one. Mark any supplier claim you cannot verify as unresolved rather than guessing. For the consent row, test the candidate's controls against the ICO's guidance, which asks whether all storage and access technologies require consent.
Ask for the written quote
Ask each candidate for a written quote covering setup, subscriptions, users, traffic or page limits, add-ons, integrations, support, renewal and cancellation. Compare the full terms alongside capability. A headline subscription price is not a reason to choose a product.
Request licence and renewal terms in writing too, including limits, paid add-ons, integration charges and cancellation conditions. Put the figures in a whole-life cost ledger and read the contract terms before signing.
A supplier's security answer is a starting point only. The NCSC says organisations of any size should decide whether a cloud provider is secure enough for their requirements, and a sales answer does not settle that.
Run the same test page for every candidate
Give each shortlisted candidate the same test page and the same synthetic lead. This is a workflow test. It shows whether the product does the job, not whether conversion improves, and it must not be reported as a result.
Check the source and campaign details, required and optional form fields, validation, a separate marketing choice, CRM record transfer through the native connector or webhook, duplicate handling, the thank-you page, the goal event and variant assignment. Write the expected and observed result beside each.
Build only with synthetic records. Pause if production data is needed merely to prove the basic workflow, and treat that need as a finding about the candidate rather than an obstacle to work around.
Read the scorecard
Total marks do not decide the outcome. Read the mandatory rows first, then the full quotes, then the unresolved items. The result may be one preferred candidate, a revised requirement list or a no-go.
Record the decision as proceed, revise, defer or exit in a log with its evidence, rationale, unresolved issues and approval status. Name who approved it and when the choice will next be reviewed, so a later buyer can see why a candidate was chosen or dropped.
A no-go is a defensible result when the record shows which evidence failed, because it prevents an unsupported live release. The launch validation checklist covers the release gates that follow, and the review methodology keeps the marks consistent between reviewers.
Before you act
- Compare buying with extending the current site or manual process.
- Write the requirements and mark each mandatory or desirable.
- Set the entry gatepublish the page and export lead data.
- Score all candidates on the same rows, with evidence attached.
- Collect written quotes with full licence and renewal terms.
- Run one synthetic lead through every shortlisted candidate.
Common questions
Why are six builders named?
They are starting candidates, not endorsements. Current capabilities and terms must be confirmed directly with each supplier, and any other product that meets the same requirements can be added to the list.
What removes a candidate before scoring?
The entry gate. A candidate that cannot publish the required page and transfer or export captured lead data to the intended destination is not shortlisted.
Does the test page show that conversion improves?
No. It is a workflow test using one synthetic lead. It records expected and observed results for each step, and it is not evidence of better conversion.
