The latest articles on DEV Community by Levine (@enivel). https://dev.to/enivel https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3944112%2F2549a4c1-3134-477a-9c26-7014c4929891.jpeg https://dev.to/enivel en Levine Thu, 21 May 2026 12:55:13 +0000 https://dev.to/enivel/i-built-a-mac-app-that-turns-web-pages-into-live-widgets-fd4 https://dev.to/enivel/i-built-a-mac-app-that-turns-web-pages-into-live-widgets-fd4 <p>I'm the developer of <a href="https://kepo.ai" rel="noopener noreferrer">Kepo</a>, a Mac app I started building because I kept checking the same web pages over and over again.</p> <p>Product Hunt launches. Reddit threads. GitHub releases. YouTube channels. Docs. Small dashboards. Status pages.</p> <p>Each check only takes a few seconds, but the workflow is surprisingly expensive:</p> <ol> <li>switch back to the browser</li> <li>find the right tab</li> <li>refresh or scroll</li> <li>read one small piece of information</li> <li>switch back to what I was doing</li> </ol> <p>After repeating this enough times, I started wondering if some web pages should not be tabs at all. Some of them feel more like small pieces of state that should sit closer to the desktop.</p> <p>That was the starting point for Kepo.</p> <h2> The product idea </h2> <p>Kepo turns web pages into live Mac desktop widgets.</p> <p>The goal is not to recreate a whole browser inside a widget. The goal is to take the part of a page that you repeatedly care about and make it available in a small, glanceable interface.</p> <p>For example:</p> <ul> <li>today's Product Hunt launches</li> <li>a Reddit thread you are following</li> <li>GitHub releases or issues</li> <li>a YouTube channel update</li> <li>a docs page section</li> <li>a small internal dashboard</li> <li>a checklist, timer, formatter, or monitor</li> </ul> <p>Kepo lives in a floating desktop panel that can be opened with a shortcut, closer to the way Raycast fits into a developer workflow. You bring it up, check or use a widget, then go back to your work.</p> <h2> The tricky part: web pages are not APIs </h2> <p>At first, this sounded simple: take part of a page and render it as a widget.</p> <p>In practice, web pages are messy.</p> <p>A page can depend on login state. It can lazy-load content. The DOM can change. Some sites expose a feed or API, while others only expose rendered HTML. Some pages are stable enough to parse directly, while others need a browser context to understand what the user actually sees.</p> <p>So the hard part is not only "extract data from a page".</p> <p>The harder questions are:</p> <ul> <li>what is the smallest useful version of this page?</li> <li>what should happen when the page fails to load?</li> <li>how often should it refresh?</li> <li>what information should be hidden in a small widget?</li> <li>when should the widget open the original page instead of trying to replicate it?</li> </ul> <p>This is where I started thinking of widgets less as small UIs and more as small contracts.</p> <p>A good widget has a clear promise: "I will show you this specific piece of information in this specific shape, without forcing you to open the full page every time."</p> <h2> Where AI fits </h2> <p>Kepo includes an AI creation flow. You can point it at a page and ask it to build a widget from it.</p> <p>AI is useful here because the first version of a widget is often structural work:</p> <ul> <li>inspect the page</li> <li>decide which data matters</li> <li>sketch the UI</li> <li>generate the widget code</li> <li>adjust the layout for small sizes</li> </ul> <p>But I do not think AI removes the design problem.</p> <p>The human part is still deciding what the widget should mean. For a Product Hunt page, do you want the full feed, the top launches, vote counts, comments, or just a launch checklist? For a GitHub page, do you want releases, issues, pull requests, or a status monitor?</p> <p>AI can help build the first version faster. It cannot automatically know what deserves to stay on your desktop.</p> <h2> Making it useful for developers </h2> <p>I also did not want custom widget creation to be locked entirely behind the built-in AI flow.</p> <p>So Kepo has a free Skills-based development path for developers who already use local coding agents like Claude Code or Codex.</p> <p>You can install the Skill with:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>npx skills add Enivel/kepo-plugin-dev-skill </code></pre> </div> <p>That lets developers build and run custom widgets locally. The built-in AI creation flow is paid, but the Skills path is free to use.</p> <p>This makes the product feel closer to a small desktop platform than a fixed widget gallery. There are ready-to-use widgets, but developers can also build their own.</p> <h2> What I am still trying to figure out </h2> <p>The biggest open question is not whether the technology works. It is where this belongs in a developer's daily workflow.</p> <p>Some widgets clearly make sense:</p> <ul> <li>CI status</li> <li>server health</li> <li>GitHub releases</li> <li>launch pages</li> <li>docs snippets</li> <li>feed monitors</li> <li>small local tools</li> </ul> <p>Other cases probably still belong in the browser.</p> <p>That boundary is what I am trying to learn from real users.</p> <p>If you are a developer, what web page would you actually want to turn into a desktop widget?</p> <p>Not in a "this looks cool" way, but in a "I check this often enough that I would save time if it lived one shortcut away" way.</p> ai webdev productivity