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:
Nice progress. What is the next thing you are focusing on?
Interesting approach. What was the hardest part to get right?
Clear and practical, thanks. Did anything surprise you along the way?
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.
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?
Really relatable. How much time do you put into this each week?
It varies, but I try to keep my direct time fairly focused rather than treating it like a full-time build.
Most of that time goes into reviewing what people actually do, deciding what needs to change, and testing the next assumption — not just adding features.
Right now I’m more interested in whether a small amount of focused work can produce real user behavior than in maximizing hours spent on it.
How much time do you usually give a new project before deciding whether it deserves more?
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?
Great breakdown. What feedback have you had from early users?
Still very early. The useful feedback so far has been about whether the first setup is clear and what would stop someone moving real work into it. I don’t yet have enough repeated use to say it replaces anything. I’m trying to learn from concrete workflows rather than compliments alone. What kind of feedback has most helped you decide what to change in your own product?
Helpful post. How did you get your first bit of traction?
Still very early.
The first useful traction came from small founder communities and launch directories, but the important part wasn’t the number of visits.
It was a few people actually trying the product and giving specific feedback.
Joining conversations worked better than simply dropping a link.
I’m still testing which channels bring real users rather than just visitors.
Where did your first engaged users come from?
Nice work shipping it. What has been the biggest challenge since launch?
The biggest challenge has been the quality of distribution, not raw traffic.
Getting someone to visit is one thing. Getting them to move real work into a new workspace is completely different.
So I’m trying to separate curiosity from actual use instead of treating every click as traction.
That gap has been harder than shipping the product itself.
Did you run into the same thing after launching something of your own?
How did you decide this was worth building in the first place?
I worked backwards from a repeated behavior rather than starting with an idea.
I was already paying for several tools while only using a small part of each one. That made the problem real enough to test.
What I still don’t have is proof that other people will actually replace part of their existing stack with blockmade.
So I’d say the pain was strong enough to justify building the test — the product itself is not validated yet.
What threshold do you usually use before deciding something is worth building?
I worked backwards from a repeated behavior rather than starting with an idea.
I was already paying for several tools while only using a small part of each one. That made the problem real enough to test.
What I still don’t have is proof that other people will actually replace part of their existing stack with blockmade.
So I’d say the pain was strong enough to justify building the test — the product itself is not validated yet.
What threshold do you usually use before deciding something is worth building?
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?
Appreciate the honesty here, most people only share the wins.
Appreciate that.
I’m trying to document what actually happens rather than make the experiment look cleaner than it is.
At this stage, the misses are usually more useful than the wins because they show me what still needs to be proven.
Makes sense. Are you planning to charge for it, or keep it free for now?
For now I’m keeping it free while I validate real use.
I don’t want to choose a pricing model before I know whether people actually move real work into it and replace part of an existing paid tool.
If that behavior starts happening, pricing becomes a much more grounded question.
What would blockmade have to replace for it to feel worth paying for to you?
Interesting approach. What was the hardest part to get right?
The hardest part has been making the idea easy to understand without narrowing it into a single-use-case product.
If I make it too broad, it sounds vague. If I explain one concrete use case too strongly, people assume that’s all blockmade is for.
So the hard part hasn’t really been adding more features. It’s making the flexibility obvious fast enough that someone still knows what to do first.
What felt least obvious to you when you first saw it?
Helpful post. How did you get your first bit of traction?
Still very early, so I wouldn’t call it major traction yet.
The first signs came from putting blockmade in front of small, relevant founder communities and launch directories rather than trying to reach everyone at once.
What helped most was joining the conversations instead of just dropping a link. A few people actually clicked through, tried the product, and gave feedback — that was more useful to me than a larger number of passive views.
So right now I’m treating “someone actually tries to build something with it” as a much stronger signal than traffic alone.
I’m still testing which channels bring people who genuinely use the product, not just visit it.
What worked for you when you were trying to get your first real users?
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.
How did you decide this was worth building in the first place?
The initial signal wasn’t “people want another SaaS.” It was almost the opposite.
I kept noticing the same pattern: paying for full products while only needing a small part of each, then stitching the rest of the workflow together.
That made the hypothesis worth testing: what if the workspace is the product, and users assemble only the pieces they actually need?
I don’t consider the idea validated yet. For me, that starts when someone moves real work into blockmade and it actually replaces part of an existing paid tool.
That’s the bar I’m testing now.
Curious — when you asked this, were you thinking more about demand evidence, or about the founder experiencing the problem firsthand?