Ive done this a few times. 1 more successful than others. I would strongly push back on presales not being a possibility in your industry.
every single person says that, but the reality is a lot more likely to be the thing you want to build doesnt have enough value to the customer to part with their cash today.
Also agree with everything below. don't worry about this stuff right now. The sole focus should be what problem do people have that I can solve. Once you figure that out, and build an MVP, then you could worry about fancy business design.
"Getting the flywheel moving" is an incredibly hard part. You most likely will never move past this stage, which means all energy spent not trying to solve that singular issue will result in waste.
As far as paying for features, Id also strongly suggest against this. Initially, and for years to come, if your project is successful there will probably only be 1 major reason a customer hands you money to solve their problem.
This might be bc you save them 10 hours a week of manual labor, or ensure no mistakes are made while processing time sheets or guarantee uptime for production (whatever it is). Even though that might sound like very few people want it, if you can find a few you are on to something.
Anytime spent building a feature because a client paid for it will not be time well spent (all things considered).
I work on an enterprise rapidly scaling b2b SaaS app in finance space. We took lump sums early on from customers and now have 5-6 different "features" in our apps that have to be maintained, supported, all unique to 1 financial institution.
It might not sound like a lot, but when you're trying to get developers up to speed, help them understand the code base, and there are things like that, it really costs, and those costs scale exponentially.
Each feature we have to ensure works with this, doesn't break anything. etc. when we only had 2 developers this was something everyone knew. Now that we have multiple teams, its really, really expensive.
Tread lightly. Solve the first problem in front of you fairst (find a problem people will give you money TODAY to solve). If you succeed at that, you will have $$$ to solve your other problems.
So, to expand a bit on the concept of paid features, my current strategy, I give two options:
1) The paid feature, if it is based on a fixed fee, includes a warranty period, where we will prioritize fixing breaking changes as other parts of the codebase change.
Once the warranty period is expired, it required additional payments to fix the feature.
2) No warranty, but the feature cost increases their monthly or yearly SaaS fees, and requires advanced notice if disabling the feature.
As long as the user is paying for the feature, development resources will be devoted to maintaining it.
This also helps steer customers toward option 2.
Honestly, I use both these strategies more-so to prevent wasted time with feature requests the customer has no interest in paying for.
It forces them to find value in what they are asking for, not just because it is a ‘great idea’.
every single person says that, but the reality is a lot more likely to be the thing you want to build doesnt have enough value to the customer to part with their cash today.
Also agree with everything below. don't worry about this stuff right now. The sole focus should be what problem do people have that I can solve. Once you figure that out, and build an MVP, then you could worry about fancy business design.
"Getting the flywheel moving" is an incredibly hard part. You most likely will never move past this stage, which means all energy spent not trying to solve that singular issue will result in waste.
As far as paying for features, Id also strongly suggest against this. Initially, and for years to come, if your project is successful there will probably only be 1 major reason a customer hands you money to solve their problem.
This might be bc you save them 10 hours a week of manual labor, or ensure no mistakes are made while processing time sheets or guarantee uptime for production (whatever it is). Even though that might sound like very few people want it, if you can find a few you are on to something.
Anytime spent building a feature because a client paid for it will not be time well spent (all things considered).
I work on an enterprise rapidly scaling b2b SaaS app in finance space. We took lump sums early on from customers and now have 5-6 different "features" in our apps that have to be maintained, supported, all unique to 1 financial institution.
It might not sound like a lot, but when you're trying to get developers up to speed, help them understand the code base, and there are things like that, it really costs, and those costs scale exponentially.
Each feature we have to ensure works with this, doesn't break anything. etc. when we only had 2 developers this was something everyone knew. Now that we have multiple teams, its really, really expensive.
Tread lightly. Solve the first problem in front of you fairst (find a problem people will give you money TODAY to solve). If you succeed at that, you will have $$$ to solve your other problems.