Egzecute — Insights

Designing a SaaS landing page that still ranks in 2026.

2026-08-02T00:00:00Z

A SaaS landing page in 2026 has to do three things at once: rank in Google for a competitive query, convert a skeptical founder to demo, and not look like the seventeen other SaaS landing pages they opened in the same tab session. Most fail on at least two.

This is a teardown of what we now use as the structural blueprint for every SaaS landing page we ship. It is opinionated. It also works.

The three failures we see most

When we audit existing SaaS landing pages — usually as part of a rebuild engagement — the same three failures show up:

The hero says nothing. "AI-powered platform for modern teams" is the most common opening line on the web. It's also the line Google can't extract entity meaning from.
Social proof comes too late. Logos and testimonials live below three scrolls of feature description, which means the skeptical visitor bounces before seeing the trust signals.
The page is built for a category that doesn't exist yet. Founders position against a future market where their software is essential, but Google ranks against the current market where it's competing with five clearer alternatives.

Every fix below addresses one of those three.

The blueprint, top to bottom

The architecture we now default to — and adjust only when we have a strong reason — has seven sections, in this order:

1. Hero with a verb-led promise

The hero headline is a verb. "Forecast revenue with the precision of a 200-person finance team." Not "AI revenue forecasting." Verb-led hero lines parse for both Google and humans. They tell the reader what the product does and the engine what intent it serves.

2. The dek — what we're for, in italic-serif

Below the hero headline, a single line of editorial weight. We use Instrument Serif italic to set it apart visually. The job of the dek is to qualify the audience and the use case. "For startup founders who refuse to outsource their numbers." This is where you lose 30% of the wrong audience on purpose.

3. A logo strip, immediately

Social proof in the second screen. Not the seventh. Six to eight customer logos, sized small, with no flourish. The job is to communicate "real companies use this." That's it.

4. The single most compelling outcome, with a number

One metric, one customer name. "Wealthora reduced their financial close from 9 days to 2." Numbers in the second-or-third position of a landing page convert at meaningfully higher rates than feature lists. The number anchors the page in reality.

The first screen should answer three questions before the visitor scrolls: what it does, who it's for, who already trusts it. One focal point, not four.

5. Three (not seven) feature blocks

We cap feature sections at three. Each one has:

A two-word feature name
One sentence of what it does
One sentence of why it matters (this is the line most pages skip)
A visual — ideally a product screenshot, not a stock illustration

Seven feature blocks dilute attention. Three force the writer to pick the truly distinct ones.

6. The case-study handoff

After features, not before, we link out to one full case study. Not a logo grid — a single, specific story. The Wealthora-to-Egzecute pattern: name, problem, outcome, link to the detailed write-up. Linking out at this position keeps the bounce rate honest and the time-on-site metrics aligned with intent.

7. The closer — one clear next action

The closer has one CTA. "Book a 20-minute demo." Not three buttons. Not a chatbot. One verb, one promise, one form. Conversion math is simple: the more options at the bottom, the lower the rate.

Pricing is where SaaS pages lose people. One primary action per plan, and one plan carrying the weight of the recommendation.

The technical SEO under it

Design without technical SEO is a billboard in the desert. The structural elements we always add:

Product schema in JSON-LD with name, description, pricing, ratings if applicable
FAQPage schema for the FAQ section, if you have one (you should)
BreadcrumbList schema so Google understands the site hierarchy
Open Graph image at 1200×630, hand-designed (not a generic export). This is the image that shows up in LinkedIn and Slack previews — it's worth 30 minutes of design time.
Title tag formula: [Verb-led promise] — [Brand]. Under 60 characters.
Meta description: the dek, lightly rewritten. Under 160 characters.
alt text on every product screenshot with the feature name and the outcome. Not "screenshot of dashboard" — "Wealthora forecasting dashboard showing 30-day revenue projection."

These don't cost design. They cost an hour of careful writing.

Design without technical SEO is a billboard in the desert. — Internal SaaS playbook

What we cut from the default SaaS template

Things we don't include, despite what the popular SaaS template libraries suggest:

Animated heroes. They look impressive in screenshots, they tank LCP scores in Core Web Vitals, and they don't measurably improve conversion.
Pricing comparison tables on the landing page. They belong on /pricing/. The landing page's job is to get to the demo. Comparison tables get visitors stuck in evaluation mode.
Live chat widgets. They lower trust on B2B SaaS pages. A clear, fast email response is better.
Generic "Get Started Free" CTAs. Specific verbs convert better. "Book a 20-minute demo" or "See your forecast in 5 minutes" outperforms generic CTAs by ~20–40% in our tests.
Customer quotes with stock-style portraits. If the headshot looks like a marketing photo, it reads as fake. Use real photos, candid if possible.

Pre-launch checklist

Before shipping any SaaS landing page, we run the same five tests: (1) Can I describe what this product does in one sentence after reading only the hero? (2) Did I see a customer logo before scrolling? (3) Is there a number anywhere on the page? (4) Is the CTA a specific verb, not "get started"? (5) Does the page score >90 on Lighthouse mobile?

The compounding effect

A SaaS landing page is the rare piece of marketing where the design, the copy, and the technical SEO all compound on the same surface. A great hero line earns both better conversion and better ranking. A clean schema markup earns both a rich snippet and a more confident user. Cutting an animated hero earns both a faster page and a higher Core Web Vitals score.

When all three pull in the same direction, the page outperforms by a margin that doesn't show up on a single metric — it shows up on the next quarter's pipeline.

Why your brand name isn't showing up on Google.

2026-07-21T00:00:00Z

If you have ever searched your own brand name and watched Google ask "did you mean…" followed by a more common word, you are not imagining it. Your brand is failing what search engineers call entity recognition — and unlike most SEO problems, this one cannot be solved with backlinks alone.

Entity SEO is the quiet layer underneath traditional ranking. It is the difference between Google understanding that "Patagonia" is an outdoor clothing brand and a region in South America, or that "Egzecute" is a creative agency and not a misspelling of the verb execute. When your brand fails this test, you do not just lose visibility. You lose the right to be searched as yourself.

This piece is a working playbook. It is the same one we use internally at Egzecute, and the same one we hand to clients whose brand names contain unconventional spellings, invented words, or letters that machines tend to autocorrect away.

What is an entity, really

An entity, in Google's vocabulary, is a thing the search engine can confidently distinguish from other things with similar surface features. A person. A place. A product. A company. Each one carries an identifier — in some systems literally a number — that anchors it across the web.

The shift to entity-based search was formalized when Google launched its Knowledge Graph in 2012. Before that, the engine matched strings: collections of characters. After that, it began matching things: clusters of facts and relationships. The result is the panel that appears on the right side of search results when you query a known brand — logo, founders, headquarters, products, social profiles — all stitched together from sources Google trusts.

An entity is not a single page; it is a network of consistent signals. The more sources agree, the more confidently Google resolves the brand.

Why Google doesn't know yours

If your brand name is short, invented, or uses a substitute letter (think z in place of x, or k in place of c), the search engine has a structural reason to doubt you exist.

Google's spelling-correction system, internally referred to as did-you-mean, is statistical. It compares your query against frequencies in its global corpus. If your brand name appears 12 times across the entire web and the closest dictionary word appears 12 million times, the math is simple. The engine assumes you made a typo, helpfully suggests the dictionary word, and quietly downranks you.

This is not a bug. It is a feature designed for the 99.9% of users who genuinely mistype things. But for emerging brands, it produces a paradox: you cannot rank until you are recognized, and you cannot be recognized until enough authoritative sources agree you exist.

"You cannot backlink your way out of an entity problem. You have to be an entity first — and that is a different kind of work." — Internal note, Egzecute brand strategy team

The on-site signal stack

The signals you control directly are your starting point. They will not, on their own, force entity recognition, but without them every other effort is wasted. Think of these as the documentary evidence Google needs before it can cross-reference your brand to anything else.

1. Organization schema, on every page

