InsightsTap: Website

The one that's actually live

Everything else on this site is a labelled prototype. This one isn't: it's a real B2B SaaS marketing site, live in production right now, and I designed the interface and wrote the front-end code that ships it. InsightsTap sells 'intent signals' to go-to-market teams (reading anonymous buyer behaviour before a prospect ever fills out a form), which means the entire product lives in concepts nobody can point at. There's no physical object to photograph. The site had to make an invisible product feel as concrete and fast as the e-commerce tools it compares itself to.

insightstap.com

Borrowing a metaphor that already worked

InsightsTap's own pitch leans on one comparison (run your B2B enterprise like an e-commerce store), and I anchored the entire site on it instead of introducing a competing metaphor of my own. Buyers in this category research anonymously and decide fast, so giving them a mental model to borrow in the first five seconds mattered more than being original. Every section after the hero pays that metaphor off rather than switching frames halfway through.

insightstap.com

Calm as the actual competitive move

The incumbents here (6sense, Demandbase, ZoomInfo, Bombora) all compete on density: walls of stats, huge signal-volume numbers, full-stack capability lists. Against that, one calm, high-contrast component system that keeps the heaviest data sections legible isn't just a style choice, it's the differentiator. One vocabulary of cards, bands and diagrams runs through the whole site, so even the densest metrics section costs a returning reader nothing new to learn.

insightstap.com

The decisions a visitor never sees

The parts of this build I am proudest of have no screenshot. The code is InsightsTap's, so none of it is on this page; what it does is mine to describe.

• The hero animation limits itself. The moving field behind the headline is drawn on a canvas, and it caps its own resolution rather than painting eight megapixels on a 4K monitor. If frames start arriving late it permanently lowers its own quality instead of stuttering, it stops completely when it scrolls out of view or the tab goes to the background, and a visitor whose system asks for reduced motion gets a still frame and no loop at all.
• Pages expire; only the hashed files are forever. The framework gives a fully static page a year in the shared cache by default, which is safe only where that cache is emptied on every deploy. This site deploys in place behind a CDN that is not emptied, so a year-old page would keep pointing at script files that no longer exist. Pages carry five minutes and a revalidation instead, and the long life belongs to the content-hashed assets, where it is actually true.
• The forms trust the server, not the browser. Anything the browser reports about a visitor can be edited before it is sent, so the values worth keeping are read on the server, where every submission already passes. One place to get right, and nothing a form can be talked into carrying.
• One validation system, and it can be heard. Every form on the site shares one set of rules and messages: errors appear on submit and again the moment a field has been touched, focus jumps to the first field that is wrong, and each message is tied to its input so a screen reader announces it. A red outline nobody reads out is not an error message.
• The images were converted once, and reversibly. Every raster asset became WebP in a single pass that checked for name collisions first, archived the originals rather than deleting them, and wrote a report I could audit afterwards. The optimiser serves AVIF and responsive sizes on top of that.

Which is what makes the next number annoying rather than surprising. Every rule above is about not spending a visitor's bandwidth, and the hero video breaks all of them.

The number I haven't fixed yet

I'd rather tell you this than let you find it: mobile load time on the live site currently sits around 14 seconds, because the hero video is the largest content element on the page. A poster-first loading fix is queued; I'm choosing to publish the honest number instead of hiding it until it's solved. Everything else is already where it needs to be: layout shift sits at a median 0.00 across five Lighthouse runs, and mobile accessibility scores 95.

const PAGES = [["home", "https://insightstap.com/"]];const RUNS = process.argv.includes("--quick") ? 1 : 5;const MODES = ["mobile", "desktop"];const median = (xs) => {  const s = [...xs].sort((a, b) => a - b);  return s[Math.floor(s.length / 2)];};// … each run shells out to Lighthouse against the live URL and keeps the//   report JSON, then reads the scores and the web vitals out of it.    results[`${name}-${mode}`] = {      perf: median(runs.map((r) => r.perf)),      a11y: median(runs.map((r) => r.a11y)),      bp: median(runs.map((r) => r.bp)),      seo: median(runs.map((r) => r.seo)),      lcp: median(runs.map((r) => r.lcp)),      cls: median(runs.map((r) => r.cls)),      tbt: median(runs.map((r) => r.tbt)),      fcp: median(runs.map((r) => r.fcp)),      runs: RUNS,    };

What building it myself actually meant

Because I designed and built the same site, nothing needed specifying twice: motion, empty states, focus order, and what happens at 320 pixels wide never got lost in a handoff, because there wasn't one. Given more time, I'd push the heaviest data sections further with motion that reveals the cause-and-effect story step by step, and test the current four-step narrative against how real buyers actually scan the page, not how the category assumes they do.

insightstap.com