@ranimontagna/agent-toolkit 0.3.6 → 0.3.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (107) hide show
  1. package/CHANGELOG.md +2 -0
  2. package/README.md +1 -1
  3. package/package.json +1 -1
  4. package/skills/backend/fastify-best-practices/NOTICE.md +1 -1
  5. package/skills/backend/fastify-best-practices/rules/authentication.md +13 -0
  6. package/skills/backend/fastify-best-practices/rules/configuration.md +9 -0
  7. package/skills/backend/fastify-best-practices/rules/content-type.md +16 -0
  8. package/skills/backend/fastify-best-practices/rules/cors-security.md +18 -0
  9. package/skills/backend/fastify-best-practices/rules/database.md +12 -0
  10. package/skills/backend/fastify-best-practices/rules/decorators.md +14 -0
  11. package/skills/backend/fastify-best-practices/rules/deployment.md +16 -0
  12. package/skills/backend/fastify-best-practices/rules/error-handling.md +16 -0
  13. package/skills/backend/fastify-best-practices/rules/hooks.md +20 -0
  14. package/skills/backend/fastify-best-practices/rules/http-proxy.md +11 -0
  15. package/skills/backend/fastify-best-practices/rules/logging.md +18 -0
  16. package/skills/backend/fastify-best-practices/rules/performance.md +20 -0
  17. package/skills/backend/fastify-best-practices/rules/plugins.md +14 -0
  18. package/skills/backend/fastify-best-practices/rules/routes.md +18 -0
  19. package/skills/backend/fastify-best-practices/rules/schemas.md +20 -0
  20. package/skills/backend/fastify-best-practices/rules/serialization.md +19 -0
  21. package/skills/backend/fastify-best-practices/rules/testing.md +17 -0
  22. package/skills/backend/fastify-best-practices/rules/typescript.md +15 -0
  23. package/skills/backend/fastify-best-practices/rules/websockets.md +15 -0
  24. package/skills/backend/go/golang-patterns/NOTICE.md +1 -1
  25. package/skills/backend/go/golang-patterns/SKILL.md +2 -1
  26. package/skills/devops/docker-patterns/NOTICE.md +1 -1
  27. package/skills/devops/docker-patterns/SKILL.md +3 -3
  28. package/skills/frontend/design/revenue-centric-design/NOTICE.md +1 -1
  29. package/skills/frontend/design/revenue-centric-design/SKILL.md +6 -4
  30. package/skills/frontend/design/revenue-centric-design/assets/1985681720104903142__1.jpg +0 -0
  31. package/skills/frontend/design/revenue-centric-design/assets/1999584679247134761__1.jpg +0 -0
  32. package/skills/frontend/design/revenue-centric-design/assets/2000930776636940333__1.jpg +0 -0
  33. package/skills/frontend/design/revenue-centric-design/assets/2018693884449009956__3.jpg +0 -0
  34. package/skills/frontend/design/revenue-centric-design/assets/2081714430811730162__1.jpg +0 -0
  35. package/skills/frontend/design/revenue-centric-design/assets/2092692547244007852__q__1.jpg +0 -0
  36. package/skills/frontend/design/revenue-centric-design/assets/2092692547244007852__q__2.jpg +0 -0
  37. package/skills/frontend/design/revenue-centric-design/assets/2092692547244007852__q__3.jpg +0 -0
  38. package/skills/frontend/design/revenue-centric-design/references/checkout-and-forms.md +39 -0
  39. package/skills/frontend/design/revenue-centric-design/references/churn-and-retention.md +25 -0
  40. package/skills/frontend/design/revenue-centric-design/references/conversion-and-landing-pages.md +52 -1
  41. package/skills/frontend/design/revenue-centric-design/references/dashboards-and-data-viz.md +23 -0
  42. package/skills/frontend/design/revenue-centric-design/references/metrics-and-experimentation.md +13 -0
  43. package/skills/frontend/design/revenue-centric-design/references/onboarding-and-activation.md +7 -1
  44. package/skills/frontend/design/revenue-centric-design/references/pricing-and-monetization.md +35 -8
  45. package/skills/frontend/design/revenue-centric-design/references/product-strategy-and-features.md +37 -0
  46. package/skills/frontend/design/revenue-centric-design/references/revenue-centric-design.md +2 -2
  47. package/skills/frontend/design/ui-ux-pro-max/NOTICE.md +6 -4
  48. package/skills/frontend/design/ui-ux-pro-max/SKILL.md +103 -573
  49. package/skills/frontend/design/ui-ux-pro-max/data/app-interface.csv +29 -27
  50. package/skills/frontend/design/ui-ux-pro-max/data/catalog-summary.json +78 -0
  51. package/skills/frontend/design/ui-ux-pro-max/data/charts.csv +26 -26
  52. package/skills/frontend/design/ui-ux-pro-max/data/colors.csv +191 -160
  53. package/skills/frontend/design/ui-ux-pro-max/data/data-provenance.json +1348 -0
  54. package/skills/frontend/design/ui-ux-pro-max/data/google-font-licenses.json +20185 -0
  55. package/skills/frontend/design/ui-ux-pro-max/data/google-fonts.csv +1934 -1923
  56. package/skills/frontend/design/ui-ux-pro-max/data/icons.csv +106 -106
  57. package/skills/frontend/design/ui-ux-pro-max/data/landing.csv +35 -35
  58. package/skills/frontend/design/ui-ux-pro-max/data/motion.csv +18 -0
  59. package/skills/frontend/design/ui-ux-pro-max/data/phosphor-icons-upstream.json +32582 -0
  60. package/skills/frontend/design/ui-ux-pro-max/data/products.csv +192 -161
  61. package/skills/frontend/design/ui-ux-pro-max/data/react-performance.csv +37 -37
  62. package/skills/frontend/design/ui-ux-pro-max/data/stacks/angular.csv +51 -51
  63. package/skills/frontend/design/ui-ux-pro-max/data/stacks/astro.csv +54 -54
  64. package/skills/frontend/design/ui-ux-pro-max/data/stacks/avalonia.csv +57 -0
  65. package/skills/frontend/design/ui-ux-pro-max/data/stacks/flutter.csv +53 -53
  66. package/skills/frontend/design/ui-ux-pro-max/data/stacks/html-tailwind.csv +60 -56
  67. package/skills/frontend/design/ui-ux-pro-max/data/stacks/javafx.csv +76 -0
  68. package/skills/frontend/design/ui-ux-pro-max/data/stacks/jetpack-compose.csv +53 -53
  69. package/skills/frontend/design/ui-ux-pro-max/data/stacks/laravel.csv +51 -51
  70. package/skills/frontend/design/ui-ux-pro-max/data/stacks/nextjs.csv +62 -53
  71. package/skills/frontend/design/ui-ux-pro-max/data/stacks/nuxt-ui.csv +77 -51
  72. package/skills/frontend/design/ui-ux-pro-max/data/stacks/nuxtjs.csv +68 -59
  73. package/skills/frontend/design/ui-ux-pro-max/data/stacks/react-native.csv +52 -52
  74. package/skills/frontend/design/ui-ux-pro-max/data/stacks/react.csv +67 -54
  75. package/skills/frontend/design/ui-ux-pro-max/data/stacks/shadcn.csv +69 -61
  76. package/skills/frontend/design/ui-ux-pro-max/data/stacks/svelte.csv +56 -54
  77. package/skills/frontend/design/ui-ux-pro-max/data/stacks/swiftui.csv +51 -51
  78. package/skills/frontend/design/ui-ux-pro-max/data/stacks/threejs.csv +54 -54
  79. package/skills/frontend/design/ui-ux-pro-max/data/stacks/uno.csv +60 -0
  80. package/skills/frontend/design/ui-ux-pro-max/data/stacks/uwp.csv +56 -0
  81. package/skills/frontend/design/ui-ux-pro-max/data/stacks/vue.csv +50 -50
  82. package/skills/frontend/design/ui-ux-pro-max/data/stacks/winui.csv +60 -0
  83. package/skills/frontend/design/ui-ux-pro-max/data/stacks/wpf.csv +57 -0
  84. package/skills/frontend/design/ui-ux-pro-max/data/styles.csv +89 -85
  85. package/skills/frontend/design/ui-ux-pro-max/data/typography.csv +74 -73
  86. package/skills/frontend/design/ui-ux-pro-max/data/ui-reasoning.csv +193 -162
  87. package/skills/frontend/design/ui-ux-pro-max/data/ux-guidelines.csv +30 -10
  88. package/skills/frontend/design/ui-ux-pro-max/references/pro-rules.md +117 -0
  89. package/skills/frontend/design/ui-ux-pro-max/references/quick-reference.md +256 -0
  90. package/skills/frontend/design/ui-ux-pro-max/scripts/core.py +800 -69
  91. package/skills/frontend/design/ui-ux-pro-max/scripts/design_system.py +700 -180
  92. package/skills/frontend/design/ui-ux-pro-max/scripts/reasoning_contract.py +123 -0
  93. package/skills/frontend/design/ui-ux-pro-max/scripts/search.py +105 -42
  94. package/skills/frontend/design/ui-ux-pro-max/scripts/validate_data.py +1095 -0
  95. package/skills/frontend/react-native/react-native-unistyles-v3/NOTICE.md +1 -1
  96. package/skills/frontend/react-native/react-native-unistyles-v3/SKILL.md +33 -24
  97. package/skills/frontend/react-native/react-native-unistyles-v3/references/api-reference.md +135 -78
  98. package/skills/frontend/react-native/react-native-unistyles-v3/references/common-issues.md +48 -31
  99. package/skills/frontend/react-native/react-native-unistyles-v3/references/setup-guide.md +76 -34
  100. package/skills/frontend/react-native/react-native-unistyles-v3/references/styling-patterns.md +145 -52
  101. package/skills/frontend/react-native/react-native-unistyles-v3/references/third-party-integration.md +76 -27
  102. package/skills/media/brag-slim/NOTICE.md +3 -3
  103. package/skills/media/brag-slim/SKILL.md +4 -0
  104. package/skills/frontend/design/revenue-centric-design/assets/2018693884449009956__1.jpg +0 -0
  105. package/skills/frontend/design/ui-ux-pro-max/data/_sync_all.py +0 -414
  106. package/skills/frontend/design/ui-ux-pro-max/data/design.csv +0 -1776
  107. package/skills/frontend/design/ui-ux-pro-max/data/draft.csv +0 -1779
