Most landing pages describe the product. The pages that work make an argument to the buyer, and the argument comes from research, not templates.
At Up Strategy Lab we start with the customer, before any design work. We run workshops and value proposition sessions to understand the business underneath the request: how the company makes money, who decides, and where the product has to earn trust before anyone buys.
One page, one job
A landing page moves one buyer one step forward. Everything on the page either serves that step or gets cut.
The job depends on who is reading. A funded founder evaluating a dev tool decides differently from a CTO defending a six-figure contract to a board. We match each client to an ICP: funded founder or CTO, growth scale-up, deep-tech, or AI-transformation mid-market. Each one has a different buying journey, so each page argues differently.
Step 1: Decode the business before the brief
We start with workshops and value proposition sessions. The output is the argument the site has to make: the business model, the buyer decision process, and the points where trust is earned before a purchase.
Step 2: Map personas to the product
For each target persona we map the jobs to be done, the pains, and the gains. Then we map those against the client's core product offering and keep what actually fits.
The landing page sells the fit: the moments where the product resolves a real pain for a real buyer.
Step 3: Find the language in search data
Those jobs, pains, and gains get checked against Google Search Console and Google Ads data. We look for the queries people actually type, and the questions they ask their AI agents and chatbots. The words that show up in search and AEO research become the words on the page, because they are the words buyers already use.
Step 4: Write section by section
Each section of the page has one value proposition to satisfy:
- The hero makes one promise in the customer's words.
- The problem section names the pain plainly.
- The solution maps the product to the job to be done.
- Trust items go where doubt is highest: quotes, logos, case studies.
- Lead-driving elements, forms and contacts, sit where intent is strongest.
Step 5: Edit in Google Docs
We write in Google Docs and edit section by section. Every sentence gets challenged: does it earn its place, does it move the buyer forward, is the claim supportable. The copy is scored against the De-AI checklist before it ships.
Step 6: Design graphics for the claims
Sections that benefit from being seen get custom graphics. A process, a comparison, an architecture, a result: if a statement lands faster as an image, we draw it.
Step 7: Build on Webflow or the Web Launch Kit
Two build tracks:
- Webflow, when the client wants to edit on-canvas themselves.
- Next.js + Payload + Supabase + Vercel, the Web Launch Kit, when the client wants to own the stack with no per-seat fees.
Every client gets their own GitHub repo, Vercel project, and Supabase project. Nothing is shared.
Step 8: QA, launch, handover
Before launch: build check, JSON-LD, sitemap, Lighthouse and Core Web Vitals, consent mode and cookie banner, analytics. Then DNS cutover and the old host is cancelled.
After launch the client either takes ownership (GitHub, Vercel and Supabase transfer natively, Resend is rebuilt, credentials rotated, about two hours) or continues on a monthly retainer for content, SEO, and design support.
The pattern is the same for every client: research the buyer, write in their language, prove the claims, ask for the next step, then measure what happens.
