On my old Windows laptop, having more than ten Chrome tabs open could make the whole machine struggle. RAM was limited, and the browser was asking too much of it. That was what first sent me looking for a better way to manage tabs.
I’m the kind of person who needs organization in their life. Back then, though, I had an immediate reason to find it: I wanted to keep useful pages without keeping all of them open.
I found OneTab. In the version I used, one click closed the tabs and kept them together on a separate page so I could return to them. It solved the immediate problem. Finding a particular tab again felt less intuitive to me, but it gave me a way to put pages aside.
Years later, I found Workona. I don’t remember where I discovered it. I do remember what made it stick: workspaces, persistent tabs associated with an account, and a cleaner, more polished experience. It was easy to use and met my needs.
A product I was happy to pay for
As I remember it, my first year was free. When Workona introduced its paid plan, I happily paid. After two years as a paying user, a renewal arrived at a point when I couldn’t afford it. I figured I could live without it and let the subscription lapse.
Workona had become one of the first extensions I would usually install on a new laptop. How often does that happen? Still, it says something about the place it had in my setup.
That history matters to why I’m building Tabwar. I already know the experience of finding a tool that works for me. I also know what I miss when I stop using it. Workspaces and an easy way back to my tabs have personal value to me, even though that tells me little about whether another extension would find an audience.
A reason to build, before a market case
Today, Claude and Codex have reached a point where I want to try building my own version. As a coding product designer, I need to keep my product gears moving. Building gives me a way to do that while learning how to work with AI.
Last month, I built Sitefar to solve another problem of my own. Tabwar comes from the same impulse: there is something I want to use, and building it gives me a practical reason to learn.
AI can do a lot. Someone still has to bring the initiative and decide what to pursue. For this project, that starts with a need I can describe from my own experience.
I haven’t researched market demand for another tab-management extension. Even if I end up being its only user, having something that serves my needs would make the project worthwhile to me. Broader demand remains an open question. My willingness to build is not evidence that other people will want it.
My history gives me a starting point; the brief still needs choices
I began by asking an AI assistant to research Workona, propose a build plan and first-version features, and create a backlog we could review before implementation. After the engineering plan existed, I asked for a dedicated product requirements document linked to the issues.
The research used public product and help documentation. It was separate from my own history as a user: the research pass did not include a hands-on paid-account evaluation or customer interviews.
The assistant proposed an initial job: put a project’s tabs away safely and return to them quickly. The draft PRD turns that into a journey of capturing a window, working in it, saving and closing it, and resuming later.
The first proposal gave each open workspace its own browser window. Switching would bring that window forward. The assistant recommended this because it reduced the complexity of closing and reopening tabs.
I rejected that model. I wanted switching workspaces to replace the tabs in the current window, and I asked why that could not be done. The initial recommendation did not match the experience I was asking for.
The revised plan makes same-window replacement a first-version requirement. It calls for saving the outgoing workspace before replacing its managed tabs with the selected project's tabs. The implementation still has to prove that it can handle an interrupted switch without losing saved sessions or creating duplicates.
That correction changed the delivery plan as well. A switching proof moved into the first-version work and became a dependency of the complete switching feature. The earlier 15–23-day engineering estimate, which assumed separate windows, was withdrawn. The plan now calls for re-estimating after that proof.
I also accepted local storage for the first version. Account-backed persistence was something I valued in Workona; Tabwar’s first version will take a different approach. Broader synchronization remains outside the proposed first release.
For the interface, I requested shadcn/ui and Tailwind, with GitHub, Linear, and Asana as references for the feel. That gives the design work a direction. It does not mean a screen has been designed or reviewed yet.
What I can claim so far
The repository contains research, an engineering plan, a proposed backlog, and a draft PRD. There is no extension to use yet.
The brief proposes saving recovery data before closing tabs and blocking a close when saving fails. It also makes a distinction between reopening saved URLs and preserving unsaved work inside a page. Those requirements give future implementation something concrete to demonstrate. They have not been built or tested.
My reason for starting is clear: I want an organization tool I will use, and I want to learn through building it with AI. Same-window switching is now part of that direction. Pin behavior, what happens across multiple windows, and which tabs a switch may replace still need decisions before the first workflow can be tested.
AI assistance: an AI assistant helped synthesize research, prepare the planning artifacts, and draft this article from my account and the repository. Same-window switching and local storage are accepted directions; remaining policies and feature priorities are still under review.
