Launching a public beta for SaaS/Dev tool - I should list all future( udeveloped) modules/roadmap or show only the current module. ( I will not promote )

[u/AggravatingCoyote186]

Hi – Currently in stealth, boot strapped, and planning to do a public beta launch for my SaaS/Dev platform. Primary users are data engineers and semi-tech-skilled business users.

Full vision of the application has 6 different models, each solving one problem in the full cycle.  Module "A" is built—MVP/beta ready. 2 modules are wireframed and functional. 3/6 modules are just concepts now.

Contemplating the right strategy for  the first beta release: (1) include all 6 models -1 functional and 5 with a home page describing the capability and value created.

OR 

(2) Disable/Hide all future modules/road map and only focus on "A" that is in beta.

Options: (1) Give the whole scope of value chain, builds confidence in the vision, and drives investor interest. But it could be too much information and can dilute the impact of module “A". 

Options (2) Might sound like a one-trick pony. And might sound weak without a road maps

What strategy would you pick? And is there anything I’m missing to consider?

[u/alexid95]

show only A in the beta. five future tabs make a working product feel unfinished, and user requests will tell you which roadmap item deserves to exist next.

[u/dmdbGroup]

option 2, and it's not close. the roadmap is for your pitch deck, not your product.

the real problem: beta users judge you on what's clickable. five dead tabs don't communicate vision, they communicate 'not done yet.' every undeveloped module is a headline that says come back later. users don't come back later.

what i'd actually do:

1. ship module A like it's the whole product. its own landing page, its own pricing story. if A can't stand alone, the other five are wishes anyway.
2. keep the vision in a one-pager for investors and partner calls. investors buy roadmaps, users buy working software. different audiences, different rooms.
3. if you must hint at more, one line at the bottom: 'built to extend across the full workflow.' not tabs, not mockups. mockups of unshipped features are promises you now have to keep on someone else's schedule.
4. watch what beta users ask for. if 30% ask for module B unprompted, you just validated your roadmap for free. if nobody mentions it, you saved six months building the wrong second thing.

rule of thumb: launch the thing that's real like it's everything. the vision is a story you tell, not a tab you ship.

[u/Professional-Run3614]

I’d show only module A for now. I usually build an MVP, get it in front of real users, and then decide what to build next based on their feedback. Things can change a lot once people actually start using the product, so I wouldn’t commit too much to a roadmap this early.

[u/RajatKhoware]

Hide the roadmap. Show only module A. We have watched founders demo the "vision" and walk away with zero usable feedback, because everyone reacts to the fantasy instead of the product. A beta that does one thing well gets you the one thing you actually need: proof someone will use it. List the future modules and you get opinions. Ship one module and you get behavior. Which matters more to you right now, investor excitement or user proof?