Schema.org's Organization markup is the most important hidden text on your site. It is a JSON object placed in the <head> that tells Google, in machine-readable terms, that this site represents a specific named entity. The critical fields are name, alternateName, url, logo, and — the one most brands skip — sameAs:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Egzecute",
  "alternateName": "Egzecute Agency",
  "url": "https://egzecute.com",
  "logo": "https://egzecute.com/logos/egzecute-logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/egzecute",
    "https://www.instagram.com/egzecute/",
    "https://medium.com/@egzecute"
  ]
}

The sameAs array is how you teach Google that the LinkedIn page, the Instagram account, and the Medium profile all describe the same entity as the website. This is the move that consolidates your scattered web presence into a single, defensible identity.

2. Consistent title-tag formula

Every page on the site should end with the brand name, separated by a pipe or em-dash. This is repetition for the index, not the user. Over thousands of crawled pages, Google sees the brand name appear in the most weighted position on every document, in a consistent format. That repetition is what builds the association in the first place.

3. Branded internal anchors

When you link from one part of your site to another, the anchor text should sometimes contain the brand name itself, in natural prose. Not "click here." Not "learn more." A short clause like "the team at Egzecute also publishes…" teaches Google that the brand and the site are the same entity, in language the engine can parse.

Practical tip

Audit your last fifty pages. Count how many times the brand name appears in body copy, naturally. If the answer is fewer than ten, you are leaving entity-building on the table. Fix it.

Off-site work is mostly repetition: the same name, the same description, the same address, everywhere a machine might read them.

The off-site signal stack

On-site work is necessary but not sufficient. Google validates entities by looking for consistency across sources it already trusts. This is where most brand entity strategies stall, because the work is unglamorous and the timeline is long.

Google Business Profile, fully verified, with the brand name spelled exactly as it appears everywhere else. This is the single highest-leverage off-site action. It often eliminates the spell-correction prompt within weeks.
Wikidata entry, submitted directly. Wikidata is the structured backbone Google reads to validate entity claims. An entry there — with citations — is treated as a primary source.
Consistent NAP (Name, Address, Phone) across LinkedIn, Crunchbase, Clutch, G2, and any industry directory relevant to your category. Inconsistency here is the most common reason entity validation fails.
Branded mentions in published content — press, podcasts, guest articles — where the brand name is spelled correctly and surrounded by topical context. Volume matters less than authority and consistency.

A realistic timeline

Brand entity work pays back slowly. The standard playbook unfolds across roughly six months, and most teams give up at month three because there is no immediate ranking pop. Here is what actually happens, week by week, when the work is done correctly.

Weeks 1–2: Schema deployed sitewide. Title tags audited. Google Business Profile claimed and verified.
Weeks 3–6: Wikidata entry approved. Initial press mentions begin to accumulate. Branded internal-link audit complete.
Weeks 7–12: Spell-correction prompt begins to disappear for branded queries. Knowledge Panel starts to assemble.
Months 4–6: Knowledge Panel solidifies. Brand-only search shows clean results. Competitive queries begin to attribute brand correctly.

None of these milestones is dramatic on its own. The cumulative effect, however, is that your brand stops being treated as a typo and starts being treated as itself. That is the entire point.

The Egzecute case

We will not pretend this is theoretical for us. Egzecute contains a z where most readers expect an x. Every cold search for our brand, in the early days, returned Google's polite suggestion to look up execute instead.

The fix took roughly four months and followed the playbook above almost exactly. The single most effective action was the sameAs array in our Organization schema, paired with a Wikidata entry that cited our agency profile and three published interviews. Within ninety days the spell-correction prompt vanished. Within six months a Knowledge Panel began to render for the brand query.

If you are reading this and recognize the problem, the work is straightforward. It is just slow, and most teams confuse slow for ineffective. They are not the same thing. Entity recognition is a compounding asset; once it lands, every other piece of marketing you do gets credited to the right brand.

Logo design is mostly editing.

2026-07-14T00:00:00Z

Every logo we have ever delivered went through the same process: a wide ideation phase, then a much longer phase of removing things. The wide phase is the part juniors love. The removing phase is the part that decides whether the logo will survive its first year.

Most logo critique is framed as taste — "this curve feels off," "the proportions are wrong." But underneath those judgments is almost always a structural failure: the designer added one thing too many and could not let it go.

This is a short essay on the part of logo design no one teaches: editing.

The ideation trap

Design schools teach divergence first. Generate 50 concepts. Then 100. The thinking is that volume reveals quality. It often does — but only if the next phase is just as ruthless as the first.

What usually happens instead is that one of the 50 concepts gets chosen, and then the designer tries to make that concept work by adding. A subtle gradient. A second weight of the wordmark for "balance." A graphic mark to clarify the metaphor.

The added elements always look like they belong, because the designer who chose them is the same designer building the proportions around them. But the logo gets weaker with every addition. A logo's job is to be recognizable at a glance. Every extra element is a glance the viewer has to spend.

The wide phase. Everything here is a candidate, and almost none of it survives — which is precisely the point of going wide.

What we cut from every logo

When we audit our own in-progress work, we ask one question of every visual element: what is this doing that nothing else in the mark is doing? If the answer is "balance" or "feeling" or "completeness," we cut it.

The things we cut most often:

Internal flourishes inside letterforms. A subtle notch, a curved tail, a stylized stem. They look clever at 800px and disappear at 32px.
Secondary marks paired with the wordmark. A graphic mark next to a wordmark forces the viewer to do two reads. Pick one.
Color gradients. Almost always a sign that the underlying form isn't strong enough to hold attention alone.
Stylized punctuation. A custom period, a unique apostrophe. Looks bespoke. Reads as fussy.
Decorative containers. A circle, a tag-shape, a frame. Frames are confessions that the mark inside cannot stand on its own.

This list isn't a rule book. There are great logos that do every one of these things. But the burden of proof is on inclusion, not exclusion.

A logo's job is to be recognizable at a glance. Every extra element is a glance the viewer has to spend. — Egzecute brand team

The "explain the cut" exercise

When a junior designer pushes back on removing an element, we use one exercise: explain in one sentence what the mark loses if this element is removed. If the sentence contains the word "feeling," "balance," or "presence," the element is decoration, not function, and it goes.

The exercises that pass this test are surprisingly narrow:

"Without this, the wordmark and the symbol read as two separate things instead of one." (Functional — keep it.)
"Without this, the mark is illegible below 24px." (Functional — keep it.)
"Without this, the brand looks less premium." (Decoration — cut it.)

The first two cuts solve specific viewing problems. The third is a designer protecting their own taste from the discipline of the brief.

When to stop editing

Editing has its own failure mode: cutting until the mark is too spare to function as a brand. A pure geometric square is editable to the maximum. It is also not a logo, because it cannot belong to a single owner.

A logo is finished when removing one more element would damage recognition. Not aesthetics. Recognition. The test is: shrink the logo to 24×24, fade it to 50% opacity, and see if you'd still recognize the brand. If yes, you've found the floor.

Where that floor sits is different for every brand, and it is set by distinctiveness rather than by complexity. A mark built on an unusual letterform can survive being cut to almost nothing. A mark built on a common shape — a circle, a chevron, a generic swoosh — hits its floor early, because what's left belongs to everyone.

This is why the editing phase has to run after the ideation phase and not during it. You cannot tell which elements are load-bearing until you can see the whole structure.

The same process after the editing phase. Less clever on a presentation slide, and considerably harder-working everywhere else.

A short defense of the boring-looking logo

The logos that end up on this floor often look boring to designers. They have one idea. They use one weight. They occupy one shape.

That boredom is feature, not bug. The viewer is not looking at the logo to be entertained. They are looking at it to confirm "this is the brand I expect." Boring, in that frame, is a synonym for legible.

The brands that age best — Patagonia, FedEx, Apple under Rob Janoff, Pentagram's Saks — are all logos that survive the editing test. None of them look like they were added to over the years. They were cut into existence.

If you are working on a logo right now and it feels almost-but-not-quite-done, the answer is probably not another flourish. It is one more cut.

Why we charge by outcome, not by hour.

2026-07-07T00:00:00Z

If you have ever paid an agency by the hour, you already know the problem. The longer the project takes, the more you pay. The faster they get, the less you pay them for the same outcome. Hourly billing is a structural disagreement between you and the people doing your work.

