NEXSUM_LABS
  1. Home
  2. Work
  3. A Series A fintech cut landing-page turnaround from three weeks to four days
Book a call

[ Case study ]

FintechWebflowWebflow Data APIHubSpotFigma (source of truth)

A Series A fintech cut landing-page turnaround from three weeks to four days

Every campaign landing page was an engineering ticket. Marketing wrote the copy, waited roughly three weeks for a build slot, then queued changes behind product work — so campaigns shipped late or ran on stale pages.

CLIENT a Series A fintech marketing team — FOCUS Design the component system before any page

Webflow DevelopmentWeb DevelopmentWebflow DevelopmentFintechRepresentative example
Client
a Series A fintech marketing team
Industry
Fintech
Engagement
6 weeks — experience pod — designer + frontend engineer
Service
Web Development / Webflow Development
Headline outcome
Median landing-page turnaround, measured across the first 12 campaign pages post-handover: 3 weeks → 4 days, read from Marketing's project tracker

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Inside a Series A fintech, the marketing team owns every campaign page the company publishes — product launches, compliance explainers, paid-traffic landers. The company sells to banks, so every page passes a compliance review before it ships. Marketing writes copy, brand guards the identity, and a small engineering team builds the site itself. The site had grown through product sprints, and marketing's requests had learned to wait in line behind roadmap work.

What it was costing

Every campaign landing page was an engineering ticket. Marketing wrote the copy, waited roughly three weeks for a build slot, then queued changes behind product work — so campaigns shipped late or ran on stale pages.

What they could see

  • Campaign pages waited roughly three weeks for an engineering build slot, and copy changes queued behind product roadmap work.
  • Some campaigns launched on stale pages because the alternative was missing the launch date entirely.
  • The brand team raised typography and color drift on published pages instead of catching it at assembly.
  • Compliance restarted its review from zero on every page because no two builds were comparable.
  • Marketers had stopped requesting improvements; the tracker showed the same tickets aging for months.

The constraints we worked inside

  • The brand team guarded typography and color strictly; the system had to encode those rules, not trust editors to follow them.
  • Compliance reviewed every page; publish paths needed a review step, not a free-for-all.
  • The existing site stayed live throughout — this was a parallel build, not a rebuild.

What had been tried before

Engineering templated the most common campaign layout and handed marketing the snippet.
Every new campaign still needed a developer to wire forms, review paths, and edge cases; the queue's length didn't change.
Marketing prototyped pages in a general-purpose no-code tool they already used for internal decks.
The brand team rejected the output — no component constraints meant drift — and compliance had no review surface for pages published that way.

What we proposed

We proposed a component system in Webflow: a locked library of brand-governed sections, campaigns modeled as CMS collections, and a publish path with permissions split between marketing, brand, and compliance. The core reasoning: the constraint was never marketing's ability to write pages — it was that every guarantee brand and compliance needed lived in people's heads and engineering's goodwill instead of in the tool. Encoding the rules structurally means a page cannot drift, and cannot ship unreviewed, without someone deliberately breaking the system.

Just as important is what we ruled out, and why:

  • Giving marketing access to the existing React codebaseEvery change would still enter through engineering's queue, which was the original failure; a codebase also gives compliance nothing to review without a developer.
  • Another general-purpose no-code page builderThe team had tried one; without CMS modeling or a permissions model it reproduced the drift and left compliance with no gate.
  • Static HTML campaign pages generated per launchFast for one launch, expensive for the next; every copy change and form tweak would route straight back through engineering.

How the work ran

01Design the component system before any page

We built a Webflow component library with client-first class structure and documented variants, so every future page is assembled from proven parts.

02Model campaigns as CMS collections

Campaign content moved into collections with reference fields, letting marketers create pages by filling fields instead of copying layouts.

03Wire the review path

Forms route to HubSpot, staging links feed compliance review, and publish permissions were split so nobody ships an unreviewed page by accident.

Delivered by the experience pod — designer + frontend engineer over 6 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Webflow
Marketers assemble from locked components instead of filing tickets; the permission model gives compliance a publish gate, which no code-based path offered without engineering labor.
Webflow Data API
A scheduled export on each publish writes a page snapshot to the compliance archive — the durable record reviewers asked for and the platform didn't natively provide.
HubSpot
Campaign forms already reported into HubSpot; wiring new pages to the existing properties meant attribution kept joining cleanly and no new system entered the stack.
Figma (source of truth)
Brand governs type and color there today; mirroring tokens between Figma and the component classes makes drift visible at review instead of after publish.

What went wrong

Obstacle

The first two campaign pages shipped with more edit freedom than the system needed — marketing restyled a locked section, and the brand team flagged it within a day.

Handled: We split Editor and Designer permissions, locked the shared classes, and re-cut the templates so editors touch copy, imagery, and CMS fields only.

Obstacle

Compliance wanted a durable snapshot of every page exactly as published, and the platform's publish model pushes all staged changes at once — no native archive existed.

Handled: A scheduled Data API export on each publish now writes a snapshot to the compliance archive, and the publish button sits behind the staging-review checklist.

How we worked together

Cadence
Monday demo, Wednesday compliance review slot, Friday publish decision — the rhythm matched their campaign calendar, and every demo ran on a staging link reviewers could annotate.
Client side
A growth marketer owned campaign content daily; the brand lead reviewed components; a compliance officer held the publish gate.
Decisions
Design questions settled in the demo; anything touching brand rules went to the brand lead; publishing was compliance's call alone, made on the staging link.
They provided
Brand guidelines and the Figma library, HubSpot property lists, compliance's review checklist, and marketer time for two pilot campaign pages before handover.

What changed

The headline: median landing-page turnaround, measured across the first 12 campaign pages post-handover3 weeks → 4 days, read from Marketing's project tracker. A second check: design-drift defects raised by the brand team since handover at 0.

Campaign pages stopped being a favor engineering owed marketing. Marketers assemble, review, and publish without a ticket, and compliance reviews a link instead of a code diff. The brand team stopped policing pages after publish because drift now fails at assembly time — the locked components make the right thing the easy thing. Launch debates moved from whether a page could be built to what it should say, which is where the team wanted its arguing budget.

The result was read from Marketing's project tracker against the pre-engagement baseline over the stated window, with a guardrail check on design-drift defects raised by the brand team since handover. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

  • The Webflow project with component library, locked classes, and permission model configured.
  • The Data API snapshot job writing compliance archives to their storage bucket.
  • A component reference documenting every editable field and its brand boundaries.
  • HubSpot campaign forms wired to existing properties, with a naming convention doc.
  • Two pilot campaign pages, fully built, as worked examples for the next ten.

What we would do differently

We would have split Editor and Designer permissions on day one — the first two pages shipped with more edit freedom than the system needed.

Web DevelopmentWebflow DevelopmentFintechWebflow

Next case study

An architecture practice took full ownership of its portfolio publishing