Nikki Asteinza
Contact

Two-level dogfooding: how a portfolio and a product site validate the same publishing engine

Before selling a publishing SaaS, I need to test it with real sites. But one internal dogfood case can be deceptive: if the person who designed the product is also the user, gaps are often avoided without anyone noticing.

Important

Useful dogfooding does not validate that "my case works". It validates that the product survives different cases with different risks.

The idea in one image

flowchart LR engine["Publishing engine"] --> level0["Level 0<br/>personal portfolio"] engine --> level1["Level 1<br/>product site"] level0 --> basic["Validates simple start"] level1 --> demanding["Validates demanding migration"] basic --> confidence["Incremental confidence"] demanding --> confidence

The two levels

Level Site What it validates Risk if it fails
0 Personal portfolio New Markdown repo, basic theme, blog, simple pages Low
1 Product site Real traffic, i18n, SEO, navigation, visual parity High

Level 0 lets me iterate without fear. Level 1 prevents the product from staying a pretty demo.

Level 0: personal portfolio

What it requires

  • New content.
  • Flat structure.
  • Technical blog.
  • One theme.
  • Reasonable SEO, but not critical.
  • Low operational risk.

What it proves

  • The engine can read a Markdown repo.
  • The theme applies without complex configuration.
  • Technical articles render well.
  • The basic publishing flow works.
Note

This site does not try to prove every case. It proves that the product can start from clean Markdown, without migration and without prior debt.

Level 1: product site

The product site is the case that looks like a real customer:

Requirement Why it matters
Existing content Publishing cannot force a full rewrite
Multi-page structure A product site is not three isolated Markdown files
i18n The structure must support locales
SEO and sitemap The site is part of the sales funnel
Polished design The tool is judged by its own website
Visual parity Migration must not degrade the current site
Warning

If I only test with the portfolio, I validate the optimistic case. If I start with the product site, I turn the sales funnel into a test bench.

Cut-over sequence

The change must remain reversible until the last moment.

sequenceDiagram participant Old as Current site participant Pub as Publishing candidate participant QA as Visual parity participant DNS as DNS / domain Old->>Old: Keeps serving production Pub->>Pub: Generates static bundle Pub->>QA: Provides candidate QA->>QA: Compares layout, links, SEO and performance QA-->>Pub: Iterates until parity QA->>DNS: Cut-over only if parity = OK DNS-->>Old: Old site is archived

What parity compares

Parity checklist for a product site
  • Same public routes.
  • Correct active navigation.
  • Content rendered without losing technical blocks.
  • Diagrams, formulas, tables, alerts and columns with the same style.
  • Page-level meta tags.
  • Sitemap and robots.
  • OG image and description.
  • Internal links without broken routes.
  • Acceptable mobile and desktop performance.
  • Documented fallback or rollback.

The checklist avoids a common trap: calling the migration done because "the homepage looks fine".

Why two levels work better

flowchart TD portfolio["Portfolio<br/>low risk, medium demand"] --> iterate["Iterate engine and theme"] iterate --> candidate["Stable candidate"] candidate --> product["Product site<br/>high risk, high demand"] product --> proof["Real commercial proof"]

The portfolio sits in low risk and medium demand: it is good for iteration. The product site sits in high risk and high demand: it validates the engine once the engine is ready.

What the product learns

Question Level 0 Level 1
Can it start from scratch? Yes Not the focus
Can it migrate real content? No Yes
Can it support a technical blog? Yes Yes
Can it support a commercial site? Partially Yes
Can it fail cheaply? Yes No
Does it work as a sales argument? Supports Proves

The trap it avoids

The trap is launching the SaaS and "validating with customers". The first customer who discovers that the system does not support i18n, SEO or real navigation will not file an issue. They will leave.

Tip

The best dogfood reproduces customer problems before customers pay for them with their patience.

The rule I keep

One-level dogfooding validates the optimistic version of the product. Two levels with contrasting demands validate that the product is real.

This article is part of my product notes. If you are interested in this work, follow the blog or contact me.