3 ms·

So I built 2 different SaaS products out of my own consulting agency (that actually made it to market). And I did them both differently. I lucked into a situa

So I built 2 different SaaS products out of my own consulting agency (that actually made it to market). And I did them both differently. I lucked into a situation with one product where basically a client needed a tool to do a job but it was something we had solved like 6 times in the past couple of years, so we knew there was a market for it. So we did team up with him on it essentially. He had no interest in the product part, just needed his problem solved, but he liked the idea of a discount on his dev fees. So what we did is cut our dev fees to him (still covering our costs), he got a worldwide non-exclusive license to use the product but not to resell, and we kept the rights to resell. So in the end, he got a product & free support for a period of time (at a steep discount) and we got a money maker, not great money but real money. The second time I just sucked it up and used off-time and down-time from consultants and myself to build the product. While it took us much longer, and nearing launch we had to dedicate more time to it which meant me funding a couple of people full time (versus just down time hours), I would say I preferred this route. It meant we didn't have to compromise on features, or develop a feature we felt/knew had no basis to be in the product. What I liked was we could focus on making a product first, which is hard to do when you are essentially solving someone else's problem. I'd do this route again over the other just for the simplicity, yes more risk, yes longer time to market, but much less of a compromise which you then turn around and spend months fixing later.

utopian3 7y ago
> What I liked was we could focus on making a product first, which is hard to do when you are essentially solving someone else's problem. Isn’t solving someone else’s problem the point of a product?
- davismwfl 7y ago
  Yes, I agree that is the point of building a product. The one catch there, is when you have a client paying for development there are compromises and time to market considerations to which can affect having a product available to the wider audience. In our case, we were working both with the client we were building the product for initially and also we had prospected a number of other clients and were trying to get an MVP out that solved the problem and then iterate. However, that didn't work for the primary client and a number of things he wanted in his MVP were not good general product market fit, which made it harder for us to manage the timing & expectations. So while it was overall less expensive initially out of my pocket, the timeline was dictated/dominated by the client and special features they needed which took away from making a generic product that we could've had in the hands of others faster. Which in the end meant we had more product/development churn then if we had gotten the more generic 80% MVP out for a wider audience. That's what I meant by we could've focused on general product first.

utopian3 7y ago

> What I liked was we could focus on making a product first, which is hard to do when you are essentially solving someone else's problem. Isn’t solving someone else’s problem the point of a product?

davismwfl 7y ago
Yes, I agree that is the point of building a product. The one catch there, is when you have a client paying for development there are compromises and time to market considerations to which can affect having a product available to the wider audience. In our case, we were working both with the client we were building the product for initially and also we had prospected a number of other clients and were trying to get an MVP out that solved the problem and then iterate. However, that didn't work for the primary client and a number of things he wanted in his MVP were not good general product market fit, which made it harder for us to manage the timing & expectations. So while it was overall less expensive initially out of my pocket, the timeline was dictated/dominated by the client and special features they needed which took away from making a generic product that we could've had in the hands of others faster. Which in the end meant we had more product/development churn then if we had gotten the more generic 80% MVP out for a wider audience. That's what I meant by we could've focused on general product first.