VectorUP

The original motivation was almost embarrassingly simple: I wanted a cleaner launcher. I had too many shortcuts, too many applications, too many folders and too many things I knew were somewhere, which is often another way of saying I had no idea where they were. A launcher is supposed to save time. Once you start scrolling through it wondering where the thing you use every second Tuesday ended up, something has gone wrong.

So the first version of the idea was not ambitious at all. I wanted one place where I could organize what I use, search for it quickly and open it without thinking too much about where Windows had decided it belonged.

Then, as usual, the problem became more interesting the closer I looked at it.

The things I use are not just applications. Some of them are folders. Some are websites. Some are terminal commands. Some are tools I only use in one particular context. Some belong together and almost always get opened as a group. Some are commands I know perfectly well until the exact moment I need them. At that point it became obvious that what I really wanted was not just a prettier launcher. I wanted a better way to move from “I want to do this” to “here are the things I need”.

That is where the name VectorUP comes from.

The “Vector” part is about direction. I have somewhere I want to go, and VectorUP should reduce the distance between the intention and the tool. “UP” stands for Unified Portal, because the long-term idea is to bring these different entry points together without turning them into one enormous pile. Unified does not mean everything mashed into the same screen. It means the user should not need to care quite so much about where something technically lives.

One of the ideas I care most about is that VectorUP should not force everyone into the same kind of application. A lot of software gets more powerful by getting more complicated for everybody. I want VectorUP to work the other way around.

For one user it should simply be a fast, tidy launcher. Press a shortcut, type a few letters, press Enter, done. For another user it can become a much broader productivity tool with workspaces, commands, automation, local search, health checks and workflows.

That is why the project is being built around four levels. Basic is meant to stay approachable for most users, with applications, categories, favorites, recent items and search. Enhanced adds more organization, workspaces, websites and modules. Advanced is where more technical features come in, aimed at developers, technicians and people who use the computer as a serious work tool. Full enables the complete stable feature set.

The important part is that these are not difficulty levels where Full is somehow the correct answer. Basic is not the demo version. If all you want from VectorUP is a better launcher, then Basic should feel complete. If you want half the advanced features but not the other half, that should also be fine. The presets are there to give the user a sensible starting point, not to decide how the program must be used.

Because VectorUP is still under active development, the exact contents of those levels may change. Some features are already working, some are being built, and others are still being shaped. At the moment, a selection of the ideas and features includes:

• Quick Launcher, with a global shortcut and fast search across the things VectorUP knows about.
• Categories, favorites and usage history, to make frequently used items easier to get back to.
• Workspaces, where applications, folders, websites and commands can be grouped into a reusable work setup.
• Smart Commands, which turn saved commands into something more useful than a line of text by allowing prompts, variables and choices.
• Workflows, for chaining several actions together.
• Website management, including organization, import, archiving and planned health information.
• Endpoints and Health, for keeping an eye on services such as HTTP, SSH, RDP and TCP without trying to reinvent a full monitoring platform.
• Maintenance, for finding problems in the user's own setup, such as missing paths, duplicates or broken references.
• Diagnostics, for showing whether VectorUP's own internal providers and services are actually working.
• Sessions, intended to capture useful parts of a current working setup and help restore them later.
• Share & Import, so commands, workflows, workspaces and other definitions can be exchanged without requiring a cloud service.
• Modules, such as system information, clock and weather, designed to stay useful without taking over the main interface.
• Light and dark themes, both intended to be proper designs rather than one theme with the brightness slider dragged in the opposite direction.
• Feature Selector, which is what allows the same application to remain simple for one user and considerably more capable for another.

That list is deliberately not a promise that every item is finished. It is a snapshot of where the project is heading. I would rather say that openly than write about VectorUP as if it is already sitting there in version 5.0 waiting for people to discover it.

Smart Commands are probably one of the better examples of how the project has changed while being built. The first thought was simply to save commands I use regularly. That is useful, but not especially interesting. The better idea was to let the command describe what information it needs.

Instead of keeping a command like:

ping 10.77.77.2

I can define something called “Ping host” and have VectorUP ask for the host or IP address when I use it. The same principle works for more complicated commands. A project creation command can ask for a project name and project type. Another command might ask for a folder, URL or server name.

That turns a collection of terminal snippets into small tools. More importantly, it means I do not have to keep pretending I will remember syntax I have already looked up fourteen times.

Workspaces follow much the same thinking. If I always open the same editor, terminal, project folder, documentation and websites when I start working on something, then those things are really part of one activity. VectorUP should be able to treat them that way instead of making me reconstruct the same setup manually every time.

This is where the project has gradually moved beyond being just a launcher, but I am also trying very hard not to let it lose the simplicity that made me start it in the first place. There is a very real danger with projects like this that every useful idea gets added until the original problem has been buried under its own solution.

If opening Calculator eventually requires understanding workflows, endpoints and PowerShell providers, I have clearly taken a wrong turn.

Another important principle is that VectorUP is local-first. It is being built as a desktop application using Tauri, React, TypeScript, Rust and SQLite. The core application, data and settings are intended to work locally without requiring an account or a cloud service just to function. Some features naturally need network access, but that is very different from making the whole product depend on a remote service.

I like software that continues to be useful when the internet is down. Radical concept, apparently.

The visual side is also undergoing a fairly major rebuild. The first interface was designed for a much smaller application, and the feature set simply grew faster than the layout did. That eventually resulted in too much empty space in some places, too much scrolling in others, narrow dialogs, settings that had accumulated rather than been designed, and screens that did not always make it obvious what they were for.

That is being reworked now. The goal is better use of wide screens, clearer page structure, a dedicated utility area for modules, wider and more sensible dialogs, better organization of Settings, a stronger visual identity and properly designed light and dark modes.

So where does VectorUP end? I still do not know.

At the moment, I think that is a feature rather than a problem. The principles are becoming fairly solid, but I do not want to decide the final shape before I have actually used enough of it to know what deserves to stay.

It started with one very ordinary problem: my launcher was becoming a mess.

Then came categories. Then workspaces. Then commands. Then websites. Then health checks. Then automation. And at some point I realized I was building something that might be useful both to someone who just wants a cleaner way to launch Word and to someone who considers opening three terminals before breakfast completely normal behavior.

The important part has stayed the same, though. I want to spend less time looking for my tools and more time using them. VectorUP should be able to stay simple. It should also be able to become powerful. The user should decide which one they need.