Inkly vs Walnut: Which demo lives in your repo?

A few months ago, on a previous project, I was cleaning out a shared Notion doc and found a product walkthrough I'd built for our first wave of enterprise conversations. I opened it expecting to archive it. Instead, I sat there for a few minutes reading a demo for a product I no longer shipped. The navigation was wrong, the pricing modal had already been redesigned twice, and the onboarding flow had been replaced entirely. Nobody had touched the doc. It had just drifted away from reality while we kept sending the link.

The cost was very concrete: I had to reconstruct what the product actually looked like, screen by screen, and rebuild the whole thing from scratch in a hosted editor. Three hours I didn't have, for an artifact that would start going stale again the moment we shipped the next sprint.

That's the real question in Inkly vs Walnut: not which tool makes a prettier first demo, but which one lets you keep the demo current without leaving your normal workflow. Walnut keeps the demo inside its platform. Inkly makes the demo code you own.

What Inkly and Walnut are solving

The same demo job, two different artifacts

Both tools exist to give prospects a polished, clickable product experience before they ever touch the real thing. The difference is what they produce. Walnut captures your product and stores it as an editable asset inside Walnut's platform. You update it through their visual editor, inside their SaaS. Inkly emits the demo as HTML code that lives wherever you put it: your repo, your hosting, your agent's context window.

That sounds abstract until you ship a UI change.

Why the artifact matters before the first update

The first demo is easy on both tools. The artifact choice only starts to matter the second time, when the product changes and the demo doesn't. With a hosted artifact, the update path runs through the vendor's editor. You log in, find the affected screens, fix them manually, and republish. With a code-owned artifact, the update path runs through your coding agent. You re-prompt against the existing demo code and the change propagates. The demo can move with the product instead of getting pinned to a separate editing workflow.

Why repo ownership changes the comparison

The table below shows where Inkly and Walnut land on the axes that matter most for a repo-native team.

The two tools share the same first-demo job. What separates them is where the artifact lives and what an update costs.

Tools compared: Inkly, Walnut.

Why a demo in git behaves differently from a demo in a dashboard

Code-owned demos can be versioned, reviewed, and diffed like any other file in the repo. A change to the demo shows up in a pull request next to the product change that prompted it. Your coding agent — Cursor, Claude Code, Codex — can read the demo file, understand its structure, and update it from a plain-language prompt. The demo becomes part of the product's source of truth instead of a separate artifact someone has to remember to maintain.

Walnut's workflow is different. The demo lives inside Walnut's platform, and updates happen through Walnut's visual editor. That editor is polished and capable, but it's still a separate tool, a separate login, and a separate mental context from the repo where the product actually lives.

The handoff problem no hosted editor really removes

When the demo lives in a vendor platform, whoever knows that platform owns the demo. Engineers can't review a Walnut demo in a pull request. They can't run a diff when a product change requires a demo update. A non-engineer can own the Walnut workflow, which is genuinely useful, but it also means the demo and the product are maintained by different people in different tools. Keeping them in sync becomes a coordination problem. Repo-native demos cut out that handoff: the engineer who ships the feature can update the demo in the same PR.

What breaks when the product UI changes

A changed button label is the easy case

A small copy change — a button renamed, a label updated — is manageable in both tools. In Walnut, you find the affected screen in the editor and type the new text. In Inkly, you tell your agent what changed and it updates the demo code. The Walnut path requires you to be in Walnut; the Inkly path requires you to have a coding agent running. For a team already in Cursor or Claude Code all day, Inkly costs less context switching. For a team that doesn't use a coding agent, Walnut's visual editor is the more accessible route.

Structural changes are where the gap shows up

A nav restructure, a redesigned onboarding flow, or a new modal sequence is a different problem. In a hosted demo tool, structural changes usually mean recapturing the affected screens. There's no in-place layout edit that really handles a flow change. Every screen that moved or changed needs to be re-recorded or rebuilt in the editor. In a code-owned demo, the structure is defined in the code. You re-prompt your agent with the new flow, and it rewrites the relevant sections. The hosted workflow scales with the number of affected screens. The code-native workflow scales with the complexity of the prompt.

Editing speed is not just how fast you click

Prompt-to-update versus manual rework

The edit loop in Walnut is visual and manual: navigate to the screen, make the change, verify it looks right, move to the next screen. That is not slow. Walnut's editor is built to make this fast. But it's still a per-screen, per-element process that runs inside their platform. The Inkly edit loop is a conversation with your agent: describe the change, review the output, commit. Which one feels faster depends on how many screens are affected and how comfortable you are with a coding agent. For a single-screen text change, Walnut is probably faster. For a multi-screen structural update, the agent prompt scales better.

Where Cursor, Claude Code, and Codex fit

An AI-native demo workflow is not a feature you toggle on. It's a consequence of where the demo artifact lives. If the demo is code in your repo, your coding agent can read it, edit it, and produce variants from it using the same prompting workflow you already use for the product. Cursor can open the demo file. Claude Code can rewrite a section. Codex can generate a customer-specific variant off the base. None of that is possible when the demo is locked inside a vendor's SaaS. Inkly's agent-fluency advantage is not a separate feature. It's what happens when the artifact is code you own.

