Are you paying for SaaS features you barely use?
I’m testing a product hypothesis with blockmade.
Small teams often end up with several tools, while only using a small part of each one. And the one function they actually want can still be missing.
I’m testing a different setup:
pick only the functions you actually use, show the functions you still need, and generate an editable workspace from the Blocks that exist today.
I’m trying to falsify two things:
- Is paying for unused functionality painful enough to make someone replace part of their current stack?
- Is choosing only the functions you need useful, or is that setup process itself too much work?
The prototype does not claim to replace everything. It still lacks production-grade permissions, email sync, and broader integrations.
If you use several SaaS tools for work, I’d like to know:
- Which current tool could this realistically replace?
- What missing function would still stop you from switching?
No signup or card:
I like that you're trying to falsify it instead of prove it. As a solo builder, the unused features bother me less than the one missing function that makes me keep a second tool open. So your second question might be the stronger one - the gap, not the waste. When people go through the configurator, are they picking functions they already use, or mostly the ones their current tools are missing?
That distinction is exactly what I need to learn. The configurator asks which functions you already use and shows where a requested function is not supported by the Blocks available today. It does not yet tell me whether people choose mostly familiar functions or mostly missing capabilities; I don’t have enough completed real configurations to claim a pattern. I’m treating that as an open question, not validation.
Nice progress. What is the next thing you are focusing on?
Nice progress. What is the next thing you are focusing on?
Right now I’m focusing less on adding more features and more on making the first useful action obvious.
I want someone who understands the idea to be able to open it and quickly know what to do next.
Nice progress. What is the next thing you are focusing on?
Nice progress. What is the next thing you are focusing on?
Nice progress. What is the next thing you are focusing on?
Interesting approach. What was the hardest part to get right?
The hardest part has been making the flexible setup feel like a clear starting point instead of another configuration task. A concrete workflow helps, but I’m still learning which parts of the first step need more explanation. What would you expect to see before trying a tool like this?
Clear and practical, thanks. Did anything surprise you along the way?
The biggest surprise was that strong interest in the idea did not always mean people knew how to take the first step. The clearest signal came from seeing where someone hesitated, rather than asking whether the concept sounded useful. Have you noticed that kind of gap between positive feedback and actual use in your own work?
I think the “unused features” problem is especially interesting for small businesses.
From the workforce-management side, I’ve noticed that businesses often need only a few core things at first: attendance, timesheets, leave, and payroll. But many platforms bundle a much larger set of HR features, which can make the product feel more complicated than necessary.
I think the difficult part is finding the right balance between flexibility and setup effort. If users have to spend too much time deciding which pieces they need, the configuration itself can become another problem.
For me, the strongest validation would be whether someone can set up a useful workflow quickly and then keep using it without needing the rest of the feature set.
Arslan, your point about setup effort is why I turned the demo into a ready-made Workforce Box in V2.1. My earlier reply asked for broad feedback; here is one concrete test instead: open the live sample, edit one fictional employee name or shift on Attendance, then check Timesheets and the Payroll estimate. Which single step is least clear? Direct link: https://blockmade.tech/box/work/plate/attendance?utm_source=indie_hackers&utm_medium=comment_reply&utm_campaign=v2_1_workforce&utm_content=workforce2020_one_edit . Please use sample data only.
Thanks again for the feedback. I built a working demo based on what you suggested.
This isn’t meant to be a finished workforce or payroll product. It’s a demo of what this kind of system could look like when built with blockmade.
The Workforce Box includes separate Plates for Overview, Attendance, Timesheets, Leave, and Payroll. Changes in Attendance flow through to Timesheets and the payroll estimate, and there’s working CSV import/export to try.
blockmade itself is still evolving. The idea is to keep adding Blocks based on real user feedback, so people can shape each Box around the way they actually work.
Here’s the demo:
https://blockmade.tech/box/workforce/plate/wf-overview?lang=en
What I’d really like to know is: what would need to change or be added for you to actually want to use something like this?
Missing features, awkward parts, or things you think are unnecessary would all be useful feedback.
Makes sense. Are you planning to charge for it, or keep it free for now?
Free for now, but I’m not assuming it should stay free forever.
At this stage I want to answer a more basic question first: will people actually move real work into blockmade and keep using it?
If that happens consistently, then I can test what part of the value people are actually willing to pay for rather than guessing at pricing too early.
So right now: validate real use first, pricing second.
What would have to happen for something like this to become worth paying for in your workflow?
The real answer is probably that your SaaS doesn't measure which features you actually use. Most products don't. It's friction to add - you need events for feature clicks, session tracking, retention per feature, maybe cohort analysis if you want to see whether people who use feature X stick around longer.
So the feature set grows because it looks good in marketing. The product team builds backwards from "what should we include to be competitive" instead of "which of our current features are users actually opening."
The gap is almost always there: announced feature adoption vs observed usage are measured at different times (launch vs two weeks later) and on different cohorts (marketing-adjacent early users vs the real user base). If you built one dashboard that just said "here's feature X, here's what percentage of MAU opened it last month," you'd probably cancel half your features immediately. That's expensive data to ignore, so most SaaS don't build the dashboard.
That’s a useful distinction: shipping a feature and seeing people return to it are very different signals. With blockmade, I’m testing whether someone moves one real workflow into a workspace made from only the Blocks they need, then comes back to do that work. I don’t have replacement behavior proven yet. Your point about comparing feature use across cohorts over time is strong. Have you found a lightweight way to get that signal without turning analytics into a project of its own?
Thanks for writing this up. Bookmarking it for later.
Glad it was useful.
If you come back to it later and anything feels unclear or doesn’t hold up in practice, I’d genuinely rather hear that than a polite thumbs-up.
That kind of feedback is exactly what I’m trying to collect right now.
This happens to me constantly — I keep tools around for one feature I used once. Are you building something to track that, or just asking to gauge interest?
I’m building something, not just gauging interest — but it isn’t a subscription tracker.
The idea is to let people assemble only the pieces they actually need in one workspace, so they may not need to keep a full SaaS around just for one feature.
I’m still testing whether that actually changes real behavior.
Which tool are you currently keeping around for that one feature?
What user behavior would validate the replacement hypothesis for you—configuring a workspace, importing real work, or actually abandoning an existing SaaS tool?
I’d treat those as different levels of evidence.
Configuring a workspace shows intent.
Moving real work into it shows activation.
Repeatedly using it instead of the old tool shows replacement behavior.
Downgrading or cancelling the old SaaS is the strongest signal.
If someone builds something in blockmade but keeps doing the real work in the old product, then I’ve just added another tool.
The sequence I’m watching is:
real workflow moved → repeated use → old tool reduced or cancelled.
I’d count a downgrade as meaningful partial replacement, but not full replacement.
Would you draw the line at downgrade, or only at full cancellation?
That’s a pretty clean hierarchy. Could take this over email sometime — what’s easiest on your side?
Happy to keep it here for now. I’m deliberately keeping the early validation public because the useful part for me is seeing where people challenge the assumptions, rather than moving the conversation off-thread too quickly.
The next thing I’m trying to understand is whether replacement starts before cancellation — for example, when someone moves one real workflow over and starts relying less on the old tool.
If you see a flaw in that definition, I’d rather pressure-test it here.