AppSignal is an established APM platform used by thousands of engineering teams that combines error tracking, logs, and uptime in one product. For its 2026 homepage, Evil Martians imagined a bold creative direction, built it with LLMs, and shipped it straight into an A/B test. Early data shows activation up 14% over the previous site.

The shipped AppSignal homepage showing the final design and messaging

The released homepage paired a stronger visual direction with clearer product messaging and a more confident CTA.

What the duck is going on with SaaS website design?

Mike Smith, AppSignal’s CMO, came in with a firm assessment: every SaaS website looks the same, and people are blind to sameness. In a crowded devtools market, where the utility is the same, “more developers chose fashion over functionality”

Vercel is “the Mac of dev tools,” and AppSignal wanted that kind of distinct, fresh-for-2026 identity: the boldness of old Sentry, the retro craft of PlanetScale. They wanted a tone projecting logic with a challenger edge (“80% of Datadog at 20% of the price”), a page showing the product instead of hiding it behind stock art, and never gating value behind a sign-up.

A long-form AppSignal homepage layout showing the scroll narrative and product messaging

The final homepage uses a scroll-driven narrative to guide visitors from the pain point to the product story.

Evil Martians explored fast, in three directions, using code, Figma, and AI together.

Figma carried the product illustration as we iterated the core “signal narrative” roughly a dozen times, the fine detail, and the section-by-section narrative.

Meanwhile, code carried the feel. One concept’s hero has a duck that hides when you try to catch the bug. It lived in code from day one, on a URL we could send. (We even spun up Three.js for a 3D direction and shader tooling for the most experimental concept.)

Three AppSignal homepage concepts shown side by side as design explorations

We explored three homepage directions in parallel, using code, Figma, and AI to compare the feel of each concept.

We landed on a fun concept after the AppSignal team shared their impressions:

I keep coming back to #2. I stop and pay attention, it’s something I’ve not seen before. It’s funny, and the longer you look at the hero the more you see. With #2 it’s instantly clear that AppSignal is gonna help me see what the duck the problem is.

A marketing website is an ever-changing representation of your business. For the sake of efficiency, we like to design in code. In AppSignal’s case, we wanted to see details, as they would ship: error labels flowing along the hero’s tendril, the duck hiding when you chase the bug, feature columns and integration logos revealing detail on hover, and a closing “pile” of disconnected tools resolving into one install.

The chosen direction was prototyped in code so the interaction details could be reviewed before launch.

An opinionated position serves as a self-qualifying lead pipeline

The concept we chose focuses on jobs to be done (JTBD) and real personas. We mapped the real-life scenarios for folks visiting AppSignal’s website:

  • the backend dev with no context to debug a prod issue
  • the on-call engineer at 4 a.m. fighting seven tools to silence PagerDuty
  • the founder staring at a Datadog bill
  • the AI-first builder flying blind
  • the dev whose compliance team wants data in the EU

Each arrives mid-panic, with about ten seconds of patience.

This page loudly qualifies the right buyer, and repels the wrong buyer, also loudly. Every section is a reader question, in their voices. The hero asks “why the f**k did my app crash?” and answers “AppSignal knows why.”

The deep dives are jobs: “what’s going on with my app?”, “what’s the root cause?”, “how do I fix it, or can AI just do it?”

The Fix section shows AppSignal’s MCP (Model Context Protocol) server handing an error to Claude, Cursor writing the patch, and the user reviewing a pull request instead of debugging.

This opinionated design, focused around an ICP, also ties into the hard part of the redesign: making a multi-product platform legible and cohesive.

So, instead of listing the features AppSignal offers (errors, performance and tracing, logs, uptime, host and Kubernetes, cron, dashboards, alerting) we opted for an 1-line positioning: “One install replaces your whole stack at 50% of the cost.” Framed this way, a homepage is a self-qualifying lead tool.

The scroll experience carries the narrative from the problem statement into the product promise.

Martian engineering perfects the AppSignal page

We shipped the design as code in a real repo, almost every part already existed as working code with styles, components, markup, and the interactions themselves. Of course, designing in code doesn’t guarantee the cleanest architecture. Our planning accounted for this, and our Martian engineer cleaned it up and had it release-ready in just three days.

To do this, Evil Martians built a short, project-specific conventions file scoped to the new landing page’s directory. Claude picked it up and with each PR our designer opened, our engineer watched for Claude’s typical mistakes: inline styles where the project had design tokens, SVG markup pasted straight into JSX, raw HTML elements where the codebase had its own wrappers. When she caught one, she fixed it and added a rule to the conventions file in the same PR. From there, the next Claude session picked the file up, and that mistake stopped recurring. Code review got easier with each PR.

Martians iterated together on a shared design system and tokens, shipping edits through pull requests.

Across six weeks of tracked feedback, four people from AppSignal’s team were in the doc with us running relentless experimentation. “5-minute install” became “2-minute install.” “Try it free” became “plans starting at $0, 30-day full trial.” We swapped Papertrail for Grafana so the comparison read true and rewrote every feature column outcome-first. We continuously worked on the website until it was production-ready.

The AppSignal homepage install call to action with a clearer value proposition

The final install CTA was rewritten to make the value proposition obvious in a single glance.

Measurable outcomes

We shipped the website and tested it. Evil Martians set up the homepage A/B experiment in PostHog (the bold treatment against the old site as control) and handed AppSignal a live read.

MetricControl (old)Treatment (bold)Lift
CTA clicks636679+7%
Signups109112+3%
Activated5765+14%
Time on site1317+31%
Scroll-depth1.62+25%

That flat signup number is the interesting part. A bolder homepage didn’t pull a bigger crowd; it pulled a better-qualified audience.

The anti-sell (“you’ll hate AppSignal if…”) and the job-shaped narrative did their job: fewer tire-kickers, more people who connect an app because they already get what it’s for.

Now that the homepage is live, the new design system, built in code from the start, is rolling across the rest of the site: 80+ pages moving to the same visual language, the same components, the same job-first narrative.

An AppSignal anti-sell section that tells visitors when the product is not the right fit

The anti-sell section helped filter out mismatched visitors while reinforcing the product’s positioning.

When to consider designing in code?

What’s the best way to approach validating a new page with this approach?

To start, use Figma where it’s strongest, but get the chosen direction into code early. Once the concept is production-ready, run your bold direction against the old one on live traffic and let activation decide. Realistically, a leaner team can put the working version in front of real traffic before the final polish and let the data say which refinements actually earn their keep.

If you want a homepage bold enough to stand out and disciplined enough to ship and test from day one (and a design system that carries across every page after it) that’s the work Evil Martians does: design that lives in code, tied to the metric that moves your business.

Book a call

Irina Nazarova CEO at Evil Martians

Inherited a vibe-coded prototype or moving a design system into code? Let's render every state, find the slop, and make your UI maintainable.