I built a Mac app that turns web pages into live widgets

I'm the developer of Kepo, a Mac app I started building because I kept checking the same web pages over and over again.

Product Hunt launches. Reddit threads. GitHub releases. YouTube channels. Docs. Small dashboards. Status pages.

Each check only takes a few seconds, but the workflow is surprisingly expensive:

1. switch back to the browser


2. find the right tab


3. refresh or scroll


4. read one small piece of information


5. switch back to what I was doing

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.

That was the starting point for Kepo.

The product idea

Kepo turns web pages into live Mac desktop widgets.

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.

For example:

• today's Product Hunt launches


• a Reddit thread you are following


• GitHub releases or issues


• a YouTube channel update


• a docs page section


• a small internal dashboard


• a checklist, timer, formatter, or monitor

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.

The tricky part: web pages are not APIs

At first, this sounded simple: take part of a page and render it as a widget.

In practice, web pages are messy.

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.

So the hard part is not only "extract data from a page".

The harder questions are:

• what is the smallest useful version of this page?


• what should happen when the page fails to load?


• how often should it refresh?


• what information should be hidden in a small widget?


• when should the widget open the original page instead of trying to replicate it?

This is where I started thinking of widgets less as small UIs and more as small contracts.

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."

Where AI fits

Kepo includes an AI creation flow. You can point it at a page and ask it to build a widget from it.

AI is useful here because the first version of a widget is often structural work:

• inspect the page


• decide which data matters


• sketch the UI


• generate the widget code


• adjust the layout for small sizes

But I do not think AI removes the design problem.

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?

AI can help build the first version faster. It cannot automatically know what deserves to stay on your desktop.

Making it useful for developers

I also did not want custom widget creation to be locked entirely behind the built-in AI flow.

So Kepo has a free Skills-based development path for developers who already use local coding agents like Claude Code or Codex.

You can install the Skill with:

npx skills add Enivel/kepo-plugin-dev-skill

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.

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.

What I am still trying to figure out

The biggest open question is not whether the technology works. It is where this belongs in a developer's daily workflow.

Some widgets clearly make sense:

• CI status


• server health


• GitHub releases


• launch pages


• docs snippets


• feed monitors


• small local tools

Other cases probably still belong in the browser.

That boundary is what I am trying to learn from real users.

If you are a developer, what web page would you actually want to turn into a desktop widget?

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.