@@ -0,0 +1,39 @@
1
+ # Checkout & Forms (Conversion-Completion Layer)
2
+
3
+ > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post. The checkout is where ~70% of drops happen — it's the highest-leverage page most founders treat as an afterthought.
4
+
5
+ ## Friction kills conversion — field count, input type, and perceived risk all compound
6
+ **Principle.** More fields = lower conversion, but the *type* of input matters too: text fields usually generate less impact, while dropdowns and textareas hurt more. Phone number drops conversion; any data that raises perceived risk or invasiveness does the same. And perceived effort ≠ real effort — 5 steps with 2 fields per screen can beat 2 screens with 7 fields each.
7
+ **Apply when.** Optimizing lead forms, pre-checkout, signup.
8
+ **The move.** Count perceived effort, not steps. A screen full of text, warnings, secondary info raises cognitive load even without interaction. Ask: how much effort can I remove without destroying the business value of that data? Sometimes the fix is between things — more breathing room, less noise, clearer hierarchy. Your form should look like a corridor, not an interrogation room.
9
+ **Evidence.** HubSpot study across 40,000+ landing pages: 3-field forms convert above 25%; adding fields trends conversion down. Phone field drops conversion to ~13.5% vs 19% without.
10
+ **Source.** [@richardrx · 2026-08-12](https://x.com/richardrx/status/2087502085151424711)
11
+
12
+ ## Microcopy at the point of fraud risk beats friction everywhere else
13
+ **Principle.** Design must protect the user from the real environment the product lives in — especially in low-trust economies. One line of microcopy in the right place prevents scams that cost more than the friction of adding it.
14
+ **Apply when.** Users are getting scammed through a flow your product enables (delivery PIN sharing, social engineering).
15
+ **The move.** Add microcopy at the exact risk moment: "Never share your number outside the app. The store and courier already have your contact via chat." Transparency is the antidote in low-trust verticals (auto repair, delivery).
16
+ **Voice.** "Scam costs more than friction."
17
+ **Source.** [@richardrx · 2026-06-29](https://x.com/richardrx/status/2071546806987538924)
18
+
19
+ ## You lose money on the boring screens
20
+ **Principle.** Registration forms are where you lose users one input at a time, creating holes in your bucket and wasting CAC — while founders polish the hero. The idea is to remove cognitive load until the flow is so smooth the user doesn't notice it.
21
+ **Apply when.** Conversion leaks between signup and first value; form-heavy onboarding.
22
+ **The move.** (1) Ask less — only what's relevant at that specific step; more questions = less conversion. (2) Avoid typing when possible (swipe/tap costs less than entering data, especially mobile). (3) Explain when asking for sensitive data (documents) — increases completion. (4) Never block paste (card numbers, CEP get copied, not memorized). (5) Help users not mistype passwords (optional visibility toggle). (6) Avoid dropdowns — they hide the answers from the user; with fewer than ~6 options, use a button group instead.
23
+ **Voice.** "You lose money on the boring screens."
24
+ **Source.** [@richardrx · 2025-12-23](https://x.com/richardrx/status/2003495704849760387)
25
+
26
+ ## Checkout is where ~70% of drops happen — every extra input is less conversion
27
+ **Principle.** At checkout, less is more. Each extra input is less conversion; ask for the minimum possible. Any new negative surprise is a reason to cancel — expensive shipping, paid shipping at all, service fee, packaging fee — embed every extra charge into the product price, never as a hidden extra.
28
+ **Apply when.** Auditing or building any checkout, signup-to-paid flow, or high-stakes form.
29
+ **The move.** (1) Minimum fields only. (2) No surprise fees — bake costs into the price. (3) Show security signals (even a lock icon with "Compra segura" — "Secure purchase" — lifts conversion). (4) Show an extra discount in the cart if you have one (anchoring works for you there). (5) Display the CNPJ (Brazilian company-registration number) — a real company converts more. (6) Show product photos even for digital products. (7) Split what you can to reduce barriers and cognitive load. (8) Use mobile-appropriate inputs (numeric keyboard for phone). (9) Yes, social proof in checkout works. (10) Test — different ICPs perceive risk differently.
30
+ **Visual.** Richard's own checkout applying the list at once: lock icon + "Site Seguro" in the header, four fields only (name, surname, e-mail, +55 phone with a numeric mask), a product thumbnail in the order summary, "Desconto 5% PIX" and free shipping on the receipt, a "Compre com confiança" trust list (100% money-back, support 7 days a week, 10,000+ sales) with a named testimonial, and the CNPJ in the footer — `../assets/1999584679247134761__1.jpg`
31
+ **Voice.** "I worked at PayPal literally designing checkouts for the biggest e-commerces and brands in Brazil. Hundreds of them."
32
+ **Source.** [@richardrx · 2025-12-12](https://x.com/richardrx/status/1999584679247134761)
33
+
34
+ ## 97% of visitors buy nothing — the leaks are known and fixable
35
+ **Principle.** Cart abandonment reasons are mapped and mostly design-fixable: late extra costs (49%), forced account creation (24%), slow delivery (19%), complicated checkout (18%), distrust of the site (17%), unclear price (17%), site errors (12%), bad return policy (11%).
36
+ **Apply when.** Diagnosing why traffic isn't converting to purchase.
37
+ **The move.** Treat this as a checklist: eliminate late costs, allow guest checkout, show delivery time early, simplify checkout, add trust signals, show total price upfront, test for errors, publish return policy. Amazon shows international products with "no additional costs after" — do the same.
38
+ **Voice.** "You can frame this as winning new conversions, or as better capturing what you're losing today."
39
+ **Source.** [@richardrx · 2025-12-09](https://x.com/richardrx/status/1998432350842016222)
@@ -2,6 +2,13 @@
2
2
 
3
3
  > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
4
4
 
5
+ ## The funnel leaks at three points — diagnose which before fixing
6
+ **Principle.** The three most common SaaS funnel holes for Brazilian founders: (1) cancel in month 1–2 → onboarding missing or LP promised the wrong thing (brought off-ICP users); the first is a product problem (shorten path to value), the second marketing (tighten the promise). (2) Many trials, few paid → paywall at the wrong moment or a broken value ladder. (3) Many visits, few signups → confused ICP and/or generic value proposition — but check the acquisition source first; wrong traffic can't be saved by copy.
7
+ **Apply when.** Triage where the funnel is leaking.
8
+ **The move.** Match symptom to owner: month-1 churn → activation/expectation; trial-no-convert → paywall timing/value ladder; visit-no-signup → ICP/positioning/traffic source. These mix — a clear ICP + good offer first, then an experience aligned to the promise.
9
+ **Evidence.** Kyle Poyar/ChartMogul+ProductLed (Jan): median free-to-paid 8%; trial-without-card good 4–6%, great 10–15%; trial-with-card good 25–35% (US).
10
+ **Source.** [@richardrx · 2026-08-05](https://x.com/richardrx/status/2085056354360729949)
11
+
5
12
  ## Churn and payback are one problem, measured in two places
6
13
  **Principle.** Churn and payback look like two problems (often with different owners) but are the same one — both decided in the user's first session, in the gap between entering and feeling the product works.
7
14
  **Apply when.** You're fixing churn at the cancel screen and chasing cheaper CAC in the ad manager at the same time.
@@ -58,9 +65,27 @@
58
65
  **Voice.** "On the dashboard it looks like a missing feature; it was a mismatch between your discourse and their understanding."
59
66
  **Source.** [@richardrx · 2026-04-08](https://x.com/richardrx/status/2041829519611371727)
60
67
 
68
+ ## Retention is raising the cost of leaving day after day — iFood's behavioral lock-in
69
+ **Principle.** iFood isn't just a business model — it's Brazil's most sophisticated behavioral lock-in. Each layer (delivery, data, credit, card) raises the psychological and operational cost of leaving: sunk-cost effect plus ecosystem dependency. The restaurant doesn't stay because iFood is good; it stays because leaving got too expensive. Retention isn't a feature — it's the accumulated cost of exit.
70
+ **Apply when.** Designing long-term retention/lock-in at any scale.
71
+ **The move.** Learn from the mechanism, ethically: every layer of value (data history, integrations, financial products, workflow embedding) makes leaving more expensive. The design goal isn't just "satisfy" — it's to increase the cost of leaving over time.
72
+ **Source.** [@richardrx · 2026-03-27](https://x.com/richardrx/status/2037543117612630126)
73
+
74
+ ## Churn math: restructured onboarding can preserve R$4.8k MRR from an existing base
75
+ **Principle.** 6% churn on 900 users at R$300 ARPU is 54 cancellations, or R$16.2k MRR, leaving each month. Restructured onboarding (contextual welcome + empty state + activation checklist) cut cancellations by ~30%: about 16 accounts retained, preserving R$4.8k MRR — a R$57.6k ARR run-rate or R$52.8k over the post's stated 11-month average lifetime. No new traffic, no new feature.
76
+ **Apply when.** Justifying onboarding investment to a numbers-driven founder.
77
+ **The move.** Keep the units explicit: monthly cancellations = base × monthly churn; prevented cancellations = cancellations × relative reduction; recovered MRR = prevented cancellations × ARPU; ARR run-rate = recovered MRR × 12. For cohort value instead, multiply recovered MRR by the stated average lifetime in months. Lower churn also raises valuation because every growth action operates with more margin.
78
+ **Source.** [@richardrx · 2026-03-19](https://x.com/richardrx/status/2034571753263939621)
79
+
61
80
  ## Engineer addiction like a game so CS isn't a churn tax
62
81
  **Principle.** Customer Success is the tax you pay for a non-addictive product — if you need an army of CSMs to stop cancellations, the product failed. Your real competitor isn't another startup; it's boredom, and boredom has infinite CAC. The CNPJ buying your SaaS is the same brain that plays Candy Crush; reward neuroscience is identical. Win retention across three game-design phases.
63
82
  **Apply when.** Diagnose by behavior: dropout at minutes 2–8 of onboarding = Phase 1; ~1.3 logins/week when it should be 4x = Phase 2; one departing employee kills the whole account = Phase 3. LTV:CAC below 3:1 means you're funding a product that can't stand organically.
64
83
  **The move.** **Phase 1 — Time-to-value vs. cognitive load:** ditch the setup wizard (asking work before delivering value reads as hostile territory in 10 seconds); use progressive disclosure, let users create and see results before asking for email/card. Mechanism: Zeigarnik effect (incomplete-loop tension) + endowment effect (people value 3x more what they helped build). Empty states must sell the dream — never show "0 data" or blank templates; populate a demo simulating day-30 usage. **Phase 2 — Habit loop / retention as biology:** passive software that only reacts is a failure to build dependency; ship proactive variable rewards. The mesolimbic reward system releases dopamine on anticipation, not the reward itself; predictable rewards (monthly report) build tolerance, variable ones ("we detected a positive anomaly yesterday") keep the loop alive. Convert vanity metrics into loss-aversion triggers: "Your team broke a record and you haven't seen it" + temporal data scarcity ("sync in 24h or lose the weekly benchmark"). **Phase 3 — Defensive moat:** single-player products die when the champion leaves — you built dependence on a person, not the org. Build multiplayer mode + data debt via social switching cost + network effects. Make User A's work block/depend on User B; reports needing multi-stakeholder approval; dashboards aggregating 3 departments. When quitting requires an alignment meeting across Sales, Ops and Finance, you reach negative churn by bureaucratic inertia; accumulated datasets add organizational endowment effect.
65
84
  **Voice.** "Stop blaming the customer. Your product is boring. And in the attention game, boring is bankruptcy."
66
85
  **Source.** [@richardrx · 2026-01-30](https://x.com/richardrx/status/2017274698699067466)
86
+
87
+ ## The 3 biggest churn reasons — and the fix for each
88
+ **Principle.** Most churn traces to three causes, each with a distinct fix. (1) Bad onboarding → gradual guided immersion to what users value most, a Zeigarnik progress bar (incompleteness nags), and targeted tooltips on unexplored features. (2) Missing perceived value → show user ROI in a simple dashboard (Grammarly shows words helped), promote feature discovery continuously, build community. (3) Hard/confusing interface → fix via a proper product design project.
89
+ **Apply when.** Churn is high and you don't know which of the three it is.
90
+ **The move.** Diagnose first: users who never reach value (activation) vs users who reached it and still left (perceived value) vs users who struggled (interface). Each has a different owner and a different fix — don't treat all churn as one problem.
91
+ **Source.** [@richardrx · 2025-12-17](https://x.com/richardrx/status/2001408166404530231)
@@ -2,6 +2,18 @@
2
2
 
3
3
  > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
4
4
 
5
+ ## Performance is conversion: 31% better LCP → +8% sales (Vodafone A/B)
6
+ **Principle.** You can raise conversion before opening Figma — web performance is a conversion lever, not an engineering nicety. Vodafone Italy A/B tested web-vitals optimization (LCP 31% better than control, same offer/creative/screen, 100k clicks and 34k visits/day per variant, paid traffic): +8% sales, +15% lead-to-visit, +11% cart-to-visit.
7
+ **Apply when.** Founders separate "conversion work" from performance work.
8
+ **The move.** Treat LCP/web vitals as a conversion experiment with the same rigor as copy tests — especially on paid traffic where every bounce is paid for.
9
+ **Source.** [@richardrx · 2026-08-04](https://x.com/richardrx/status/2084589988843299217)
10
+
11
+ ## Compliments aren't validation — "what's missing for you to PIX now?" is
12
+ **Principle.** Everyone loves your idea, nobody bought. Compliments are free and worth nothing (like your freemium). The simplest validation test: try to sell. If you can't close inside your ICP, ask directly: "Falta o que pra você fazer o PIX agora?" ("What's missing for you to send the PIX instant payment right now?") The pause reveals the truth — either the real objection (your build list) or excuses (the "loved it" was just politeness). Follow up: "If it had that, would you pay now?" Then do 20 sales this way.
13
+ **Apply when.** Collecting praise but no revenue.
14
+ **The move.** Sell before building. Richard sold 20 subscriptions off a gray clickable wireframe — the QR code wasn't even real. Nobody said "paint the wireframe"; they asked for invoices and a second mechanic login. Those doubts became sales arguments and FAQ items. The gray was enough to prove the only thing that mattered: people with the pain and in a hurry to pay. Design came after, to scale what conversation already proved sells.
15
+ **Source.** [@richardrx · 2026-07-07](https://x.com/richardrx/status/2074539418266812580) and [@richardrx · 2026-06-24](https://x.com/richardrx/status/2069743203863962080)
16
+
5
17
  ## "Paint the button" is judging the last line of a long cascade
6
18
  **Principle.** The visual layer of a landing page is the tip of a cascade that begins at the ICP — so "make it more colorful" critiques the *end* of a process as if it were the start.
7
19
  **Apply when.** Gathering or acting on LP feedback, or reaching for button color first.
@@ -17,6 +29,12 @@
17
29
  **Voice.** "Scaling budget into cold traffic works like an honesty test: it shows how much of your conversion is your page and how much is borrowed trust."
18
30
  **Source.** [@richardrx · 2026-06-08](https://x.com/richardrx/status/2063972594223661127)
19
31
 
32
+ ## Test hero comprehension with a stranger from your ICP
33
+ **Principle.** The cheapest usability test nobody runs: show your LP hero to one person for 5 seconds, take it away, ask "What does this product do? For whom?" If they can't answer, the hero failed — no matter how pretty it is. In those seconds the brain asks three questions, almost in order: what is this → is this for me → why should I care now. The mechanism is cognitive load: every second spent decoding what you do is a second closer to giving up — clarity beats cleverness at the top of the funnel, always.
34
+ **Apply when.** A hero trades clarity for "creativity" ("Revolutionize your workflow" doesn't say what it does; "The definitive productivity platform" doesn't say for whom).
35
+ **The move.** A hero needs: (1) a headline saying what the product does, in the customer's language, not internal jargon; (2) a subheadline nailing the ICP and the concrete result; (3) real visual proof — a screenshot of the product working, not a generic smiling illustration; (4) a specific CTA; (5) immediate social proof (a logo or a number) above the fold. Specificity sells: "Controle de comandas pra oficina mecânica" ("Work-order control for auto repair shops") beats "Software de gestão" ("Management software"). If you covered everything on the page except the hero, could a stranger from your ICP say what you sell in 5 seconds? Read with "Pass the 5-second test — lead with the problem, not the feature" (2026-05-01): that post argues for a pain-led headline, this one for a what-it-does headline — both demand the what / for whom / why-now answers inside 5 seconds.
36
+ **Source.** [@richardrx · 2026-05-29](https://x.com/richardrx/status/2060409264683044995)
37
+
20
38
  ## Write the CTA microcopy, not the button color
21
39
  **Principle.** The CTA label moves conversion far more than button color or shape — it's the last thing the user reads before deciding, so it must reduce the mental effort of simulating what happens next.
22
40
  **Apply when.** A technical founder is A/B testing button colors for weeks over a 0.3% (non-significant) delta while the label still says "Sign up" with no click trigger.
@@ -98,7 +116,7 @@
98
116
  **Apply when.** You're choosing between a page that wins design compliments and one built to convert.
99
117
  **The move.** Engineer the converting pattern even if the artist in you cringes: (1) one obvious attention point — eyes go where they must; (2) a high-contrast CTA with redundancy; (3) a clear promise delivering easily-perceived value; (4) guarantee, social proof, and a free element to reduce risk aversion; (5) organic images by the second fold to back the offer and build trust.
100
118
  **Evidence.** The analyzed page (quoted): 100 visits → 19 signups, a 19% conversion rate.
101
- **Visual.** An "ugly-but-converts" waterproofing LP: urgency bar, high-contrast orange CTAs, a short above-the-fold form, stat row (12,500+ / 4.9★ / lifetime warranty), and trust badges — `../assets/2023777916673220817__q__1.jpg`
119
+ **Visual.** An "ugly-but-converts" waterproofing LP: urgency bar, high-contrast orange CTAs, a short above-the-fold form, stat row (12,500+ / 4.9★ / 20+ yrs / 100%), and a trust-badge strip (incl. lifetime warranty) — `../assets/2023777916673220817__q__1.jpg`
102
120
  **Voice.** "Some LPs go after compliments, others go after conversion."
103
121
  **Source.** [@richardrx · 2026-02-17](https://x.com/richardrx/status/2023777916673220817)
104
122
 
@@ -130,3 +148,36 @@ Awareness → angle / hero / proof:
130
148
  **Visual.** Schwartz's 5 awareness stages as a rising ramp (Unaware → Problem → Solution → Product → Most Aware) — `../assets/2011427153133351046__3.jpg`; plus the demographic-twins diagram (Charles vs Ozzy, identical on paper) — `../assets/2011427153133351046__2.jpg`
131
149
  **Voice.** "There's no 'conversion rate' in a vacuum. There's contextualized conversion."
132
150
  **Source.** [@richardrx · 2026-01-14](https://x.com/richardrx/status/2011427153133351046)
151
+
152
+ ## The 2026 landing page checklist
153
+ **Principle.** An all-in-one checklist for a converting LP — @namyakhann's (Supafast) list, which Richard translated and endorsed in full: Hero (1 clear promise / 1 specific audience / 1 exact-action CTA / show-don't-explain visual / trust seal above the fold). Copy (headline <10 words, benefit before feature, customer language, one central transformation, scannable in 5s). Social proof (logos if you have names, metrics if you have traction, specific result testimonials, zero generic praise). Structure (Hero → Pain → Solution → Proof → CTA; max 3 feature sections; FAQ kills top 5 objections; CTA repeated 2–3x). Technical (<3s load, real mobile-first, single-scroll flow).
154
+ **Apply when.** Auditing or building any LP.
155
+ **The move.** Run the checklist top to bottom. Mantra: Clarity > creativity. Result > feature. Speed > polish. If it doesn't convert in 2026, it's not your traffic — it's your page.
156
+ **Source.** [@richardrx · 2026-01-02](https://x.com/richardrx/status/2007216871607771303)
157
+
158
+ ## Click triggers: one line of risk-reducing microcopy next to the CTA
159
+ **Principle.** A single line of text reducing perceived risk can save conversion — in CRO these are "click triggers" (marketing calls it objection-breaking): "Lifetime guarantee," "Free shipping," "7 days free, no card." It's certainty placed on top of a known ICP doubt.
160
+ **Apply when.** Users hesitate right before the CTA.
161
+ **The move.** Find the real objections by talking to customers and reading complaint pages (ReclameAqui) and app-store comments; then test which click trigger performs best. No mystery, just work — and it works.
162
+ **Source.** [@richardrx · 2025-12-19](https://x.com/richardrx/status/2002076748112875558)
163
+
164
+ ## Founder LP guide: platform doesn't matter, load time does; proof must outweigh the promise
165
+ **Principle.** Profits are more sensitive to conversions than to costs, and the landing page is often the first gate between a founder's product and its users. The platform matters less than speed, clarity, contrast, proof, and direct action.
166
+ **Apply when.** Building a first LP cheaply.
167
+ **The move.** Follow five rules: (1) use any platform, but deliver content fast and target an "A" on GTMetrix; (2) lead with a short pain or clear benefit, then make the promise tangible in the subhead; (3) create visual contrast with what the ICP sees daily; (4) ensure proof ≥ promise, moving from strong/shallow at the top to denser evidence below; (5) use direct CTAs tied to the outcome about every 1.5 sections.
168
+ **Voice.** "Nobody wants to know about your product's features — they want what it generates or the pain it kills. Not 6GB of space, 3,000 songs in your pocket."
169
+ **Source.** [@richardrx · 2025-11-10](https://x.com/richardrx/status/1987842649261261240)
170
+
171
+ ## Match CTA microcopy to the funnel stage
172
+ **Principle.** Button text should change with the user's progress in the funnel — the verb matches the mental state at each stage. First interaction: "Descubra como funciona" ("See how it works"). Product page: "Quero esse produto" ("I want this product"). Checkout: "Finalizar minha compra" ("Complete my purchase"). Short (≤4 words), clear, directional. This discreet personalization raises perceived control, confidence, and conversion.
173
+ **Apply when.** One generic CTA label serves the whole journey.
174
+ **The move.** Audit every CTA against the stage it appears in; test stage-matched variants. Small adjustments, large results.
175
+ **Source.** [@richardrx · 2025-11-07](https://x.com/richardrx/status/1986836679953719632)
176
+
177
+ ## Real humans outconvert models — banner blindness explains why
178
+ **Principle.** Highrise, the 37signals CRM, tested homepage variants with different human figures; real users and actual team developers converted best on average — above stock-photo models. (37signals later became Basecamp.) Likely explanation: banner blindness — we learn to ignore what looks like advertising and give attention to what's organic or unusual.
179
+ **Apply when.** Choosing imagery for LPs and proof sections.
180
+ **The move.** Prefer real users/team over polished models; user-generated reviews and simple real photos often beat studio shots. Chinese sites exploit this at scale with gamified UGC.
181
+ **Evidence.** The stock-model / team-developer comparison is the post's. 37signals' own writeup of the test ([Signal v. Noise, "Behind the scenes: A/B testing part 3"](https://signalvnoise.com/posts/2991-behind-the-scenes-ab-testing-part-3-final)) photographed only real Highrise customers — no stock models, no staff — and found the specific person barely mattered: the lift came from the person-photo layout beating the long-form page.
182
+ **Visual.** The Highrise homepage test side by side — the illustrated "original design" vs the "person design" fronted by a real customer's photo and quote, marked +102.5% — `../assets/1985681720104903142__1.jpg`
183
+ **Source.** [@richardrx · 2025-11-04](https://x.com/richardrx/status/1985681720104903142)
@@ -0,0 +1,23 @@
1
+ # Dashboards & Data Visualization (Retention Surface)
2
+
3
+ > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Dashboards aren't reporting tools — they're retention surfaces. A good dashboard eliminates churn by delivering so much value the user feels the need to return.
4
+
5
+ ## Removing information creates room for direction — the dashboard should say what to do with the data
6
+ **Principle.** Good product design work is mostly *removing*: showing less and giving clarity to what remains, based on what the user needs on that screen. Removing information opens space for direction — the app stops just showing data and starts saying what to do with it. That's the actionable layer.
7
+ **Apply when.** A dashboard shows everything but guides nothing.
8
+ **The move.** Compare before/after: giant number fighting the chart below, tabs inside tabs, bars that tell nothing → chart that breathes, selected month popping, space for a card that warns "two installments end in August, save what's left over." Less on screen = shorter learning curve; a product that guides gives a reason to return — engagement becomes retention (+LTV).
9
+ **Source.** [@richardrx · 2026-07-10](https://x.com/richardrx/status/2075623473565647202)
10
+
11
+ ## A good dashboard informs at a glance — like a car dashboard, the user must focus on where they're going
12
+ **Principle.** A good dashboard is informative and effortless to read — the main KPI sits top-left (F-pattern), every element either earns its place or is noise. The goal isn't informing: it's eliminating churn and maximizing LTV through value so large the user feels the need to return.
13
+ **Apply when.** Designing or auditing any analytics/admin dashboard.
14
+ **The move.** (1) Define who it's for (ICP) — information without context is spam. (2) Everything not useful is noise — each extra line/card/icon is cognitive load unless indispensable for consuming the data. (3) F-pattern: main KPI top-left. (4) Attach meaning to data — "You generated 500 tickets" → "That's 15% above your monthly target"; use framing ("You're in the top 20%") for belonging/social proof. (5) Design for the empty state (good empty states, guide users to fill them). (6) Drive to action, not excess — an actionable panel beats a "complete" one (GA4 has everything, little usable). (7) Personalize by role — a CEO panel ≠ a marketing analyst panel.
15
+ **Visual.** An annotated repair-shop dashboard ("Quadro Geral") with seven callouts: 01 logo, 02 sidebar navigation, 03 the main revenue KPI (R$57,257, ↗6.2% vs last month) top-left, 04 average ticket, 05 the Max / 12-month / 3-month / 30-day range tabs, 06 a single primary action ("Adicionar OS"), 07 the composition card's ⋮ options menu (personalize what the panel shows) — plus a revenue-composition donut, a 12-month revenue history and services / parts / outsourcing breakdown cards — `../assets/2000930776636940333__1.jpg`
16
+ **Voice.** "Information without context is spam."
17
+ **Source.** [@richardrx · 2025-12-16](https://x.com/richardrx/status/2000930776636940333)
18
+
19
+ ## Dashboards: not a pile of gauges — every extra indicator slows the scan for what's actionable
20
+ **Principle.** The original "dashboard" was a board on carriages that kept horse mud off the passengers; the first Ford T kept the design with just an ignition key and an ammeter, and gauges accumulated from there. That industrial-era aesthetic survives in luxury cars and watches — the "complications" on a Patek Philippe or a Pagani — where it's interesting; in a software dashboard it isn't. The more information on screen, the higher the cognitive load and the longer it takes to scan for what is important and actionable. A good dashboard is built around the business's main indicators.
21
+ **Apply when.** Stakeholders keep asking to add "just one more" KPI.
22
+ **The move.** Pick the KPI shortlist for the business type and leave the rest off the panel. E-commerce: conversion rate, average order value (AOV), CAC, customer lifetime value (CLV), cart-abandonment rate, ad return (ROAS/CPA). SaaS: MRR, churn, CAC, LTV, ARPU. Apps: DAU, MAU, retention rate, ARPU, app-store rating, engagement (session length, frequency), cost per install (CPI).
23
+ **Source.** [@richardrx · 2025-11-04](https://x.com/richardrx/status/1985828780838097317)
@@ -2,6 +2,13 @@
2
2
 
3
3
  > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
4
4
 
5
+ ## Duolingo's lesson: optimize the metric that moves DAU, not the borrowed mechanic
6
+ **Principle.** Duolingo copied game mechanics twice and failed both (a Gardenscapes moves-counter: neutral; a referral program copied from Uber: +3% because the reward excluded the best users). They stopped picking mechanics and modeled which number to move: bucketing users by engagement and simulating +2%/quarter for 3 years, CURR (current-user retention rate) had ~5x the impact of the next-best metric. Then gamification worked: CURR +21% over 4 years, daily churn of best users −40%+, DAU ×4.5. Leaderboards alone +17% total learning time and tripled highly-engaged learners — because they switched to competing with users of *similar prior-week engagement* (auto opt-in = default effect, no extra tasks).
7
+ **Apply when.** Adding gamification by copying a mechanic instead of finding your CURR.
8
+ **The move.** Find the single retention metric that compounds your DAU before choosing mechanics. PBL (points, badges, leaderboards) is the free sample — there are ~290 gamification mechanics. Useful three: competition (defined start/middle/end missions), progress bars as trajectory achievement (not just onboarding), engagement-unlocked content (a forecast panel opens only after 30 real entries — blocked as a ladder, not a paywall).
9
+ **Visual.** Duolingo's DAU curve from mid-2018 to mid-2022, marked "Started working on CURR" at the inflection, with a 4.5× arrow from there to the top right — `../assets/2081714430811730162__1.jpg`
10
+ **Source.** [@richardrx · 2026-07-27](https://x.com/richardrx/status/2081714430811730162)
11
+
5
12
  ## Don't mistake signups for traction
6
13
  **Principle.** Signups are the cheapest action a user takes, so they measure curiosity, not value — especially in freemium. Real growth is whether people come back and do the action that delivers value.
7
14
  **Apply when.** A rising signup curve on the dashboard feels like proof of traction, particularly under a freemium model.
@@ -29,3 +36,9 @@
29
36
  **The move.** Do the churn→LTV math: at 25% monthly churn on 1,000 users you must add 250 new users/month just to break even — kill paid traffic and the product dies in ~4 months. Then improve retention without Figma: define the Aha Moment, measure time-to-value (TTV) from signup to it, ask "how do I deliver this faster?", break it into micro-wins if you can't, then test, measure, repeat.
30
37
  **Evidence.** Finance SaaS, ARPU R$120: cutting churn 5 points (25%→20%) is +R$72,000/year in cash, with no price change and no extra acquisition.
31
38
  **Source.** [@richardrx · 2026-04-06](https://x.com/richardrx/status/2041184077106004289)
39
+
40
+ ## Nine product metrics, each telling one thing
41
+ **Principle.** ARR = size (not necessarily health). Burn rate = risk (time until death). CAC = efficiency (but obsessing over lowering it can worsen conversion with a less-qualified cohort). DAU/MAU = engagement (<20% = bad sign). LTV = product (does the customer see value?). Churn = fit (user doesn't understand or see value → cancels). NRR = real growth (>100% = good). Gross margin = model (<70% in SaaS = problem, except AI wrappers). Runway = survival (<12 months = danger). Metrics are like a blood panel — one bad reading is critical, but all-good is real health.
42
+ **Apply when.** A founder fixates on one number or conflates what each metric diagnoses.
43
+ **The move.** Use each metric as a diagnostic for its matching layer, then read the full panel before prescribing a fix: ARR alone cannot prove health, low CAC can hide a weak cohort, and strong growth without margin or runway can still be fatal. Treat one bad result as a specific warning and the bundle as the business's health check.
44
+ **Source.** [@richardrx · 2026-01-12](https://x.com/richardrx/status/2010675817483817384)
@@ -2,6 +2,12 @@
2
2
 
3
3
  > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
4
4
 
5
+ ## Map the whole journey to value — then fix the biggest drop, not the first step
6
+ **Principle.** Founders rush to the top of the funnel when activation falls, but the leak is usually in the middle — the step where effort is already high and the user hasn't seen proof it's worth it. Method: (1) Define what "value" is (the first moment the user gets the promised result — measurable, visible in data). (2) List every step between signup and that value (every screen, click, wait, field — always more than you remember). (3) Measure drop per step; find the steepest fall. (4) Fix the biggest drop first — that's where the money is. (5) Diagnose why: friction (cut), confusion (direct attention), ordering (deliver value before asking effort).
7
+ **Apply when.** Activation is low and you're not sure where the leak is.
8
+ **The move.** Count the steps before first value — each is a chance to quit. High activation lives in the shortest path to first result, not the most complete product before it. Almost every founder has this map in their head and never on paper; the head version always looks shorter.
9
+ **Source.** [@richardrx · 2026-07-08](https://x.com/richardrx/status/2074814716824731651)
10
+
5
11
  ## An onboarding video welcomes — it doesn't teach
6
12
  **Principle.** A good onboarding video isn't a manual (nobody reads their car's or iPhone's). It welcomes, builds connection, shows the product at a glance, and points to where value comes fastest.
7
13
  **Apply when.** Designing first-run onboarding or a welcome video.
@@ -97,7 +103,7 @@
97
103
  **Apply when.** You're weighing an 8-field signup form against email + password.
98
104
  **The move.** Default to the minimal form and let qualification happen later, inside the product, from real behavior. Deciding where to add versus remove friction is what separates a product that grows from one that spins its wheels — but it's contextual ("it depends").
99
105
  **Evidence.** Same product, two founders: 8-field form (name, email, company, role, phone, segment, team size, how-did-you-hear) → 12% signup rate; email + password only → 34%.
100
- **Visual.** Annotated onboarding step (DevNoodles): an ICP/intent question flagged "Zeigarnik effect" (the step progress dots) and a B2C/B2B card selector flagged "Progress effect" — showing where each bias is engineered into the flow. — `../assets/2042558822825239030__1.jpg`
106
+ **Visual.** Annotated onboarding step (DevNoodles): an ICP/intent question flagged "Zeigarnik effect" (the step progress dots) and a B2C/B2B card selector flagged "Default effect" (the B2C card is pre-badged "Mais comum") — showing where each bias is engineered into the flow. — `../assets/2042558822825239030__1.jpg`
101
107
  **Source.** [@richardrx · 2026-04-10](https://x.com/richardrx/status/2042558822825239030)
102
108
 
103
109
  ## Celebrate the activation moment, don't just confirm it
@@ -2,6 +2,20 @@
2
2
 
3
3
  > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
4
4
 
5
+ ## Use a disfluent font for genuine deals — and name tiers for the mix you want
6
+ **Principle.** A uniformly polished pricing page can be easy to scan yet weak at selling. For a genuinely favorable promotion, a disfluent (ugly) font on the price can make people process the number more deeply. Tier labels can change purchase incidence and which tier buyers choose — and those effects can run in opposite directions.
7
+ **Apply when.** Pricing looks clean but plan distribution has been flat for months, or every company's pricing cards feel interchangeable.
8
+ **The move.** Keep the rest of the page legible, but test a deliberately ugly or disfluent font on a genuine promotional price — never make the whole UI ugly. Choose labels by the outcome: in Wang et al.'s experiments, a superior-sounding metal ladder (Silver/Gold/Platinum) reduced choice deferral but moved the mix down, while an inferior-sounding ladder (Bronze/Silver/Gold) moved it toward higher-priced tiers. Richard applies that result to functional names such as Basic/Standard/Essential; treat that mapping as a hypothesis and measure purchase incidence and initial tier selection separately. Read with "Build a single value axis, then tune the decoy's distance to your target plan" (2026-02-02): that post recommends aspirational Starbucks-style tier names to lift the brand, this one prices that choice — aspirational names sell more units, unglamorous ones sell more high tier, so pick by the metric you are optimizing.
9
+ **Evidence.** Motyka et al. (2016) found that disfluent fonts on price promotions prompt deeper processing and increase purchase behavior when the offer is a deal, even though people like the display less. Across five experiments (1,954 participants), Wang et al. (2024) found superior-sounding labels increased purchase incidence but shifted choices toward cheaper options; inferior-sounding labels increased higher-priced choices.
10
+ **Visual.** Three pricing screenshots from the quoted post by @pankajstwt — 3-column Basic/Starter/Pro with near-identical includes; 2-column Launch/Scale; one-time Starter/Premium/Pro plus Ultimate — clean generic templates Richard challenges the reader to tell apart: `../assets/2092692547244007852__q__1.jpg`, `../assets/2092692547244007852__q__2.jpg`, `../assets/2092692547244007852__q__3.jpg`
11
+ **Source.** [@richardrx · 2026-08-26](https://x.com/richardrx/status/2092692547244007852)
12
+
13
+ ## Price from cost+margin floor and value ceiling — never tarot or competitor-minus-20%
14
+ **Principle.** Two calculations give your floor and ceiling. Floor = cost to serve + target margin (infra, support, tools, tokens; if R$10/account and 80% margin, floor is R$50). But two traps: price too low signals low quality before use, and CAC math can eat the margin (CAC R$100 + margin R$40/mo = 2.5-month payback; churn at month 3 = you worked 3 months for R$20). Ceiling = reference value — what the client pays today to solve it their way (Excel + 1.5h/day of admin; or the loss they absorb by not solving).
15
+ **Apply when.** Setting or revisiting SaaS pricing.
16
+ **The move.** Quantify the delta in money for them: an ICP auto repair shop loses ~12 quotes/month to no follow-up × R$800 ticket × 30% margin × recovering 1/3 → R$3,200/mo revenue, R$960/mo profit. Then the sliding scale: value easy to prove, buyer convinced, little competition → move the price up; value hard to prove, skeptical buyer, a competitor on every corner → settle for ~10% of the value generated and be grateful. Commodity features (work orders, scheduling, reports) don't sustain price — they just put you in the same comparison table.
17
+ **Source.** [@richardrx · 2026-08-03](https://x.com/richardrx/status/2084250609687884144)
18
+
5
19
  ## The freemium trap, in numbers: higher conversion, far lower cash
6
20
  **Principle.** A free plan lifts signup conversion but can crush the economics — the higher top-of-funnel number hides a worse business.
7
21
  **Apply when.** You're tempted by freemium's better conversion rate.
@@ -23,6 +37,19 @@
23
37
  **Voice.** "Charging more without seeming to be worth more is just raising the price of rejection."
24
38
  **Source.** [@richardrx · 2026-06-29](https://x.com/richardrx/status/2071634185228329219)
25
39
 
40
+ ## 1% on price beats 1% on acquisition — you raise prices too little and too late
41
+ **Principle.** A 1% price improvement drives ~8–11% more profit (ProfitWell) on typical SaaS margins, while a 1% acquisition improvement yields ~2%. Yet 70% of executives rank acquisition as the most important growth lever — the one that pays least. Price is left untouched because of loss aversion (fear of losing what you have screams louder than the chance to gain).
42
+ **Apply when.** It's been >12 months since a price change and the product improved meanwhile.
43
+ **The move.** Test the new price only on new customers, don't touch the base. If the conversion drop is offset by the higher ticket, it wins. Users who pay more churn less. Raise gradually, anchored in value — communicate what improved, never a naked increase. Forget A/B testing price (you lack volume); segment and run willingness-to-pay research instead.
44
+ **Voice.** "If 1% on price pays five times more than 1% on acquisition, why is nearly all your energy at the top of the funnel?"
45
+ **Source.** [@richardrx · 2026-06-03](https://x.com/richardrx/status/2062127283977019757)
46
+
47
+ ## Competing on price is adverse selection — you filter in the worst client
48
+ **Principle.** Price-led copycats attract bargain hunters: they enter because you're cheapest and leave the second someone is R$1 cheaper. High churn, zero loyalty, most support tickets. Price as bait is a filter for the client you least want. Better: Kawasaki's "Be a baker, not an eater" — bake your own pie via niche (CRM for facial-aesthetics clinics, not another CRM) and charge 5x with no comparison. Use the giant's weight against it (jiu-jitsu): big players' blind spots are in public complaints — ReclameAqui, app stores, Google Places, communities, FB/WhatsApp groups, niche sites. Each complainer represents ~26 equally unhappy silent ones.
49
+ **Apply when.** Tempted to differentiate purely on being cheaper than a big player.
50
+ **The move.** Mine complaints for the niche, angle, vocabulary, pain, and promise for your LP. Accept you'll be copied — storefronts look equal but the model underneath (your niche, angle, economics) isn't. McDonald's is a real-estate company dressed as a burger joint; BK is royalties. Same storefront, different machine.
51
+ **Source.** [@richardrx · 2026-06-03](https://x.com/richardrx/status/2062314549483589691)
52
+
26
53
  ## Make the middle plan the one you actually want to sell
27
54
  **Principle.** Each plan has a behavioral job, not just a price; the plan you most want to sell should sit in the middle, flanked by a decoy below and an anchor above.
28
55
  **Apply when.** Building or auditing a SaaS pricing page, especially if you copied competitors without assigning each tier a role.
@@ -70,18 +97,18 @@
70
97
  **Voice.** "Pricing success depends not just on what you deliver, but on the order the brain is led to process the value."
71
98
  **Source.** [@richardrx · 2026-03-05](https://x.com/richardrx/status/2029623167900061970)
72
99
 
73
- ## Build a single value axis, then tune the decoy's distance to your target plan
74
- **Principle.** A plan ladder must read as one clear progression of value; mixing quantitative and qualitative axes muddles it, and where you place the decoy's price decides which plan looks like the deal.
75
- **Apply when.** Naming and pricing tiers, or the "value staircase" between your plans isn't obvious to users.
76
- **The move.** Pick one progression — quantitative (rising credits/users) or qualitative (24/7 human support, special features) — rather than blending both. Borrow Starbucks-style naming (Tall/Grande/Venti) so every tier sounds good and lifts the brand. Then position the decoy: place it near the most expensive plan and the expensive plan looks cheap; place it near the cheapest and the decoy itself becomes the most attractive option.
77
- **Visual.** Decorative 3D price-tag illustration — no data.
78
- **Source.** [@richardrx · 2026-02-02](https://x.com/richardrx/status/2018357024543715480)
79
-
80
100
  ## Engineer the pricing page with Good-Better-Best and control the comparison
81
101
  **Principle.** Lost LTV is rarely about price — it's analysis paralysis from a missing choice architecture. The brain is lazy and judges by relative comparison (priming + anchoring), so if you don't design the anchor, users compare you to "nothing" or to the cheapest competitor.
82
102
  **Apply when.** Designing or fixing a pricing page; conversions die at the final step despite strong CAC spend.
83
103
  **The move.** Use a Good-Better-Best (GBB) structure: **Good** = a stripped entry plan that anchors a low price but is limited enough to make users feel pain and look up (never make it free — then everything above looks expensive). **Better** = your standard plan, the target for ~80% of buyers; price it closer to Good than to Best so users think "paying only ~20% more I get double?" **Best** = the value anchor that exists mainly to make Better look cheap (bicycle analogy: without the carbon-fiber Best, the carbon-wheel Better looks expensive). Golden rule: keep comparisons on one axis — don't pit "10,000 tokens" against "Priority Support"; prefer linear, ideally asymmetric, growth. Cap at 2–5 plans (6 = anxiety, paradox of choice). Then control which attributes you compare — your own "Brazil vs Paraguay" table — choosing indicators that favor your value thesis. Highlight Better with color/size/badges. "Stop making the user do the math — do the math for them."
84
104
  **Evidence.** Cites Briesch et al. (1997) and Mazumdar et al. (2005) on reference-price models, and Chernev (2015) on choice overload.
85
- **Visual.** Two mirrored BR-vs-PY indicator tables prove framing: swapping which metrics are shown flips which country "wins" — `../assets/2018693884449009956__1.jpg`, `../assets/2018693884449009956__2.jpg`. Four-tier mockup highlights a "Most Popular" target beside a high anchor (Hick's law / few options) — `../assets/2018693884449009956__4.jpg`
105
+ **Visual.** Two mirrored BR-vs-PY indicator tables prove framing: swapping which metrics are shown flips which country "wins" — `../assets/2018693884449009956__2.jpg`, `../assets/2018693884449009956__3.jpg`. Four-tier mockup highlights a "Most Popular" target beside a high anchor (Hick's law / few options) — `../assets/2018693884449009956__4.jpg`
86
106
  **Voice.** "Your pricing page is killing your LTV — and I can prove it."
87
107
  **Source.** [@richardrx · 2026-02-03](https://x.com/richardrx/status/2018693884449009956)
108
+
109
+ ## Build a single value axis, then tune the decoy's distance to your target plan
110
+ **Principle.** A plan ladder must read as one clear progression of value; mixing quantitative and qualitative axes muddles it, and where you place the decoy's price decides which plan looks like the deal.
111
+ **Apply when.** Naming and pricing tiers, or the "value staircase" between your plans isn't obvious to users.
112
+ **The move.** Pick one progression — quantitative (rising credits/users) or qualitative (24/7 human support, special features) — rather than blending both. Borrow Starbucks-style naming (Tall/Grande/Venti) so every tier sounds good and lifts the brand. Then position the decoy: place it near the most expensive plan and the expensive plan looks cheap; place it near the cheapest and the decoy itself becomes the most attractive option. Read with "Use a disfluent font for genuine deals — and name tiers for the mix you want" (2026-08-26): aspirational names lift purchase incidence, but unglamorous ones shift the mix toward higher-priced tiers.
113
+ **Visual.** Decorative 3D price-tag illustration — no data.
114
+ **Source.** [@richardrx · 2026-02-02](https://x.com/richardrx/status/2018357024543715480)
@@ -2,6 +2,43 @@
2
2
 
3
3
  > Curated, distilled wisdom from @richardrx ("Richard — Design for startups"), translated from Portuguese. Each entry is a reusable principle linked to its source post.
4
4
 
5
+ ## Feature requests from cancellations don't buy features
6
+ **Principle.** Three auto shops canceled RepareCar over missing boleto (bank-slip) issuance — request logged in Linear with name and date, 20+ in the same queue, oldest since June. But cancellation doesn't buy a feature: the ICP profile is defined, and boleto sits in a deliberately-not-doing package. Support is semi-automated (AI triages, human on novel questions, both open Linear tickets; a daily Claude task prioritizes). Bugs jump the queue; anything new defaults to parking lot.
7
+ **Apply when.** Cancelling customers' feature requests pressure the roadmap.
8
+ **The move.** Log each request with the customer and date, aggregate demand, then prioritize by bug severity, ICP fit, and strategy — not by the latest cancellation. Default net-new work to the parking lot. When asked for timing, communicate the real queue ("20 requests are ahead of yours") instead of making a false promise.
9
+ **Source.** [@richardrx · 2026-08-10](https://x.com/richardrx/status/2086931878251057479)
10
+
11
+ ## Building is the comfort zone; distribution is the game
12
+ **Principle.** Founders choose to build because selling hurts — Richard spent 90% of his time perfecting a delivery product one year before iFood existed; it died beautiful. Humane raised ~US$240M, ex-Apple founders, gorgeous hardware; returns outpaced sales by summer 2024 and HP took the assets for US$116M. In survival phase you do both jobs and almost always pick building — your comfort zone — pretending the next feature will make selling easier. Exercise: how many months of runway does your next feature cost?
13
+ **Apply when.** Roadmap keeps growing while distribution is untested.
14
+ **The move.** Before every roadmap item in the survival phase, ask the post's question — how many months of runway does this feature cost? — and whether it actually makes selling easier or just postpones selling. If the honest answer is "it's the comfortable thing to build," spend that time on the job that hurts: selling.
15
+ **Source.** [@richardrx · 2026-07-21](https://x.com/richardrx/status/2079575881115226453)
16
+
17
+ ## 94% of features are filler — Pendo's data and what to do about it
18
+ **Principle.** Pendo's analysis across ~2,500 companies' apps found roughly 6% feature adoption in the average product; even top-10% products reached only 15.6%. That leaves about 94% rarely or never used in the average product (84.4% even in the top decile), creating low activation, churn, a larger attack surface, and higher sustaining cost/complexity. Some features sell without being used, but that doesn't explain the gap.
19
+ **Apply when.** Auditing a bloated roadmap or justifying a feature purge.
20
+ **The move.** Classify every feature by usage correlation: A. Core (the 6% carrying the product; 15% if you're top-10%), B. Strategic (contributes to sales), C. Discard. Then shrink the product based on use and/or cash generation.
21
+ **Source.** [@richardrx · 2026-07-17](https://x.com/richardrx/status/2078079228717764886)
22
+
23
+ ## PMF is step 8 in a 10-step sequence — founders start there too early
24
+ **Principle.** Sequence: (1) Define the ICP — does it really exist, or is it who you wish it were? (2) Surface the ICP's pains and desires — real? verified where, with how many? (3) Understand awareness level — knows the pain? the solution? yours? (4) Slice niche/sub-niche — their particularities, do they exclude each other? (5) Size TAM of niche and sub — enough market, and does enough remain after niching? (6) Actively decide who the solution serves — can you stand out there? (7) Validate the thesis — the ICP's pain solved in a way that pays; are they paying? (8) Reach PMF — does the product stick? do users recommend it unprompted? does the business sustain itself without you pushing? (9) Fix inefficiencies in acquisition, activation, retention — always leaks; measured where? (10) Scale.
25
+ **Apply when.** A founder says they "want PMF" without the groundwork.
26
+ **The move.** Work the sequence in order and require evidence at each gate: a verified ICP and pain, a viable niche/TAM, paying thesis validation, then PMF. Only after measuring and fixing acquisition, activation, and retention leaks should you scale.
27
+ **Source.** [@richardrx · 2026-07-09](https://x.com/richardrx/status/2075192130184630688)
28
+
29
+ ## Feature creep ("fiturite") is a business cost, not just a UX one
30
+ **Principle.** The Homer Simpson car problem: every unsatisfied user request implemented as a feature eventually makes the product hard to operate, steepens the learning curve, and worsens experience through cognitive overload and choice paradox. It's bad for the business too — you spend more on dev for features serving few users, more on maintenance, eventually whole teams for barely-needed areas. Prune based on: who are our most strategic users, what are they using, what's unused that I can abstract, what aligns with the vision.
31
+ **Apply when.** A product keeps growing features without a subtraction ritual.
32
+ **The move.** Treat pruning like a cost line: grass grows by itself, you have to mow. Look for low-usage features serving low-paying/high-churn subniches and cut them to serve better those who pay more and stay longer.
33
+ **Source.** [@richardrx · 2025-11-03](https://x.com/richardrx/status/1985329704312709254) and [@richardrx · 2026-07-06](https://x.com/richardrx/status/2074118439321350163)
34
+
35
+ ## Maturing the product means doing the same thing better, not adding power-user features
36
+ **Principle.** Technical founders keep densifying the product for heavy users, making it expensive, complex, and hard for the average user — a Boeing 747 cockpit. Maturing means doing better what the product already does: smoother flows, bug fixes, attention direction. Hidden risk: a power-user product has a smaller top of funnel, so you must charge more — you changed markets (TAM/SAM changed) and price must follow. The founder then reads "product is bad" when really ICP isn't adjusted. Adjust copy (more executive, less tool-like), visuals (show the result, less product internals), and detail care (high-paying ICP tolerates AI-slop design less).
37
+ **Apply when.** The product keeps getting denser and conversion falls.
38
+ **The move.** Stop adding depth by default; smooth the core flows, fix bugs, and direct attention first. If the product is deliberately moving upmarket, recalculate TAM/SAM and price, then align the ICP, copy, visuals, and detail quality with that smaller, higher-value market.
39
+ **Evidence.** Christoph Janz's five paths to $100M — from the elephant (few customers paying a lot) to the fly (millions paying little) — all work; the problem is becoming an elephant without noticing and still charging mouse prices.
40
+ **Source.** [@richardrx · 2026-07-02](https://x.com/richardrx/status/2072718071060447691)
41
+
5
42
  ## Run every feature through a two-layer "Swiss Knife filter" before building
6
43
  **Principle.** A feature you ship stays forever and charges rent forever, so the right question isn't "is this good?" but "does it deserve the permanent cost it imposes on the product?"
7
44
  **Apply when.** A roadmap item feels appealing but nobody applied a filter before committing to build.
@@ -44,7 +44,7 @@
44
44
  **Principle.** Designers loop forever ("it's great → could be better → better → repeat"), refactoring UI like code. True refactoring waits for user feedback and changes what fixes a problem; repainting because the old color got boring is vanity that burns a week on pixel-perfect nobody asked for.
45
45
  **Apply when.** You feel the itch to redo a screen mid-project; separate "this resolves a known pain" from "this just looks nicer."
46
46
  **The move.** Gate the change: does it attack a real, validated pain? Richard's example passed because it tackled an old industry pain — customers not trusting the repair shop's quote. Until usage proves it, "you're just selling the visual."
47
- **Visual.** RepareCar quote builder — parts pre-loaded with photo, code, and cost; live financial summary (labor + parts = total); client approves by phone — `../assets/2062554393447141438__1.jpg`
47
+ **Visual.** RepareCar quote builder — parts pre-loaded with photo, code, and cost; live financial summary (labor + parts → total) — `../assets/2062554393447141438__1.jpg`
48
48
  **Source.** [@richardrx · 2026-06-04](https://x.com/richardrx/status/2062554393447141438)
49
49
 
50
50
  ## Mine the tactical layer — it's the most under-explored
@@ -94,7 +94,7 @@
94
94
  **Principle.** A dashboard is your software's front door, not NASA mission control. Cram it with colorful charts, five-decimal counters, and endless tables and the user takes a cognitive-overload beating, feels dumb, and churns. A good dashboard answers one question — "What do I do now to get more value?" — and that drives LTV.
95
95
  **Apply when.** Building or auditing any data-heavy screen (dashboards, reports, analytics views).
96
96
  **The move.** Apply the rule set: (1) **Define your "who"** — list users' top 3 pains, your top 3 value deliveries, and combine them. (2) **Noise is a cognitive tax** — every pixel that doesn't communicate (thick borders, heavy shadows, colored fills) competes for attention; less ink = more signal. (3) **Insights > raw data** — bad: "sales Jan–Dec"; good: "Revenue up 15% vs last month, likely cause: Twitter," with an expandable card (and a free 15-day upsell to act on it). (4) **The "so what?" test** (from Scott Belsky's *Making Ideas Happen*) — for each component, if a number is red, is the fix button right beside it? (5) **Round everything** — drop decimals, currency symbols, cents the ICP doesn't need; "R$10,234.56" → "10k"; white space cuts anxiety. (6) **Group by business context**, not chart type — sales in one block, support in another; the eye scans Z-within-F, so use Gestalt proximity/similarity to shorten the scan. (7) **Size + position = hierarchy** — "if everything is important, nothing is"; the user's North Star metric gets the largest font on screen. (8) **Design for humans** — celebrate when a goal is hit, redirect with good humor when something breaks; reinforce positive behavior to build habit and retention.
97
- **Visual.** "Raw data → Actionable" LEGO value ladder (collection → preparation → visualization → analysis → storytelling, rising from −value to +value) — `../assets/2022255404743381289__3.jpg`. Bad example: an aesthetic-looking dashboard overloaded with color that fails to direct attention — `../assets/2022255404743381289__4.jpg`. Hierarchy fix: a tiny "13" lost bottom-right (✗) vs a large "13" placed top-left in the F-pattern (✓) — `../assets/2022255404743381289__5.jpg`
97
+ **Visual.** "Raw data → Actionable" LEGO value ladder (collection → preparation → visualization → analysis → storytelling, rising from −value to +value) — `../assets/2022255404743381289__3.jpg`. Bad example: an aesthetic-looking dashboard crammed with modules and numbers that fails to direct attention — `../assets/2022255404743381289__4.jpg`. Hierarchy fix: a tiny "13" buried at the right edge of the middle row (✗) vs a large "13" placed top-left in the F-pattern (✓) — `../assets/2022255404743381289__5.jpg`
98
98
  **Voice.** "Your dashboard is a graveyard of data, and that's going to kill your LTV."
99
99
  **Source.** [@richardrx · 2026-02-13](https://x.com/richardrx/status/2022255404743381289)
100
100
 
@@ -3,13 +3,15 @@
3
3
  This skill was copied from Next Level Builder's UI/UX Pro Max Skill repository.
4
4
 
5
5
  - Source: https://github.com/nextlevelbuilder/ui-ux-pro-max-skill/tree/main/.claude/skills/ui-ux-pro-max
6
- - Source commit: 8a81ed60272d21d4b8808f7308d49a0b1b000555
6
+ - Source commit: 477bcb28c9812b385cb51a4605ddf30d7b2266e2
7
7
  - License: MIT
8
8
  - Copyright: Copyright (c) 2024 Next Level Builder
9
9
 
10
- The upstream skill used symlinks for `data` and `scripts`. This vendored copy
11
- stores those directories as real files so npm installs are self-contained.
12
- The upstream MIT license is included in `LICENSE`.
10
+ This vendored copy stores `data` and `scripts` as real files so npm installs
11
+ are self-contained. The upstream `scripts/tests` suite and its fixtures are not
12
+ vendored. Command examples in `SKILL.md` were rewritten from the upstream
13
+ plugin-root path to paths relative to the installed skill directory. The
14
+ upstream MIT license is included in `LICENSE`.
13
15
 
14
16
  The `Landing-Page Delivery Priority` section is an editorial addition merged
15
17
  from the first-party Agent Platform skill during catalog unification.