We used to bill hourly. Then we stopped, deliberately, after a project where we delivered the same design system in half the time we had quoted — and felt punished for it. This is the essay that argues the switch.

The hourly billing trap

Hourly billing has a quiet assumption: that time spent is a proxy for value delivered. Sometimes it is. Often it isn't.

The agency that takes 80 hours to make a logo and the one that takes 12 are doing different jobs. The first is probably learning your category on your dollar. The second has done this work a hundred times and has the muscle memory to skip the dead ends. Charging both at the same hourly rate rewards the slower one.

Worse: hourly creates a perverse incentive to appear busy. Every freelancer and agency has felt the pull, even subconsciously, to do another round of refinement when the work is already done. Not because the work needs it — because the timesheet does.

What "outcome" actually means

When we say outcome pricing, we don't mean "fixed bid." Fixed-bid contracts have the opposite problem: they reward speed at the cost of quality, because every hour saved is margin earned. The agency rushes, the client gets a watered-down result.

Outcome pricing is structurally different:

The deliverable is defined, in concrete terms — not "a website" but "a 14-page marketing site with the architecture in the appendix, including X, Y, Z components, with these performance benchmarks."
The price is fixed, but tied to that specific outcome, not to hours.
Scope changes have a clear conversion path — adding a page or a feature has a price, agreed in writing, before work starts.

The agency makes money by being good at the work. The client gets predictable cost. Neither party is rooting against the other.

Scope written as deliverables. Both sides can point at the same object and agree whether it exists yet.

How we structure it

For every engagement, we now write what we call an outcome brief before any contract. It contains four things:

What the work will accomplish — in business terms, not deliverable terms. ("Launch positioning for an enterprise audience" rather than "10 pages of marketing site.")
What the deliverables are — in concrete terms. Page counts, component counts, content modules, design system depth.
What is explicitly out of scope — the most important section. Most disputes happen at the boundary.
The price, and what happens if scope changes — usually a flat fee for the defined outcome, plus a per-component rate for additions agreed in writing.

The brief is signed before any design work starts. It is the contract.

The agency makes money by being good at the work. The client gets predictable cost. Neither party is rooting against the other. — Internal note on pricing philosophy

When hourly still makes sense (rarely)

There are two cases where we still bill hourly:

Genuine exploration phases. When the work itself is "figure out what this thing should be" — typically a one-week research-and-positioning sprint — there are no defined deliverables to price against. Hourly is honest here.
Ongoing support after launch. A flat retainer for "design help as needed" is hard to bound in advance. Hourly with a monthly cap works.

Both are exceptions, and we name them as such in the contract. An agency that can't tell you which parts of its own model are exceptions is describing a preference, not a pricing structure.

If the price only makes sense when the work goes slowly, it was never a price. It was a meter. — Internal note on pricing philosophy

What this means for clients

The most common pushback we get is: "How do I know the price is fair without seeing the hours?"

The answer is that you don't, exactly — but you also don't with hourly. An agency that bills 80 hours can pad to 100. With outcome pricing, the price is the price. You decide whether that price is fair before signing, by comparing it to the value of the outcome and to other agencies' quotes for the same scope.

The harder question is: what if the agency over- or under-delivers? Over-delivering is the agency's problem (more profit if efficient, less if not). Under-delivering is what the outcome brief exists to prevent. If the deliverable doesn't match the brief, it isn't done, and we don't invoice until it is.

For founders evaluating agencies

Ask any agency you're considering: "If you finish in half the time you estimated, do I pay less?" If yes, they're billing by the hour. If no, they're billing by the outcome. Neither answer is wrong — but knowing which one you're getting is the difference between a transparent engagement and a billing surprise.

The quiet effect of outcome pricing: both parties end up reading from the same page, because neither profits from the project taking longer.

The cultural side

The deeper reason we switched is not financial. It's that hourly billing makes every conversation transactional. Every email, every call, every revision becomes a line item.

Outcome pricing lets us say yes to a small tweak without invoicing for it. It lets the project end when the work is done, not when the budget is. It restores the agency-client relationship to what it should be: two parties solving the same problem from different sides of a desk.

If you're shopping for a creative partner this year and one of them is still billing by the hour, that's the most important data point you'll get from the proposal.

The 1-day brand audit checklist.

2026-06-23T00:00:00Z

Most agencies will sell you a brand refresh before they sell you a brand audit. That gets the order of operations wrong. A logo redesign without a diagnostic is cosmetic surgery on a structural problem.

This is the diagnostic we run for every new client, before any visual work. It takes one day to complete and surfaces the questions that should drive the entire engagement.

Why an audit isn't a logo refresh

