2
11 Comments

What do you think of custom-software-development-as-a-service subscription model?

We develop custom software for agtech startups and established companies in the agricultural space at www.nielswart.com. As any software agency and freelancer know there is quite a lot of risk involved in fixed pricing as estimation can be tricky. Clients on the other hand don'

  1. 1

    Hello! I agree that finding a reliable custom software development service provider is not an easy task. Therefore, I recommend looking at the experience of implemented projects of companies https://www.cleveroad.com/blog/custom-software-development/

  2. 1

    Definitely, a tight niche that would try this, but it might work in certain cases. I mean there are already a lot of custom software development companies out there that offer technical support constantly for the service they've provided. For example, I've collaborated with https://develux.com/custom-software-development one year ago for the development of an app and they are still on top of it today, no need for me to pay a subscription for their services. Though of course, there might be certain areas where this could catch on.

  3. 1

    I think it makes sense in your situation when you're using a specific technology both you and the client are familiar with, especially if the work is repetitive. But I don't think that model makes sense for project centric work because the goals are not aligned. The client wants the project to be done as quickly as possible but you guys would want the opposite.

    If you're referring to developers who need to hire developers to help with client work, I don't think they would get that help from an agency. Especially for regular ongoing monthly work. They're probably going to find an independent dev.

    1. 1

      Thanks for the reply @Mailman. The idea is to let clients downgrade and upgrade (or even cancel) plans on a month to month basis (lowest being maintenance mode which include bug fixes and support only). So they basically choose how fast they want to complete their project by selecting the plan that suits their budget and required delivery timelines. We definitely want them to stay subscribed for longer, but we never enforce that - only by providing discounts on an annual subscription.

      Do you think that alleviates the concern of goals not being aligned?

      As for using independent devs to "join" a development team, I totally agree, but that is not really our target market - we target clients that do not have that capacity and are not in the position or event want to build or manage a team of devs (independent or in -house), e.g agtech startups or established ag businesses wanting to develop a tech product.

      1. 1

        I get that you're trying to improve something and make it better...But what is your goal here? Are you trying to fix something based on customer feedback or losing a deal?

        One of the first things you mentioned was the risk developers take when bidding on projects. Is this the problem you're trying to solve?

        Or is this simply a business idea to adopt the subscription model to custom development work?

        Or are you trying to provide a service that is more simple for your customers to understand to make it easier for them to buy from you?

        For custom software projects there is always a clearly defined scope of work with timelines. How does this new model benefit the customer over a fixed price contract?

        Custom software projects usually have a business driver behind them, why would I want to downgrade or upgrade the creation of my software if I know what software I need and by when? Yes, having flexible options is usually a good thing but does that apply to custom software projects? In what situation would I want to slow down my software project?

        I can tell you from experience that selling this type of service is extremely difficult and you would need to build a really good sales team and probably have to completely change how your entire company operates. Businesses do not purchase IT Consulting services by reading a nicely designed website with price tables and features listed. They enter into software development engagements based on trust which has to be established and built through a very specific processes and interactions. The reason I know this is because I used to sell enterprise software solutions to Fortune 500 customers using the Account Based Marketing sales methodology. And our company literally offered monthly subscription IT services like remote Oracle DBA, desktop end-user support, network admin/support, etc. And selling annual subscription contracts was hard as hell. I think part of the reason it's hard is because people don't want to work on potentially sensitive software projects for their business, with a complete stranger who they have never met. Security, trade secrets, HIPPA, customer data, all kinds of reasons.

        1. 1

          I don't totally agree with the premise that all custom software projects are clearly defined ito scope or timelines and I think that this is where we diverge in our views.

          So I totally agree that if you have a fixed scope that can be clearly defined with certain timeline requirements, fixed pricing is basically the way to go. Either as a fixed monthly fee for x months or a once off fee paid in whatever way is agreed. (Which does not really differ much from a subscription model)

          In my experience and with the specific work that I do, projects with a well defined and fixed scope are rarely the case.

          So the problems I'm trying to solve with this model are:

          1. Reducing risk for the developer and the client for not so well defined ongoing work. We develop a client's core software product and the requirements and business goals change quite rapidly. We try to make it like having your own product development team.

          2. Making the sales conversation easier with clearly defined pricing, instead of long analysis and proposal work. If we don't do proper homework, we can easily underestimate (more often than over estimating) and therefore you start to build in larger risk margins and you also have to factor in the time and cost of estimation and developing proposals even for projects that are not signed.

          3. Hourly billing is the standard in most projects we do and most clients prefer this over fixed pricing for various reasons, but variable scope and uncertainty being the main drivers. The problem however is that client and developer goals are misaligned and quality assurance usually suffers because no one is incentivized to build well tested code, but to roll out features as fast as possible. We are incentivized to take longer and not to increase internal efficiencies. Also the only honest way we as developers can increase profitability is by raising our rates, which has its limits and is much harder to sell. This just doesn't really make sense.

          Regarding your comments about trust relationships. I wholeheartedly agree. We also don't expect the pricing model to really influence the sales process. The idea is not to have pricing page with a buy button which takes you to payment form - I know that will never work. The pricing page is just to give the prospect as much of the information upfront and then start the normal sales process as usual.

          Thanks again, it gave me some things to think over, I appreciate it.

          1. 1

            There is a big difference between existing clients/referrals and new clients. Since existing clients/referrals will do pretty much anything you tell them to do, all my comments were based on a situation where you're trying to win over a new customer. Wasn't the point of this thread to explore/brainstorm trying to sell the service to new customers? Or were you trying to explore potential options for existing clients?

            I don't think we have a difference of opinion. I just assumed the discussion was in reference to new customers since your initial post was a question for the IH community, which I would label as new customers.

            To clarify, is this discussion in reference to getting New Clients or working with Existing Clients? All my comments were about new customers only.

            #'s 1-3 above - Here are my comments and questions.

            #1 - If they treat your team like employees and pay you like hourly consultants, isn't this the ideal arrangement? If you have concerns about frequently changing projects/priorities, why don't you simply voice your concerns with them? And to cover your own ass, just document your thoughts/concerns/ideas in an email and make sure they reply to it so you have proof that the discussion took place and they clearly understood your message. Software development projects seem to always have some sort of office politics and drama so you have to protect yourself with documented hard evidence just in case the sh|t hits the fan someday and someone tries to throw you under the bus. When jobs/money/security is at stake, crazy things can happen in the business world. Trust your gut, if you don't feel good about something, you're probably right. And who is to say that the person who is currently making all the decisions for the product knows better than you? They're human so they could be making lots of costly mistakes...and everyone is accountable to someone.

            #2 - Have you ever considered charging the client for your time spent creating their proposals? Why should you have to create them if the deal is already closed? You should be able to just write a quick high level summary. Otherwise, it's just doing consulting work for them. Proposals are for deals you haven't won yet, not for deals you already have on lock.

            I think you should add the hours and label them under Project Management time, Discovery time, Assessment, Scoping, or something similar that makes sense and looks normal. and just bill them at your standard hourly rate. Why? Because it requires your expertise, experience, knowledge, and time so it's exactly the same as consulting work. And you're only doing it to protect them, help their business, help them make money, help them avoid costly problems, reduce their risk, etc. You're not doing it for your own health, how could the client not want to pay for the work when there is no benefit in it for you?

            In the past I've had many situations where I had to bill the client for the initial assessment/scoping/system health check work mainly because I'm not a consultant, I was a sales person so I had to use actual consultants to create my proposals, conduct assessments, gathering requirements, scoping, etc. Since there was an overhead cost to using their time, eventually my boss told me that he was going to kick my ass if I kept using our benched consultants for all my proposals. I thought it was because I was still new and I hadn't yet proven myself in the company but that wasn't it. I later learned that all the strong sales people charged for proposal creation time and the less experienced sales people were too scared to do it because they were afraid of making the customer angry. You should think of it as a sales pitch/meeting so to prepare, you should review your compelling arguments, the value of the proposal, the benefits to them, why it's important and necessary work. If you explain these things correctly, it will be painfully obvious why it only makes sense to bill for the hours you spent on it. And since you're a developer, it's even more so because you could be doing billable work in that time instead.

            Only you know the answer to this based on how long you've worked with the client, but maybe you just include in the invoice in an ethical way without bringing it up at all? Whey would they even read the invoice to begin with anyway? They might but there's a 50% that after you bill them for the time, that it never even get's brought up ever again. A lot of people don't review their invoices because the company just pays them.

            #3 - In my opinion, all you can do is be yourself by doing the basics and this is how you keep your mind right and feel proud about the work you're doing. Work hard, be honest, don't steal or hurt people, etc. You didn't invent consulting or technical staff augmentation...but more importantly, think about how much effing money they're going to make forever after your done with the system? You're not the javascript salvation army. And in your specific situation, developing the core product which is a business responsibility, there is only so much in your control so don't feel bad about business problems that are out of your hands. And keep in mind that this isn't the first rodeo for all the people involved on the project, so everyone knows how the startup technology creation lifecycle works, you can't feel bad just because certain things aren't as efficient as they can be. Maybe they need more project management involvement? I say you revisit your priorities and come up with a different strategy to make as much money as possible while you're in this lucky hourly situation. As long as you maintain your integrity and values, working harder and billing more hours only gets them to their goals faster so it's a win win situation if you ask me. Forget about their finances, you're a programmer, that's the CFO's job brother. Your job is to convert code to cash in your wallet! Stress kills.

            My final point....at least until you come up with a real solution, I think you should communicate with your client more to get rid of your anxiety or frustrations with all the changes. Talking about it will make you feel better about it. Buy him a steak and drink a few beers and just speak openly about everything. If you don't feel comfortable having these types of discussions, you're going to have to learn sometime anyway, so you might as well start now. Business is nothing but dealing with uncomfortable conversations and problems....so the sooner you get a thicker skin and learn to have these shitty discussions, the better off you'll be.

            Sorry if I missed the mark on anything, it's super late...

            1. 1

              Thanks for your thorough response and sorry for my late reply. I had a very tough schedule the last month to meet some deadlines.

              I appreciate your insight and suggestions and I will think a bit more about my options going forward.

              1. 1

                I was really tired when writing that, here's my main point.

                If I were in your position, I would use the saying "it's better to ask for forgiveness than permission." Just bill them for your time spent and see what happens. I think it's common knowledge that proposals are written and submitted BEFORE you win a client. AFTER you've won the client already (which you clearly have), that type of work is billable hours. How could it not be? And if they were to fight it, in a worse case it's a billing revision but if they challenge it, they would be labeling themselves as unfair people because if they were in your shoes, they would also want to be paid for their time spent.

  4. 1

    This comment was deleted 4 years ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 47 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 27 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments