Ask HN: The software I want to build is too custom, how do I make it affordable?
9 comments
I was in a similar situation recently working with minimally funded organizations. In the end, after spending about two years on it, I wasn't able to make it work. The groups' needs were just different enough that they required consulting engagements but couldn't really afford them. I've found it disappointingly hard to serve small businesses and NGOs given that they often do interesting and important work. I hope you can make it happen. Some thoughts:
0) There's a good chance your main obstacles aren't related to server optimization or finding the right mix of features to roll into a product. You probably need to clarify your assumptions and make sure there's really a business to be had.
1) Consider honestly whether it's realistic to serve organizations that can't pay $40 a month for software they need. I'm not saying it's impossible or undesirable, but it's a critical question to answer for yourself. You need to eat, and choosing to work with these organizations means you'll have to have to subsidize your time with other, higher paying work, offer a level of service that won't satisfy you or your customers, or both.
It's possible there's a large enough number of customers that you could support a business on < $40/month, but it's unlikely for non-profits, especially given your experience with their heterogeneous needs.
2) In light of their reluctance to spend, how sure are you that you've identified a critical need for these organizations? This isn't necessarily an indictment of your product. In my experience many small NGOs are still figuring out their internal processes, and what's important to them and their funders. Codifying nascent processes in software is hard - bordering on impossible - and sales cycles can be untenably long. On the plus side it means they're often willing to be flexible and work with you as you figure out what the software should do.
3) If you do move forward (and of course you probably will), be creative about funding. Working with non-profit arts organizations gives you a great story to tell. If submission management and evaluation really is critical, can you work with your customers to incorporate a software budget into their funding proposals? Find out who the funders are. What are their priorities? Can you appeal directly to funders and show them how your software can help achieve and monitor their objectives, and communicate their impact more effectively?
I'd love to hear what you end up doing. Feel free to reach out (my username at gmail) if I can help.
0) There's a good chance your main obstacles aren't related to server optimization or finding the right mix of features to roll into a product. You probably need to clarify your assumptions and make sure there's really a business to be had.
1) Consider honestly whether it's realistic to serve organizations that can't pay $40 a month for software they need. I'm not saying it's impossible or undesirable, but it's a critical question to answer for yourself. You need to eat, and choosing to work with these organizations means you'll have to have to subsidize your time with other, higher paying work, offer a level of service that won't satisfy you or your customers, or both.
It's possible there's a large enough number of customers that you could support a business on < $40/month, but it's unlikely for non-profits, especially given your experience with their heterogeneous needs.
2) In light of their reluctance to spend, how sure are you that you've identified a critical need for these organizations? This isn't necessarily an indictment of your product. In my experience many small NGOs are still figuring out their internal processes, and what's important to them and their funders. Codifying nascent processes in software is hard - bordering on impossible - and sales cycles can be untenably long. On the plus side it means they're often willing to be flexible and work with you as you figure out what the software should do.
3) If you do move forward (and of course you probably will), be creative about funding. Working with non-profit arts organizations gives you a great story to tell. If submission management and evaluation really is critical, can you work with your customers to incorporate a software budget into their funding proposals? Find out who the funders are. What are their priorities? Can you appeal directly to funders and show them how your software can help achieve and monitor their objectives, and communicate their impact more effectively?
I'd love to hear what you end up doing. Feel free to reach out (my username at gmail) if I can help.
Why not setup a web application, and host everything on your servers? Then, offer different plans based on the amount of work they're receiving.
This is the beauty of web applications, they don't need to run their own hosting, manage a VPS, or register a domain. I think that would be overwhelming for non-profit art organizations, so if you can get them started in minutes with a few clicks, you'll be more likely to win them over.
Customizing software for each organization seems like a nightmare, along with the support to follow. If they're hosting things on their own, you'll have to troubleshoot that as well. You might make more money per organization, but I think you'll reach far less.
You said the core of the software is fairly simple, and some groups don't need anything too complex. Start there, get the core of the software working, and get something online. Approach these groups, get feedback, get them signed up, and start growing. When you have a few customers, you can start adding more features, and building out the software. Don't try to build a monster app all at once, you'll end up over your head, get frustrated, lose interest, and be less likely to ever finish.
Remember, everything takes far longer than expected. Keep it simple to start.
This is the beauty of web applications, they don't need to run their own hosting, manage a VPS, or register a domain. I think that would be overwhelming for non-profit art organizations, so if you can get them started in minutes with a few clicks, you'll be more likely to win them over.
Customizing software for each organization seems like a nightmare, along with the support to follow. If they're hosting things on their own, you'll have to troubleshoot that as well. You might make more money per organization, but I think you'll reach far less.
You said the core of the software is fairly simple, and some groups don't need anything too complex. Start there, get the core of the software working, and get something online. Approach these groups, get feedback, get them signed up, and start growing. When you have a few customers, you can start adding more features, and building out the software. Don't try to build a monster app all at once, you'll end up over your head, get frustrated, lose interest, and be less likely to ever finish.
Remember, everything takes far longer than expected. Keep it simple to start.
"The core of the software is ultimately pretty simple, however it really needs to be custom tailored to each organization. Some groups want to track whether artists are persons of color, some groups want to have explicit fields for evaluating, and some just want space for a recommendation and a way to attach an in depth review, and every organization believes that theirs is the one true method. These changes are all pretty simple to make, however they are large enough and sometimes architectural enough to make building one monster app and database with support for all the iterations rather imposing. Especially when I can't afford to work on this full time."
"Do I try to make one monster app that can serve every organization, risking complexity, less flexibility, and security? Do I just try and optimize and optimize until it can run happily on a less beefy machine? Or do I have too many pre-conceived notions about how customers think, and I just need to pump out a project, set a price, and start going? Help!"
This seems like a problem that can be solved with some pretty basic OO in your business logic layer, and a little creative database work. One system to run all of the sites will save you headaches in the long run. It will likely save you some money as well. Were I in your situation, I would certainly go with the one central system approach.
Off the top of my head, I'd be creating one set of abstract business logic classes that contain what your clients have in common; and a set of abstract methods that will return objects that contain data they do not. I'd create a class inheriting the abstract one for each client, each containing their custom requirements. I'd create a view layer that can adapt to the custom data, and a data layer that is capable of storing the custom data. Let me know if this is too vague.
"Do I try to make one monster app that can serve every organization, risking complexity, less flexibility, and security? Do I just try and optimize and optimize until it can run happily on a less beefy machine? Or do I have too many pre-conceived notions about how customers think, and I just need to pump out a project, set a price, and start going? Help!"
This seems like a problem that can be solved with some pretty basic OO in your business logic layer, and a little creative database work. One system to run all of the sites will save you headaches in the long run. It will likely save you some money as well. Were I in your situation, I would certainly go with the one central system approach.
Off the top of my head, I'd be creating one set of abstract business logic classes that contain what your clients have in common; and a set of abstract methods that will return objects that contain data they do not. I'd create a class inheriting the abstract one for each client, each containing their custom requirements. I'd create a view layer that can adapt to the custom data, and a data layer that is capable of storing the custom data. Let me know if this is too vague.
Two things:
1) In the same breath you say they're willing to pay and not willing to pay. If they're not willing to pay $40/month, it seems either they're too low on resources to afford even $40 software or your software doesn't provide enough benefit to justify the cost. You have to find a solution to this first or you'll have a long, uphill struggle - regardless of this customization problem.
2) How much do they really, really require the customization? If you talk to the users of any SaaS software, almost every single user will mention a customization they wish they had. But yet they're still using and paying for the software. Your job isn't to provide the 100% complete solution. Your job is to provide enough of a benefit to justify the cost of the software.
1) In the same breath you say they're willing to pay and not willing to pay. If they're not willing to pay $40/month, it seems either they're too low on resources to afford even $40 software or your software doesn't provide enough benefit to justify the cost. You have to find a solution to this first or you'll have a long, uphill struggle - regardless of this customization problem.
2) How much do they really, really require the customization? If you talk to the users of any SaaS software, almost every single user will mention a customization they wish they had. But yet they're still using and paying for the software. Your job isn't to provide the 100% complete solution. Your job is to provide enough of a benefit to justify the cost of the software.
My experience has led me to hold the belief that the organizations I am targeting are more interested/willing to pay a person (and community member) for one time services than they are for ongoing maintenance costs and subscriptions. This may well be my own misunderstanding and lack of marketing knowledge, but that's what it feels like I'm faced with.
This is software that I can only really see reaching at most 40 institutions. All of whom are cutting budgets and are as resistant to change as a not-for-profit tends to be. And it's software that I want to make and want to give them for as cheap as possible. I'm not worried about my own take on this, I just want to give them the solutions they need and make it affordable.
I think I'm just getting too worried and heady. I need to buckle down, trim the fat on the deployment, get it to fit on a low-rent VPS, and spend my time from there really working with companies to make it work.
This is software that I can only really see reaching at most 40 institutions. All of whom are cutting budgets and are as resistant to change as a not-for-profit tends to be. And it's software that I want to make and want to give them for as cheap as possible. I'm not worried about my own take on this, I just want to give them the solutions they need and make it affordable.
I think I'm just getting too worried and heady. I need to buckle down, trim the fat on the deployment, get it to fit on a low-rent VPS, and spend my time from there really working with companies to make it work.
How much revenue can you be generating from this if it went really well? What's the cost of that revenue?
Based on what you have been saying, your total potential revenue doesn't seem to be very high (less than $100K,$200K,$300K??) and the cost to get these clients seems to be involved.Especially considering each instance is effectively its own mini-product with development effort.
Personally, I would suggest you consider this an incredible learning experience and start focusing on another product that can be more profitable.
Going after a niche market is great but the niche market also has to have the money to pay. For example, you may consider oil and gas a niche market, even a small segment of it, but, the money flows like water for them so getting them to pay and pay big (if the ROI is there) can be done.
Anyway, maybe not what you want to hear but worth thinking about.
Based on what you have been saying, your total potential revenue doesn't seem to be very high (less than $100K,$200K,$300K??) and the cost to get these clients seems to be involved.Especially considering each instance is effectively its own mini-product with development effort.
Personally, I would suggest you consider this an incredible learning experience and start focusing on another product that can be more profitable.
Going after a niche market is great but the niche market also has to have the money to pay. For example, you may consider oil and gas a niche market, even a small segment of it, but, the money flows like water for them so getting them to pay and pay big (if the ROI is there) can be done.
Anyway, maybe not what you want to hear but worth thinking about.
Well you could simply package the hosting costs into your general solution/whatever. This way you can avoid directly discussing what hosting you're going to get them and how much it would really cost them.
But it does sound odd. How much is your software going to cost?
I really don't know what your skill set is and/or Rails requirements, but $30-$40 for hosting seems pretty high. My product uses 3 Java Virtual Machines and a Postgres Database and I can get it too perform quite well on a 512MB Digital Ocean instance ($5 a month).
always start with something core to your product. If there is only one feature you can add to your current product, what will you add? If there is only one organization you decide to support, which one will you choose? Choose only one and make people in that organization REALLY happy.
Dare to say no to feature request. As your service grows, always ask your self the question: do I really need that one more feature?
Dare to say no to feature request. As your service grows, always ask your self the question: do I really need that one more feature?
The core of the software is ultimately pretty simple, however it really needs to be custom tailored to each organization. Some groups want to track whether artists are persons of color, some groups want to have explicit fields for evaluating, and some just want space for a recommendation and a way to attach an in depth review, and every organization believes that theirs is the one true method. These changes are all pretty simple to make, however they are large enough and sometimes architectural enough to make building one monster app and database with support for all the iterations rather imposing. Especially when I can't afford to work on this full time.
It seems like the best option for me, and for each of my customers, is to build a custom instance for each organization. That way they can truly get the interface they want. And I think organizations are willing to pay for that customization time! But they aren't willing to pay $40 a month for two dynos on Heroku or other comparable Rails hosting. Even $30 a month for a solid VPS (and then more time for the setup...) seems like a lot of money to organizations that are having to cut work weeks and personnel, for something they already have a sort of reasonable system.
Do I try to make one monster app that can serve every organization, risking complexity, less flexibility, and security? Do I just try and optimize and optimize until it can run happily on a less beefy machine? Or do I have too many pre-conceived notions about how customers think, and I just need to pump out a project, set a price, and start going? Help!