A brand has four layers: strategy (who we are for, what we promise, what we won't do), identity (how we look and sound), experience (what it feels like to interact with us), and operations (how consistently we deliver). A logo refresh only touches identity. A brand audit examines all four — and most of the problems live in strategy and operations, not identity.

The pattern we see most often: a founder thinks the brand needs a new logo. The actual problem is that nobody on the team can answer "who is this for?" the same way twice. No new logo will fix that.

What a brand looks like when the answers are already clear: the same decisions holding across every surface, without anyone re-deciding them.

The 12 questions

Ask each question to three different people inside the company — ideally the founder, someone on sales, and someone on product. If the answers don't roughly converge, that's the audit finding. Misalignment between roles is the brand problem.

Strategic alignment (4 questions)

1. Who is this product for, specifically? Not "businesses" or "startups." A real persona with a real job title, an industry, and a stage. If three people inside the company name three different ideal customers, your positioning is unowned and your marketing is fighting itself.

2. What do we promise the customer that no one else credibly does? Not features. Promises. "We deliver in 30 days, end-to-end." "We never bill more than our quoted price." If the answer is "high quality" or "great service," the brand has no claim to differentiation.

3. What kinds of work do we explicitly refuse? A brand without "no" is a brand without identity. The companies you decline to take on define you as much as the ones you accept. If your team can't name three categories of work you refuse, the brand will say yes to its own dilution.

4. What do we want a customer to feel the moment they finish their first interaction with us? Trust? Relief? Inspired? Exhausted? The desired feeling is the experiential goal of the brand. Without naming it, every team makes their own version of it, and they conflict.

Visual coherence (4 questions)

5. Is the logo legible at 24×24 pixels? At app-icon size. If you can't recognize it instantly, the mark has too much information for the medium. (See Logo design is mostly editing.)

6. Do all customer-facing surfaces use the same typography system? Website, decks, contracts, email signatures, invoices. If sales decks use one font and the website uses another, the brand fragments at the point of decision.

7. Is there a single, named, accessible primary color? Not "kind of orange." A hex code. With contrast ratios documented. With usage rules written down. Brands die from color drift more than any other identity decay.

8. Are images and photography directed, or sourced? Stock photography is fine for placeholders and bad for brand. If 80% of your customer-facing imagery is stock, your brand has no visual voice — it's wearing someone else's clothes.

Operational consistency (4 questions)

9. Does the brand voice survive translation between channels? Read three tweets, the most recent email newsletter, and the latest press release out loud, back to back. If they sound like different companies, the voice isn't documented or trained.

10. Can a new hire produce on-brand work without showing it to the founder? This is the operational test of the brand. If every piece of public-facing work needs founder approval to be "right," the brand exists only in the founder's head and will not scale.

11. Is there a written brand document, and was it updated in the last 18 months? Brand documents go stale. A document written for a 5-person team becomes wrong for a 30-person team. If the doc exists but hasn't been touched in 2 years, it's a museum piece, not a working tool.

12. Where does the brand break first under stress? When the team is busy, what gets dropped? Tone? Visual consistency? Sales-deck quality? The answer reveals the brand's structural weakness — and that's exactly where the audit's recommendations should focus.

A brand without "no" is a brand without identity. — Internal audit principle

What to do with the answers

After you've asked all twelve to three people, you'll have a matrix. The questions where all three answers align represent brand strength — areas where the brand is genuinely coherent. The questions where answers diverge represent brand drift — and they are where the actual work is.

We score the matrix simply:

Green — all three answers say roughly the same thing
Yellow — two of three converge, one is off
Red — three different answers

Any red item from the strategic-alignment section is a priority-one fix. Strategic ambiguity propagates downward into everything else.

Who to ask

Ask the same twelve questions of three people who never talk to each other: the founder, someone in sales, and someone in product or delivery. Asking a leadership team together produces one rehearsed answer and tells you nothing. The divergence between three separate answers is the finding.

Audit time-boxing

Run all twelve questions in a single 4–6 hour workshop with the founder, sales, and product reps in the same room. Do not let the conversation expand into solutions. The job of the audit is to find the problem, not solve it. Solutions come in week two.

Most audits surface the same finding — the brand has never said no to anything, so it now means nothing in particular.

What the audit usually surfaces

After running this on dozens of brands, the pattern is consistent: the most damaging issues are almost always in questions 1, 3, and 10. The "who is this for" question and the "what do we refuse" question are the two that founders most want to dodge — because answering them clearly is a commitment they haven't made yet. And the "can someone else produce on-brand work" question is the operational version of the same problem.

You can buy a beautiful logo and still fail at all three. That's why we audit first.

Editorial typography on the web is mostly a confidence problem.

2026-06-16T00:00:00Z

The reason most agency blogs look polished but read poorly is not a typography problem. It is a confidence problem. Designers under brief pressure hedge — and hedging on typography always produces the same blurry-but-busy result.

This essay is the argument for committing harder.

The hedging instinct

When a designer is uncertain about how a blog post will be received, the typographic instinct is to be safe. Pick a comfortable sans-serif. Set the body at 16px. Use medium line-length. Add one quirky element somewhere to feel "designed." Move on.

The result is the typography of every tech-adjacent blog from the past decade. Inter, 16px, 580px line width, one weirdly-tracked all-caps eyebrow per section. The author of the post might have something genuinely sharp to say, but the typography is doing the opposite of that — it's saying "we're neutral, we're safe, please don't judge us by how this looks."

The fix isn't more flourish. It's commitment.

The three rules I keep coming back to

After years of designing editorial pages, three principles consistently produce results.

1. Line length: longer than designers want, shorter than developers want

The standard advice is 50–75 characters per line. In practice, on a desktop screen at body size, 65–75 reads more naturally for longform than the conservative 50.

The hedge most designers make is to set 540–580px reading width. That's safe at every screen size but slightly too short for the body type. A line that breaks every three or four words mid-thought feels twitchy to read. Push the column to 640–720px and the reading rhythm becomes paragraph-paced, which is what longform is supposed to feel like.

2. Leading: looser than feels right

The web's default line-height: 1.5 is the wrong number for editorial body type. Set body lines at 1.6–1.75 and the page exhales. Headings can sit tight (1.1–1.2) by contrast.

The reason designers hedge here is that loose leading looks "loose" in mockups at zoomed-out scale. At reading scale on a real screen, it's correct. Trust the reading test, not the zoom test.

3. Contrast: serif italic against geometric sans

Two typefaces, one rule: one is the workhorse, one is the accent. We use Bricolage Grotesque (geometric sans, variable weight) for everything structural — headings, body, captions, UI labels. Instrument Serif italic is the accent — used only for emphasis, deks, pull quotes, and the occasional word inside a heading.

The trap is using the serif as a second body face. That dilutes the contrast. The italic-serif accent works precisely because it's rare and emotionally distinct from the surrounding sans.

Trust the reading test, not the zoom test. — Workshop note

A long measure with generous leading. It looks too wide in a design file and reads correctly on a screen — which is the only test that matters.

The italic-serif move

The single design choice we most consistently use on editorial pages is one italic-serif word inside a sans-serif heading.

Field notes.

Get our thinking, before it's a project.

Related reading.

The pairing does three things at once. It signals editorial intent (this is writing, not marketing). It creates rhythm within a heading that would otherwise be one weight at one tracking. And it's repeatable — once a system uses this move, it can be reused on every page as an identifier.

The mistake designers make is using too many italic-serif words. The accent works because it's surgical. One word per heading, not two. A few headings per page that use it, not every heading.

Pairing rules: when to break them

The conventional wisdom on type pairing is "one serif + one sans." That's a heuristic, not a law. A more useful frame is emotional distinct + structurally compatible.

Bricolage Grotesque + Instrument Serif italic — our default. Geometric sans with a humanist italic serif. Emotionally distinct, structurally aligned at the x-height.
Inter + IBM Plex Mono — works for technical writing. The mono accent feels like a code annotation, which is the right voice for engineering posts.
Söhne + Söhne Mono — works if you want a unified voice with one acknowledgment of code/data.

What doesn't work, no matter how much it appears in templates: two display sans-serifs with different vibes. Inter for body + Anton for headings. The structural mismatch is visible and the page feels like a Frankenstein.

Practical test

If you can't describe the emotional difference between your two typefaces in one sentence, you don't have a pairing — you have a clash. "One is workhorse, one is editorial accent." "One is technical, one is humanist." If the sentence is fuzzy, the pairing is fuzzy.

The third typeface temptation

Around the third week of working on a brand, designers feel a pull to add a third typeface. Usually it's for "tags" or "captions" or "metadata" — a small uppercase tracked sans. It feels like the move that ties everything together.

It is almost always the move that breaks coherence. Captions can use the workhorse sans at a smaller size with letter-spacing applied. Metadata can use the same. The third typeface adds visual noise and adds nothing structurally.

A third typeface is usually a size problem wearing a costume. — Egzecute design team

The exception: code blocks need a monospaced face, and that's not really a "third typeface" — it's a specialized type for a specialized content type. JetBrains Mono, IBM Plex Mono, SF Mono. Pick one. Reuse everywhere code appears.

Two faces, one idea. One carries emphasis and voice; the other carries everything else. A third would have to earn its place, and usually can't.

What this looks like in practice

The current blog you're reading is built with exactly this system. Bricolage Grotesque for everything. Instrument Serif italic for emphasis. JetBrains Mono for code. No third sans. No fallback decorative face. The same three typefaces across every post, every list page, every UI element.

The decisions feel restrictive when you start. They feel obvious six months in. By the time the system has produced three hundred pages, the consistency is the brand. Visitors recognize an Egzecute page in the first scroll because the typography has been the same since post one.

That recognition is what design commitment buys. Hedging gets you templates. Committing gets you a brand.

The quiet death of keyword-first SEO and what comes after.

2026-06-09T00:00:00Z

The keyword-density era of SEO is over. It has been over for a while, but the playbook lingers because it's measurable and easy to sell. What replaced it is harder to measure, harder to sell, and — for the brands willing to do it — far more durable.

This is the short version of what we now tell every client whose SEO strategy still revolves around finding "the right keyword."

The old playbook (and why it stopped working)

For roughly a decade, the SEO consensus was:

Find a keyword with high search volume and "reasonable" competition.
Write a 2,000-word article structured around that keyword.
Use the keyword in the title, the H1, the first paragraph, four times in the body, and the meta description.
Get backlinks.
Rank.

This worked. It also produced a generation of articles that read like compliance documents — a string of keyword variations stitched together by transitional phrases. Google noticed. The Helpful Content updates of 2022 onward, the spam updates of 2023–2025, the entity-recognition push, and the increasingly aggressive deindexing of "thin" content have collectively retired the playbook.

Pages that still follow it can rank, briefly. Then they fall, all at once, in a Google core update. The owners attribute the drop to bad luck. It isn't.

Entity coherence is not an SEO deliverable. It is what a brand looks like when every surface agrees about what it is.

What Google actually scores now

The current ranking system, simplified, weighs four things:

1. Entity recognition

Does Google understand what you are? A site about brand strategy needs Google to recognize "brand strategy," "Egzecute," "agency," and a dozen other relevant entities as a coherent cluster. Keyword usage is the symptom of being a real entity; entity coherence is the cause. (See Why your brand name isn't showing up on Google for the brand side of this.)

2. Topical authority

How much related content do you have? A single article on "SEO for SaaS" ranks far better when the site has fifty pages around the same cluster than when it stands alone. Google's reasoning: a site that has written exhaustively about a topic is more likely to be a useful answer than a site with one article and a content gap behind it.

3. Useful-content signals (the E-E-A-T model)

E-E-A-T stands for Experience, Expertise, Authoritativeness, Trustworthiness. The model is squishy as a checklist but sharp as a frame: does the content read like it was written by someone with real experience in the topic, or by someone summarizing other articles? The signals Google uses to estimate this are partly explicit (author bios, citations, organizational backing) and partly inferred from the content itself (specificity, opinion, named examples).

4. User-behavior signals

Time on page. Pogo-sticking. Click-through rate from the search results. Repeat visits. These signals are noisy at the individual level, statistically loud at scale. A page that ranks but bounces does not stay ranked.

Keyword usage is the symptom of being a real entity. Entity coherence is the cause. — Egzecute SEO note

The new rituals (E-E-A-T, but practical)

The E-E-A-T model is useless as a checklist and useful as a question. Three questions we now ask before publishing anything:

Did a real person with experience write this? Not "research" or "synthesis." Experience. A post about SaaS landing pages should reference real launches the author has worked on. A post about brand entity SEO should reference a real brand the team has fixed. If the author can't put their name on a specific example, the piece isn't ready.

Does the post argue something, or just describe something? Descriptive posts ("What is brand audit?") don't compound authority. Argumentative posts ("Why brand audits should precede logo refreshes") do. The opinion is what separates your piece from the 200 other articles that summarized the same topic.

Would a competitor reading this learn something? This is the harshest test, and it's the one that most reliably predicts long-term ranking. Pages that have something competitors don't have rank because Google has fewer alternatives to surface.

What to do with your old SEO playbook

If your existing SEO strategy is still keyword-density-led, the move is to consolidate rather than continue. The pattern that works:

Audit existing content. Identify the 20% of pages that get 80% of traffic. Those are your authority-cluster pages — keep them, update them, deepen them.
Merge or deindex the bottom 50% of pages. Thin pages drag down site-wide signals. A site of 200 mediocre pages ranks worse than a site of 80 strong pages.
Build clusters around the top pages. For every authority page, write 3–5 supporting pieces that link inward to it. Topical authority is internal link density as much as it is external.
Add author bios and Organization schema. Real people, real organization, sameAs links to social profiles. This is the E-E-A-T plumbing that confirms the site is a real entity.

One page, one job. The page that tries to rank for nine adjacent queries now ranks for none of them.

Three things to stop doing tomorrow

Even before the consolidation work, three changes that move the needle immediately:

Stop writing 2,000-word posts for the sake of word count. Length should match the depth of the argument. A sharp 600-word post outranks a padded 2,000-word post at the same intent.
Stop using keyword-research tools as content briefs. A keyword tool tells you what people search for. It doesn't tell you what they want to read. The two diverge significantly for any non-trivial topic.
Stop optimizing for the meta description as a ranking signal. It hasn't been one in years. It still matters for click-through rate (which is a ranking signal indirectly), so write it well — but stop stuffing it with keywords.

Taken together, the shift is less a new playbook than a straight substitution. Most of the old tactics have a direct replacement, and the replacement is almost always slower to execute and harder to fake:

Retire this	Replace it with	Why the swap works
Keyword density targets	One page, one job	Google resolves meaning from the whole page, not from repetition
Exact-match page-per-variant	A single canonical page per topic	Nine thin pages compete with each other; one good page doesn't
Anonymous "content team" bylines	A named author with real credentials	Experience is a scored signal, and it needs someone to attach to
Backlinks as the primary metric	Consistent entity signals everywhere	Links help a page; entity coherence helps the whole brand
Publishing to a keyword calendar	Publishing what you actually know	The former is detectable; the latter is the only durable moat

If you do one thing off this table, make it the last row on the on-site side: add Organization JSON-LD with full sameAs social URLs to every page. It costs an hour, signals entity coherence immediately, and works invisibly under everything else.

The new playbook, in one sentence

Build a small site full of strongly-opinionated, experience-backed, internally-linked, schema-marked pages — and let Google's entity engine do the rest.

It is slower than the keyword playbook. It is also the only playbook that survives the next core update.

How to brief a designer when you don't know what you want.

2026-06-02T00:00:00Z

The most common reason a design project goes sideways isn't the designer. It's the brief. And the most common problem with a brief isn't that it's wrong — it's that it's vague in the places it needs to be specific, and specific in the places it should be open.

This is the checklist we wish every client filled in before we wrote a proposal.

The biggest brief mistake

Most briefs lead with aspiration: "We want a website that feels premium and converts well." Aspirational language sounds confident but communicates almost nothing. "Premium" can mean five different visual languages. "Converts well" can mean any of a dozen different metrics. A designer reading this brief has to guess — and the gap between their guess and your unspoken assumption is where every revision round comes from.

A good brief replaces aspirational language with specific constraints.

The 5 things every brief must contain

We use the same five-section template for every project, regardless of size. If a brief is missing any of these, we ask the client to fill them in before we estimate.

1. The business problem in one sentence

Not the design solution. The problem. "We get 3,000 visitors a month but only 12 demos, and our hypothesis is that the homepage doesn't qualify the audience clearly." This sentence tells the designer what success looks like — measured, not vibed.

If you can't write the business problem in one sentence, the project isn't ready to start. The discovery phase exists exactly to answer this.

2. Who the work is for, specifically

Not "potential customers." A person, role, and context. "CFOs at Series B startups, evaluating financial-modeling tools, usually while drafting their board deck." The more specific the audience, the more confidently the designer can make decisions that would otherwise need approval.

3. What success looks like, measurably

Numbers. Not "more conversions" but "demo bookings up 30% within 60 days of launch." Not "stronger brand" but "the brand audit shows green on questions 1, 3, and 10 within six months." (See The 1-day brand audit checklist for what those questions are.)

If the goal can't be measured, it can't be designed for — it can only be designed around.

4. Constraints, not preferences

This is the section most briefs get wrong. They list preferences ("we like clean designs") instead of constraints ("the page must work in IE11 / must be mobile-first / must launch by April 15").

Preferences feel helpful and aren't. They constrain the designer's options without constraining the problem. Constraints — real ones — are how the brief disambiguates. "Must work without JavaScript" is a constraint. "We like minimal designs" is a preference dressed up as one.

5. References, properly framed

Three reference examples, each annotated with one sentence on what specifically you like about it. Not "this whole site is great" — "the way they handle the case-study transitions is exactly the rhythm we want."

A reference without annotation is noise. A reference with one specific note is gold.

Preferences feel helpful and aren't. Constraints are how the brief disambiguates. — Egzecute project lead

The useful brief annotates. 'This one, because the density works for our data' beats a folder of twenty screenshots with no commentary.

Reference images: how to use them properly

The mistake most founders make with references is using them as visual targets. "Make ours look like this Stripe page" leads to a watered-down copy of Stripe.

The right use of references is vocabulary. You and the designer don't share enough visual vocabulary to discuss subtleties. References give you a shared one. "I like this kind of editorial weight" is harder to say than "I like the typography on the Vercel blog." The reference is the dictionary, not the destination.

A useful trick: bring at least one reference that is outside your industry. If you're a SaaS company, include a reference from an editorial site or a fashion brand. Cross-industry references are how original work happens — same-industry references produce category-average work.

A simple brief template

Here is the template we hand to clients, in full:

PROJECT
  [One sentence on what we're shipping]

BUSINESS PROBLEM
  [One sentence on the problem this work solves]

AUDIENCE
  [Role, stage, context — specific]

SUCCESS METRIC
  [Measurable target, with timeframe]

HARD CONSTRAINTS
  [Must-haves and must-not-haves. Real ones.]

REFERENCES
  1. [URL] — what specifically I like: [one line]
  2. [URL] — what specifically I like: [one line]
  3. [URL] — what specifically I like: [one line]

NOT IN SCOPE
  [What this project explicitly will not address]

DECISION-MAKERS
  [Who has approval authority. Capped at 2 people.]

That last section is the one most clients underrate. Projects where more than two people have approval power take three times as long and produce work no one is happy with. Name the deciders before work starts.

There is one honest exception to all of this. If you cannot fill in the business problem or the success metric — not "haven't yet," but genuinely cannot — then the brief is not the thing that's missing.

If you can't name the problem, you're not ready to commission the solution. Positioning first, design second. — Egzecute discovery note

We sell discovery as a one-week sprint precisely because so many projects skip it and then pay for it in rounds four and five, at design rates.

What a good brief buys you: the first round lands close enough that the conversation is about refinement rather than direction.

What the brief is for

A brief is not a contract. It is a conversation starter that ensures both parties walk into the kickoff with the same set of expectations. The best briefs are short — one to two pages — and specific where it matters.

Spend an afternoon writing a real one. The hours you invest in the brief are the same hours you would otherwise spend in revision rounds, just paid up front, at the cheap end of the project lifecycle.

Webflow vs Framer vs hand-coded: when to pick what.

2026-05-26T00:00:00Z

This question comes up in roughly half our discovery calls. It used to have a clean answer. In 2026 it doesn't — the tools have all matured in different directions, and the decision is now genuinely contextual. This essay is the framework we use to decide, project by project.

We ship in all three. We're not loyal to any. What follows is honest, not promotional.

The decision framework, in one paragraph

The choice depends on three variables: how much custom interaction the design needs, who will maintain the site after launch, and how much content will be added over time. Each tool optimizes for a different combination of those three. Pick the one whose optimum matches your project.

The rest of this post unpacks that paragraph.

Webflow: when it wins

Webflow is the best in this class when you have:

A marketing site with moderate-to-rich design (custom layouts, hover interactions, scroll animations)
A team that includes at least one non-developer who needs to update content
A roadmap that involves adding pages and blog posts over time
A budget that allows for Webflow's CMS hosting (~$300–400/year for the Business plan)

Webflow's strength is the gap between "design fidelity" and "content editor accessibility." A marketer can update a case study without breaking the page. A designer can add custom interactions without writing CSS. The CMS is genuinely usable.

Where Webflow is painful

It struggles when:

You need real backend logic (auth, complex forms, data processing). Webflow's "Logic" feature exists but is brittle for anything non-trivial.
The site needs to scale past ~1,000 CMS items per collection. Performance degrades, build times grow.
You want full source control with proper git workflows. Webflow's export is fine but it's a snapshot, not a sync.
The site needs to integrate deeply with a third-party stack (a custom API, an internal data source). Webflow's integrations are mid-tier.

The Webflow ceiling is real. Hit it and you're rebuilding.

The case for the fastest tool: it needed to ship in days and change weekly. Nothing about that argues for a build pipeline.

Framer: when it wins

Framer is the best when you have:

A landing page or early-stage marketing site where you want exceptional animation and motion design
A team where the designer is the developer (or close to it)
A timeline measured in days, not weeks
Less complex CMS needs

Framer's strength is the gap between "Figma fidelity" and "shipped page." The visual layer translates almost 1:1 from Figma. Animations are first-class. The new Framer of 2025–2026 is genuinely close to a "code-output-equivalent" tool for visual work.

Where Framer is painful

It struggles when:

The site has more than ~30 unique page types or deep content hierarchies
You need traditional SEO controls at the depth Webflow offers (Webflow's SEO surface is still better, page by page)
The team has multiple non-designer collaborators editing content — Framer's CMS is leaner than Webflow's
You expect to leave Framer. Exporting Framer to anything else is significantly harder than Webflow export. You're more locked in.

Framer is a launching tool, not always a maintaining tool. It's exceptional for the first six months and can become a constraint at month eighteen.

Hand-coded: when it's worth the cost

Hand-coded (a modern stack — Next.js, Astro, SvelteKit, plus a headless CMS like Sanity or Contentful) wins when:

The site has bespoke interaction requirements — true product surfaces, multi-step flows, custom data visualizations
The team has developer capacity to maintain it
You're at a scale where the time investment pays back — typically 100+ pages, or sites with significant traffic
You need deep integration with internal systems, custom APIs, or analytics infrastructure
Performance is a feature — every kilobyte matters, and the page must score 99 on Lighthouse

The strength of hand-coded is no ceilings. Anything you can imagine, you can build. The price is that you have to imagine it, build it, and maintain it.

Where hand-coded is painful

It struggles when:

The team has no developer, or only contractor capacity. Hand-coded sites die slow deaths when the contractor leaves.
The content cadence is high and managed by non-developers. Headless CMS interfaces have come a long way but they're still worse for non-tech writers than Webflow's editor.
The project is time-boxed under three weeks and the design is moderate. You'd pay 3x the cost for Webflow-equivalent output.

The honest comparison: a hand-coded site is better than Webflow on every axis that matters once you cross a complexity threshold. Below that threshold, it's worse on every axis except long-term flexibility.

Hand-coded is better on every axis once you cross a complexity threshold. Below it, it's worse on every axis except long-term flexibility. — Internal stack decision note

The moment a project has a component library with real state logic, the no-code tools start charging you rent in workarounds.

The hybrid approach we now default to

For most projects we run in 2026, the answer is none of the above as a single tool — it's a hybrid:

Marketing site: Webflow (best balance of fidelity, editor access, and SEO)
Application UI: Hand-coded (real product, real data, real flexibility)
Launch landing pages and microsites: Framer (speed and motion design)
Blog system: Hand-coded with a CMS (this site is built this way — Eleventy + Sveltia CMS)

The hybrid frustrates founders who want a single answer. It's also what produces sites that don't compromise.

The comparison, on one screen

Everything above, condensed. Read down the column you're leaning toward and check whether the "costs you" row is a price you're willing to pay — that's usually the row that decides it.

	Webflow	Framer	Hand-coded
Best at	Marketing sites a non-developer will keep editing	Launch pages and microsites with real motion design	Product UI, and anything with genuine state logic
Time to first ship	Days to weeks	Hours to days	Weeks
Who can edit it after	Anyone, via the editor	Designers, comfortably	Developers only, unless you add a CMS
Design fidelity ceiling	High	High, and highest for motion	No ceiling
SEO control	Good — meta, redirects, clean markup	Adequate, improving	Total
Costs you	A monthly fee, and a wall you eventually hit	Hitting that wall sooner	Time up front, and a developer to change things
Breaks down when	The build needs real application logic	The site outgrows a handful of pages	Nobody on the team can maintain it

The row that catches most teams out is the third one. A tool that a marketer can update on a Friday afternoon is worth a real amount of money, and that value never shows up in a feature comparison.

Decision flowchart

If you want a single rule:

Is the site product UI? → Hand-coded.
Is it a launching landing page or microsite with rich animation needs? → Framer.
Is it a marketing site that non-developers need to edit? → Webflow.
Is it a content site with high publishing cadence? → Hand-coded with a CMS (Eleventy/Astro + Sveltia/Sanity).
Is it a single-page promo that needs to ship this week? → Framer.

The flowchart breaks at the edges. A site that's "mostly marketing but with one custom data widget" is exactly the kind of project where the wrong tool choice produces months of regret. For those, run the three-variable test — interaction complexity, maintainer profile, content cadence — and pick honestly.

The most common mistake

The most common mistake we see is picking the tool the founder is most familiar with, regardless of fit. A founder who built their first site in Webflow tends to default to Webflow for everything, including projects where it's clearly the wrong choice. Pick the tool that fits the current problem, not the one you fluently used last time.

What we're watching in 2026

A few moving targets that may change this comparison in the next year:

Framer's CMS is improving fast and may close the gap with Webflow for content-heavy sites.
Webflow's developer tools (more meaningful code export, real API integrations) are slowly maturing.
AI-augmented hand-coded stacks are eating into the "Webflow saves time" argument — at some point, the speed advantage of Webflow disappears when AI can scaffold the equivalent in a hand-coded framework in minutes.

We re-run this comparison every six months and the answer shifts. For now, the hybrid approach above is what we default to. In a year, the right answer may be different.

The tool isn't the brand. Pick the one that fits the project, and don't get attached.

Naming a startup when every dictionary word is taken.

2026-05-19T00:00:00Z

Every good name is already taken. Every available name sounds invented. The naming problem in 2026 isn't creative — it's structural. You're picking from a shrinking pool of options that have to pass four near-incompatible filters at once.

This is the framework we use for naming work. It is not a magic generator. It is a way to think about the problem that produces fewer dead ends.

Why every good name is already taken

When the internet was small, you could name a company "Apple" or "Amazon" because dictionary words still had availability. That window closed roughly 2008–2012. After that, the gold rush on common words ended.

Today, naming a startup means picking from one of three strategies:

Invent a new word that sounds like it could be a real word
Modify an existing word in a way that's still pronounceable
Compound two real words into a new combination

Each strategy has different costs. The framework here helps you pick the one that fits your situation.

Strategy 1: Invent

Companies like Lyft, Tesla, Slack, Stripe, and (yes) Egzecute are all invented or near-invented words. The benefit: trademark and domain availability are almost guaranteed. The cost: nobody knows how to spell it the first time they hear it.

The test for an invented name:

Is it pronounceable on first read? "Tesla" passes, "Mxqz" fails.
Does it follow the phonotactics of the target language? English allows certain consonant clusters and not others. "Stripe" is allowed, "Stkripe" is not.
Does it sound like a real word in some recognizable register? "Lyft" sounds like "lift." That association is the work.

Invented names trade short-term recognition for long-term ownability. If you can afford a 6–12 month branding investment to make the name familiar, this is the strongest strategy. If you can't, it's the riskiest.

Invented, modified, compound. Sorting candidates by construction rather than by preference makes the trade-offs visible before anyone falls in love with a word.

Strategy 2: Modify

Replace a letter, drop a vowel, swap a consonant. Kobo (from "book"), Reddit (from "read"), Tumblr (from "tumble"), Egzecute (from "execute").

The benefit: the root word stays recognizable, so the meaning carries. The cost: you're now in the territory of Google's spell-correction filter. Every search engine will assume your brand is a typo for the original word until you've built enough entity signal to override that assumption. (See Why your brand name isn't showing up on Google — this is exactly the problem we solved for ourselves.)

The test for a modified name:

Is the modification a recognizable alteration? "Kobo" sounds like "book" backward, intentionally. "Krbq" doesn't sound like anything.
Does it pass the spell-check test? Will Google ask "did you mean…" forever, or only at first? The answer depends on how aggressive the modification is.
Is the original word semantically aligned? "Reddit" makes sense (read it). "Tweezer" wouldn't, for a content company.

Modified names are the most common pattern in modern startup naming because they balance recognizability with availability. They also produce the most search-engine pain in year one. Plan for that pain.

Strategy 3: Compound

Combine two real words. Airbnb (air + bnb), Facebook (face + book), Linktree (link + tree), Workspace, Salesforce, Quickbooks.

The benefit: each word carries meaning, the combination feels coined-not-invented, and search engines parse the components correctly.

The cost: most good compounds are also taken. You're competing with twenty other founders for the same recognizable pair.

The test for a compound:

Does the compound describe something the company actually does? "Airbnb" is literal (air mattress + B&B). "Salesforce" is literal. If the compound is poetic-but-vague, it ages worse.
Is the compound pronounceable as a single word? "Workday" yes. "Quickworkflowapp" no.
Does either component carry trademark conflicts? Two-word compounds are more often blocked than invented names.

The naming problem in 2026 isn't creative. It's structural. — Egzecute naming brief

The trademark and domain gauntlet

Before you fall in love with a name, run the four-filter test:

1. USPTO trademark search

Search the United States Patent and Trademark Office database. If a registered mark exists in your trademark class (computer software is class 9 and 42), the name is dead. Period. Same applies for EU, UK, and any market you're entering.

2. Domain availability

The .com is the only one that matters for default brand recall, regardless of what anyone tells you about .io, .co, .ai. The .com redirects. Buying the .com of a name that's already taken on .com-redirect costs $5k–$50k typically. Budget for it or move on.

3. Social handle availability

Check @yourbrand on at least Instagram, LinkedIn, X, and YouTube. If three of the four are taken, the name fragments your brand presence — every channel becomes "yourbrand_official" or "the.real.yourbrand" which dilutes recognition.

4. Google spell-correction test

Open an incognito browser. Search the name. If Google asks "did you mean…" and suggests a dictionary word, you have an entity-recognition problem baked in from day one. Modified names usually fail this. Invented names sometimes pass. Compounds almost always pass.

Reject any name that fails two of these four. Names that pass all four are gold — buy them immediately.

Founders lose months to names that failed filter one on day one. Search the register before you run the workshop, not after. — Egzecute naming brief

A name is only finished when it survives being set, spoken, spelled down a phone line, and searched.

A worksheet for testing names

For every serious candidate, fill in:

NAME: [the candidate]
STRATEGY: [invent / modify / compound]

USPTO check: [pass / conflict in class ___]
.com domain: [available / taken / available for purchase at $___]
@handles: [Instagram: ] [LinkedIn: ] [X: ] [YouTube: ]
Google spell-correction: [passes / fails — suggested word: ___]

Pronounceability (1–10): [score]
Memorability (1–10): [score]
Spelling consistency (does everyone spell it right after hearing it?): [yes/no]
Connotation (positive/neutral/negative/none): [note]

Run this against ten candidates and the top three usually emerge cleanly. The candidates that founders are emotionally attached to but score poorly on the worksheet are exactly the ones to walk away from.

The hard pass

Reject any name whose .com costs more than $20k unless you're a Series A or later. Below that stage, the money is better spent on product or distribution. Domain-squatting tax is real but it's optional — pick a different name.

What to do after the name

Once you've picked a name that passes the gauntlet:

File a trademark application immediately, in your primary class. This is the most important $300 you'll spend.
Register the .com — and the .co, .io, and .ai variants if your category is competitive.
Claim all four social handles even if you don't post to them yet. Squatters are real.
Submit a Wikidata entry for the company. Wikidata is the structured backbone Google uses for entity validation; an early entry accelerates entity recognition.
Start writing the brand name into every piece of content you publish, in natural prose. Repetition is how Google's NLP learns that this character string is an entity.

Then live with it. Names don't reveal their quality in week one. They reveal it in year three, when the brand has either become a verb or remained a typo.

Stop designing case studies. Start designing arguments.

2026-05-12T00:00:00Z

The traditional case-study template — challenge, approach, solution, results — is so widespread it feels like a law of nature. It is not. It is one specific narrative structure, inherited from consulting decks, optimized for showing process. And it is the wrong structure for an agency website.

This is the essay where we explain why our case studies are getting rewritten this quarter.

The traditional case-study format (and why it fails)

The four-act template — Challenge → Approach → Solution → Results — is a chronology. It tells the story of the project in roughly the order it happened.

The problem: nobody reading a case study is interested in chronology. They are interested in whether you can solve their problem. The chronology buries the answer to that question in the middle of the article, behind setup the reader has to wade through.

A typical reader's actual journey:

They land on the case study from a Google result or a homepage link.
They scan for proof: "Did they solve a problem similar to mine?"
If proof is visible, they read more.
If proof is buried, they bounce.

The four-act format puts the proof in act four. Most readers don't make it.

Argument-shaped: the claim sits on top, and everything beneath it is evidence. Chronology, where it survives at all, is in service of the claim.

What an argument-shaped case study looks like

An argument-shaped case study reverses the order. It starts with the conclusion — the proof — and then unpacks the reasoning behind it.

The structure we now use, in order:

The headline outcome — one sentence, with numbers if possible
The argument — the insight that produced the outcome, in one paragraph
The proof — the specific work, with visuals
The why — what was non-obvious about the approach

Put the two structures side by side and the difference is mostly about what each one asks the reader to do first:

	Four-act chronology	Argument-shaped
Opens with	The client's situation before you arrived	The outcome you produced
Reader's first question	"How long is this?"	"Could they do that for us?"
Proof appears	Act four	The first line
Organizing logic	The order things happened	The order a sceptic needs convincing
Rewards	Readers who finish	Readers who scan
Fails when	The reader leaves early — most of them do	You have no outcome worth leading with

The last row is the honest catch. Argument-shaped case studies are harder to write, because they will not let you hide a project that didn't produce much.

The reader sees the headline outcome on screen one. If it's relevant to them, they keep reading. If not, they bounce — which is fine. The case study has done its job.

The 4 questions a great case study answers

When we audit our own case studies now, we test each one against four questions:

1. What did the client get out of this?

Not "we delivered a brand identity system." That's the deliverable. The outcome is what changed for the client because of the deliverable. "Their close rate on enterprise demos went from 12% to 28% in the quarter after launch." "They were able to onboard their first three Fortune 500 clients with the new positioning." Outcomes are measurable changes in the client's world, not artifacts produced by us.

2. What was non-obvious about how we got there?

If the approach is "we did research, then design, then refinement," there's no insight to communicate. The case study has nothing to teach. But almost every project we've worked on contains one specific insight that wasn't obvious at the start — a reframing of the problem, an unusual constraint we accepted, a decision to not do something the brief asked for. That insight is the case study.

3. What does this tell a future client about how we work?

A case study isn't a portfolio piece. It's a sample of working with us. A potential client reading it is asking, "If I hire them, what's the texture of the engagement?" The case study should leave them with a clear sense — confident about some things, aware of constraints about others.

4. What would I, as a designer, want to take away from this if I read it?

A case study that other designers can learn from is also a case study that clients can trust, because it reveals craft. We write our case studies to be useful to peers, not just to potential clients. That double-purpose tightens the writing.

A case study isn't a portfolio piece. It's a sample of working with us. — Internal case-study principle

Each section pairs one decision with one outcome. Nothing is included because it merely happened.

The Wealthora case study, redesigned

The previous version of our Wealthora case study followed the four-act template. It opened with "Wealthora is an enterprise asset management platform redefining…" Three paragraphs of setup. Then the brief. Then the design. Then a results section at the bottom that nobody made it to.

The redesigned version opens with: "Wealthora's close rate on enterprise demos went from 18% to 41% within six months of the new design system shipping."

That's the first sentence. The rest of the page argues why — the specific design insight that produced that lift. The visual work is downstream of the argument, not the lead.

Templates and traps

The argument-shaped case study has two failure modes to watch for:

Trap 1: Inflating the outcome. If you don't have a real measurable outcome, do not invent one. "Increased engagement" is meaningless. "Achieved positive client sentiment" is fluff. Better to lead with a qualitative claim that's specific — "The client now uses this brand system across three product lines without modification" — than to lead with a hollow number.

Trap 2: Substituting opinion for insight. The argument has to be specific. "We focused on simplicity" is opinion. "We removed three of the seven menu items from the navigation because user research showed task-completion improved with fewer choices" is insight. The first is decoration. The second is craft.

The 30-second test

A good case study should communicate the outcome and the insight within 30 seconds of landing on the page — usually within the first scroll. Read your own case studies on a phone with a 30-second timer. If you can't answer "what did the client get?" and "what was non-obvious about how?" in 30 seconds, the structure is wrong.

Why agencies resist this

The four-act template is comforting because it shows us — the agency — doing work. Our process. Our approach. Our research. The argument-shaped template shows the client — their outcome, their world, their problem.

That's the right framing for marketing, even though it feels counterintuitive. Clients don't hire agencies because the process is interesting. They hire agencies because they trust the outcome.

If you only have time to fix one thing on your agency website this quarter, fix the case-study lede. Replace "Client X is a leading provider of…" with "Client X's [specific metric] improved from [number] to [number] within [timeframe]." Then watch your demo bookings move.

Designing for AI search, when the answer isn't a page.

2026-01-13T00:00:00Z

For twenty years the deal was simple: rank a page, get a click, own the reader from there. That deal is being renegotiated without us. A growing share of searches now end in an answer the user never had to click to read — and the brands being quoted inside those answers are not always the ones ranking first.

This is the question we get most often now, usually phrased as some version of "is SEO dead?" It is not, and the panic is mostly misdirected. But the shape of the work has changed, and the parts that changed are not the parts most agencies are talking about.

Here's what we've actually adjusted, and what we've deliberately left alone.

What changed: the click is no longer the unit

The old funnel had one job for a page: earn the click. Everything downstream — the conversion, the trust, the enquiry — happened on your property, under your design control.

AI answers break that model in a specific way. The reader now meets a summary of you, assembled by a machine, before they meet you. Sometimes they arrive afterwards. Often they don't arrive at all, having got what they needed.

That sounds like a loss, and for thin content it is. A page that existed only to capture a query and funnel a click has lost its entire reason to exist. But for brands with genuine expertise, something more useful happens: the summary becomes a referral with a citation attached. The traffic that does arrive is further down the decision than it used to be.

The pages that get quoted look like this: one question, answered near the top, with nothing else competing for the space.

What gets quoted, and what gets skipped

We've been tracking which of our own pages and our clients' pages surface inside AI answers. The pattern is not subtle, and it is not really about SEO at all.

Quoted pages tend to share four traits:

They answer one question. Not a topic — a question. Pages built around "everything about X" get summarized into nothing.
They commit to a position. Hedged writing has nothing extractable in it. "It depends on your needs" is unquotable by design.
They show their work. Numbers, named methods, specific trade-offs. Anything a model can attribute back to a source.
They come from a recognizable entity. The same signal that governs traditional ranking, doing more work than ever.

Skipped pages are usually the mirror image: broad, hedged, unsourced, and published by an organization the machine cannot confidently identify.

A model can only quote you if there is something in the page worth quoting. Most SEO content was engineered to avoid saying anything that specific. — Egzecute SEO note

That last trait is why we keep pushing entity work ahead of content volume. A brand with a coherent, verifiable identity gets cited. A brand the machine can't resolve gets paraphrased without attribution, if it's used at all — which is the same problem we wrote about for brand-name search, arriving through a different door.

What this means for design

Here's the part that gets left out of most write-ups on this, and the part that matters most to us: the design implications are real, and they run in the opposite direction from what people expect.

The intuitive response to "machines read my site now" is to design for machines — strip things back, prioritize parseability, treat visual craft as overhead. That is exactly backwards.

If a share of your audience gets your substance from a summary, then the people who do click through are self-selected: they wanted more than the answer. They came to evaluate you. What they land on is no longer competing with nine other search results — it's competing with the impression the summary already gave them.

	Pre-AI-answer search	Post-AI-answer search
What the click is worth	One visitor among many results	A visitor who chose you specifically
What the page must do first	Convince them to stay	Confirm they were right to come
Cost of a generic template	Some lost conversion	Contradicts the expertise they just read
Role of visual craft	Differentiator	Evidence
Content that wins	Comprehensive	Specific, attributable

That fourth row is the one we'd underline. When a prospect arrives already half-convinced by something a machine quoted from you, the site's job is corroboration. A generic template quietly undercuts the claim. This is not an argument for decoration — it is an argument that craft has become a form of proof.

Same object, different level of finish. When a reader arrives already half-convinced by something a machine quoted, the site's job is to confirm the impression rather than contradict it.

What we haven't changed

Roughly as important, and much less discussed. We have not:

Started writing for models. Every "optimize for LLMs" tactic we've tested either does nothing or is a rewording of "write clearly and be specific," which was already the job.
Abandoned long-form. Depth still wins, because depth is what produces the specific, quotable claim in the first place.
Added an FAQ section to everything. Schema-stuffed FAQ blocks were a 2019 tactic. Answering real questions in the prose works better and reads like a human wrote it.
Chased volume. Publishing more mediocre pages was a bad strategy when humans were the only readers. It's worse now.

The practical test

Take any page you've published this year and try to extract one sentence from it that a competitor could not also honestly publish. If you can't find one, the page has nothing a model can cite and nothing a reader can remember. That is a content problem, not a technical one — and no amount of schema markup will fix it.

Where this actually lands

The uncomfortable summary is that AI search has made the fundamentals matter more, not less, while making the shortcuts stop working entirely. Brands with real expertise, a coherent identity, and the willingness to say something specific are being cited more than they were. Brands that were coasting on keyword coverage have lost the mechanism that was carrying them.

That's an unglamorous conclusion, and it's the one the data keeps supporting. The work is: be a legible entity, know something worth quoting, say it plainly, and build a site that holds up when someone arrives to check whether you meant it.

None of that is new. It's just that the alternatives have stopped working.