Which tool fits a small SaaS team

When Walnut is the simpler answer

Walnut makes sense when the team wants a polished hosted demo builder and doesn't operate out of a repo. Sales teams, GTM leads, and founders who want to build and update demos without touching code will find Walnut's visual editor more approachable than a coding-agent workflow. Walnut also has a mature sales-enablement feature set — demo centers, analytics, team collaboration — built for a sales-led motion. If that's the buyer, Walnut is a reasonable fit.

When Inkly is the better fit

Inkly is the right call when the demo has to stay close to the codebase and the team already ships through Cursor, Claude Code, or Codex. Founders building investor demos, product engineers who want the demo to reflect the current build, and indie hackers who don't want another SaaS login in the maintenance loop — these are the people the Inkly workflow was built for. The demo is code you own, it lives next to your product, and your agent keeps it current. Ship a pitch-ready demo without adding a separate editing tool to your stack.

The honest tradeoff on both sides

Walnut requires a sales conversation to get started. There's no self-serve pricing page. That tells you who it's built for: funded teams with a sales motion, not solo founders or small engineering teams. Inkly's limitation is the bring-your-own-agent requirement. The MVP path assumes you already have Cursor, Claude Code, or Codex set up and are comfortable prompting your way through a code update. If your team doesn't work that way, Inkly is extra setup before you get to the demo. Walnut's all-in-platform flow is the cleaner starting point for teams new to coding agents.

Where Inkly comes in

The problem this article has been describing isn't a feature gap. It's an artifact gap. When the demo lives inside a vendor's platform, every product change becomes a separate editing task in a separate tool. That's not Walnut's failure. It's the consequence of the hosted-artifact model. The fix isn't a better editor. It's a demo that lives in the same place as the product and gets updated the same way.

Inkly is built on that premise. The demo is code you own. It lives in your repo, it's readable by your agent, and it updates from a prompt instead of a re-record. The three-prompt loop — create, update, produce variants — replaces the three things that historically made demo maintenance painful. When your product ships a structural change, you re-prompt the existing demo code. No screen-by-screen editor pass required. When a new customer needs a tailored version, you prompt for a variant off the base code: same flow, different branding, in minutes. Inkly is free, so HTML demos are available without a tier gate. The one real constraint: you need a coding agent already in your workflow. If you're already in Cursor or Claude Code, demos as code you own is the natural next step.

FAQ

Q: Which tool is better if I want the demo to stay close to my codebase?

Inkly. The demo is emitted as code that lives in your repo, alongside your product. Your coding agent (Cursor, Claude Code, Codex) can read, edit, and version it like any other file. Walnut stores the demo inside its own platform. There's no repo sync, no diff, no agent access to the artifact.

Q: How much ongoing upkeep does each tool create when the product changes?

On Walnut, upkeep runs through the visual editor: find the affected screens, fix them manually, republish. On Inkly, upkeep runs through a prompt: describe the change to your agent, review the output, commit. For small copy changes, the effort is comparable. For structural UI changes affecting multiple screens, the agent-prompt path scales better. The work grows with prompt complexity rather than screen count.

Q: Which option gives a founder or product engineer more ownership and control over the demo?

Inkly. Ownership is literal: the demo is a file you control, in a repo you control, editable by any agent or developer on your team. Walnut's demo lives inside Walnut's platform. You can export content, but the artifact and its editing workflow are platform-dependent. For a product engineer who wants the demo treated like product code, Inkly is the only option here.

Q: How do Inkly and Walnut differ in editing speed and team handoff?

Walnut's visual editor is fast for non-engineers — anyone with access to the platform can update a screen without touching code. Inkly's edit loop is faster for teams already running a coding agent, but it requires that agent to be set up. On team handoff: Walnut's demo can be updated by whoever owns the Walnut account; Inkly's demo can be updated by anyone with repo access and a coding agent. Different handoff shapes for different team structures.

Q: Which tool is better for an AI-native or vibe-coded demo workflow?

Inkly. The demo being code in your repo is the precondition for an agent-native workflow. Your coding agent can read the file, understand the structure, and update it from a natural-language prompt. Walnut's AI features operate inside their platform's editor; the artifact is not accessible to an external agent. If your workflow is Cursor or Claude Code, Inkly fits that loop. Walnut is conventional SaaS editing, which is the right fit for teams that don't operate through a coding agent.

Conclusion

The ownership question from the opener hasn't changed: if the demo should live with the code — versioned in git, updated by your agent, maintained as part of the product — Inkly is the better call. If you want a polished hosted builder with a visual editor and a sales-team workflow, Walnut makes more sense. The test is simple: pick a real UI change in your product this week and trace the update path on each tool. On Walnut, that path runs through their editor. On Inkly, it runs through a prompt. Which one fits how your team already works is the answer.