Use case
Portfolio and Project Management Software
Project management asks whether this project is on track. Portfolio management asks whether it should exist. Tools designed for the first question answer the second one badly.
If you need mature PPM, buy it. Broadcom's Clarity, Planview, and Microsoft's Project for the web with Power BI on top are the established options, and they exist because portfolio management at scale is genuinely hard and heavily regulated in some industries. Nothing here is an argument that you should reimplement Clarity.
What is worth knowing first is that most organisations searching this phrase do not have a portfolio problem yet. They have a spreadsheet that four people edit and nobody trusts, and the question is whether to buy a large system or build a small one.
What portfolio management adds to project management
Four altitudes, and the tools that live at each
Which investments do we fund, and what do we stop? Decisions made quarterly by people who do not open a task board. The output is a funding list, not a schedule.
Several related projects sharing a goal and, more importantly, sharing people. This is where resource capacity is either managed or quietly overcommitted.
One deliverable with a start, an end, and an owner. The layer Asana, Jira, and Monday.com were designed for and are good at.
The actual work. Plenty of good free tools live here, and no portfolio decision has ever been improved by more detail at this level.
PPM software earns its price at the top two bands. If your real need is the bottom two, you are shopping in the wrong category and paying enterprise rates for it.
The specific things that only exist at the top: demand intake, a front door where proposals arrive and get scored before becoming projects. Stage gates, where funding continues only if criteria are met. Capacity against demand, which is the honest version of resource planning and the reason portfolios get rebalanced. And benefits realisation, checking a year later whether the promised return appeared, which is the one almost nobody does.
We can do portfolio management by grouping our projects and adding a roll-up dashboard.
Grouping gives you a report. Portfolio management is the intake, scoring, and gating that decides what enters the group and what gets killed, and a roll-up view of work already funded cannot produce those decisions.
If everyone updates their tasks properly, leadership will see the true picture.
Percent-complete on tasks rolls up into a number that feels precise and predicts nothing. The signals that matter at portfolio level, capacity, dependency risk, and whether the business case still holds, are not derivable from a task board no matter how well maintained.
A single system from portfolio down to task will finally give us one source of truth.
Executives want few numbers, updated monthly. Delivery teams want fast, detailed, daily tools they actually enjoy. Systems that serve both tend to be tolerated by neither, which is why plenty of organisations run a light portfolio layer above whatever the teams already use.
The third one is the useful insight if you are considering building: a thin portfolio layer over existing team tools is a much smaller project than replacing them.
What you would be starting from
pack-projects installs org-scoped projects with members, favourites, icons, and a project switcher in the navbar. The
Project model holds a name, description, status, icon, organisation, and creator. pack-teams and the starter pack
give you organisations, membership, and roles.
So you get the project as a first-class, permissioned, multi-tenant object, which is genuinely the foundation of the portfolio layer.
What is not there
- Tasks, at allThere is no Task model in the registry. No milestones, no dependencies, no Gantt, no critical path. If you want the bottom two bands of that diagram, you are writing them or integrating a tool that has them.
- Everything specific to portfoliosNo intake form, no scoring model, no stage gates, no capacity or allocation model, no benefits tracking. The four things that make it PPM are all yours.
- FinancialsBudget, forecast, actuals, and variance. pack-billing-stripe charges your customers a subscription, which is unrelated to tracking spend against a project budget.
- Executive reportingThere is no dashboard or charting layer aimed at this. Recharts is already a frontend dependency, so you have the drawing tools and none of the definitions.
The status field on Project is a plain string. That is a deliberate blank rather than a stage-gate model, and treating it as one is the first thing you would change.
When this trade is worth it
It is worth it when the portfolio layer is thin and yours. An intake form, a scoring rubric your leadership actually agreed, a capacity view built from your real team structure, and a monthly roll-up. That is a small application, and the reason to own it is that the scoring rubric and the gate criteria are specific to your organisation and are exactly what enterprise PPM tools make you configure for six months anyway.
It is not worth it if you need the bottom two layers as well, because then you are building Jira, and Jira exists.
The install below is the foundation: organisations, projects, members, auth, and a typed API. What you add is the decision process, which was always the part only you could write.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeInside the stack
What each pack gives you
Source code, not a dependency. Every pack lands in your repository across the surfaces the feature touches.
Authentication, organizations, roles, sessions, and a full admin app, powered by WorkOS.
- Email & social login
- Organizations & members
- Roles & permissions
- Admin app & dashboard
Questions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.