update handbook with PostHog Desktop rename#18780
Conversation
and cleaned up some stray em dashes
Deploy preview
|
|
Vale prose linter → found 116 errors, 546 warnings, 4 suggestions in your markdown Full report → · Copy the Job Summary code block into an LLM to batch-fix issues.
|
Bundle reportTotal JS (gzip)6.75 MiB (+4.2 KiB / +0.1%) Largest changed named chunks
Eager graph (modules shipped in each entrypoint's initial chunks)
Largest modules in the
|
| Module | Size |
|---|---|
./src/data/mcp-tools.json |
888.6 KiB |
css ./node_modules/.pnpm/css-loader@5.2.7_webpack@5.101.3/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[1]!./node_modules/.pnpm/postcss-loader@4.3.0_postcss@8.5.6_webpack@5.101.3/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[8].oneOf[1].use[2]!./src/styles/global.css |
747.2 KiB |
./src/components/Stickers/Stickers.tsx |
696.4 KiB |
./node_modules/.pnpm/@radix-ui+react-icons@1.3.2_react@18.3.1/node_modules/@radix-ui/react-icons/dist/react-icons.esm.js |
481.4 KiB |
./node_modules/.pnpm/rehype-raw@7.0.0/node_modules/rehype-raw/lib/index.js + 29 modules |
395.1 KiB |
./node_modules/.pnpm/@posthog+icons@0.36.6_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.cjs.js |
364.8 KiB |
./src/hooks/useCustomers.tsx + 54 modules |
355.1 KiB |
./node_modules/.pnpm/@posthog+icons@0.36.6_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@posthog/icons/dist/posthog-icons.es.js |
354.8 KiB |
./node_modules/.pnpm/react-markdown@8.0.7_@types+react@16.14.66_react@18.3.1/node_modules/react-markdown/lib/react-markdown.js + 88 modules |
351.4 KiB |
./node_modules/.pnpm/cloudinary-core@2.14.0_lodash@4.17.21/node_modules/cloudinary-core/cloudinary-core.js |
281.9 KiB |
./src/components/ProductComparisonTable/index.tsx + 120 modules |
278.6 KiB |
./src/components/SearchUI/index.tsx + 87 modules |
272.1 KiB |
./node_modules/.pnpm/framer-motion@10.18.0_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/framer-motion/dist/es/render/dom/motion.mjs + 109 modules |
253.9 KiB |
./node_modules/.pnpm/d3@7.9.0/node_modules/d3/src/index.js + 208 modules |
247.4 KiB |
./src/components/Pricing/PricingSlider/Slider.tsx + 87 modules |
239.9 KiB |
Eager-graph budgets are report-only until a baseline is established. Sizes are gzip of public/**/*.js; eager size is webpack module source bytes for the modules actually shipped in the entrypoint's initial chunks (post-tree-shake).
charlescook-ph
left a comment
charlescook-ph
left a comment
There was a problem hiding this comment.
I brain-read all the files like a sociopath, looks good!
I think it might be worth pulling out the positioning doc as a separate PR maybe? I feel like that section was generally quite woolly/waffley and not something people would actually use in real life when talking about the product, sorry 🙇
|
|
||
| PostHog Desktop is a product editor: a desktop app where you, your team, and a fleet of coding agents build your product together. | ||
|
|
||
| The same self-driving engine that turns product data into pull requests runs in PostHog web, but Desktop isn't where you watch that work happen; it's where you do it. Think of the web app as the dashboard and Desktop as the driver's seat. |
There was a problem hiding this comment.
LLM alert - it's isn't blah, it's blooh (I don't think the phrase even really says much)
The web app also isn't really a dashboard right as people can ship PRs from there too? Maybe it's more about the level of the complexity of the work?
|
|
||
| ## The unique belief (in terms of PostHog Desktop) | ||
|
|
||
| Agents write most of code now. Claude Code and Codex are all excellent at the work, but neither of them can originate it – they need a prompt from a human to turn it into a task. The solution isn't a chat box, and it isn't an IDE. It's a product editor: one that's deeply integrated with your data, and multiplayer (like work actually is). |
There was a problem hiding this comment.
again, it isn't blerp, it's blorp.
Can you say more about what deeply integrated with your data actually means maybe? I think that's the unique belief right?
|
|
||
| ### Message 1: Real usage catches what review can't | ||
|
|
||
| **Problem:** Code review catches wrongness in the syntax, but it can't catch wrongness in *behaviour*. That's because behaviour only shows up in production. |
There was a problem hiding this comment.
US spelling (sorry), also generally this feels very fluffy and LLM-y:
- 'catches wrongness in the syntax but can't catch wrongness in behaviour' - you mean user behaviour or something else?
- 'flags and experiments are how a code change actually earns its spot' - nobody is ever going to say this phrase in real life
I feel like generally these messages need manual writing so they sounds more like words our sales team could say.
| - Canvases: ask for a dashboard, report, or internal tool and get it built on your real data model *(alpha)* | ||
| - No markup – you pay the token costs, not a subscription stacked on top | ||
|
|
||
| ## Battle cards |
There was a problem hiding this comment.
these are pretty good! anything on Notion/Linear?
There was a problem hiding this comment.
I don't think anyone would compare PostHog to either at this point?
Maybe linear agents, but that's more self-driving than desktop specifically.
There was a problem hiding this comment.
Yeah fair, that's prob vs. the overall PostHog vision vs. desktop specifically (this was the example that came to mind)
|
|
||
| **What they're really saying:** Inference feels free right now. Anything metered next to a flat, subsidized sub looks expensive. | ||
|
|
||
| **Answer:** You're comparing the cost of generating changes with the cost of knowing whether they worked. Run the logic forward: subsidized inference means you'll run more agents making more changes, which makes verification the growing line item, not the optional one. We also run open source models, which are getting good enough to handle plenty of the work for a fraction of the cost. |
There was a problem hiding this comment.
I think the answer here is probably around models, the rest is a bit word salady.
|
|
||
| *When they push on bill predictability (a fair worry) point at billing limits and per-tool caps. Don't argue that usage-based pricing is painless; argue it's honest.* | ||
|
|
||
| ### "We already have an established stack. Why consolidate?" |
There was a problem hiding this comment.
I suspect people will say 'why trust PostHog, you are an analytics company'
|
|
||
| **What they're really saying:** The 2030 story is ahead of my org. Don't sell me the destination. | ||
|
|
||
| **Answer:** No problem – most teams are here. Our version of the agent loop is worth running because it doesn't rely on autonomy from humans (just autonomy from instruction). You set the bar for which repos to connect, PostHog agents follow your CI rules, and you cap the spend on PR creation. |
There was a problem hiding this comment.
We still review the agents' PRs right?
|
@charlescook-ph Totally fair (and I agree it's a bit wooly). Figured it was better to have something fast to get reactions to (then then tweak) instead of spending loads of upfront time polishing. |
…ging Generated-By: PostHog Code
2 participants
Changes
Checklist
vercel.json