3 ms·

I have seen SaaS application owner who was thinking he could do SaaS with low code and cut the costs. On his place I would be selling "low code" but that guy w

by ozim 5y ago

I have seen SaaS application owner who was thinking he could do SaaS with low code and cut the costs. On his place I would be selling "low code" but that guy was severely shortsighted.

jacquesm 5y ago
I'm sure there are countless examples of this. But even so: there is a vast number of applications out there that are more complex than 'excel' and much simpler than 'bespoke software', and that niche is widening as these platforms become more capable.
- ozim 5y ago
  I don't see it that way. In the moment that you want to have multiple users working on the same Excel/Dataset and changing formulas/calculations/rules it is basically bespoke software. Well good luck changing stuff by each employee on their own. Because there will be appointed one employee who will be making changes for that and as such "Excel" grows he will end up not working on whatever he was expert for but on maintaining that bespoke software. I don't see low code platforms solving maintenance issue, they promise that you will be able to write code quicker and without developers. When you get one of the employees working full time on updating and maintaining some low code, he becomes developer. Well you pay him the same salary and you don't have to shell out money for Java/.NET guy but you will pay for license on that platform. While you will be able to hire next Java/.NET dev, good luck finding that specific platform developers. Salesforce if probably going into good direction building their "consultants" base, where I don't see fundamental difference between "consultant" and "developer". Maybe you don't need consultant day in/ day out but they still charge like you would have them hired full time. In the end I am biased because I am a dev and businnes risks I see are from different side than business people. But as with Salesforce or any other CRM I see it as a huge lie as the system gets bigger and complex there is no running away from dedicated people doing maintanence. You just tie yourself to a proprietary tool where with Java/.NET you still tie yourself to an ecosystem but it is basically for free and you keep unbounded flexibility.
  - jacquesm 5y ago
    > I don't see it that way > In the end I am biased because I am a dev I agree :) Unbounded flexibility for one party spells 'nightmare' for another... as with every other tool: use where applicable and don't try to stretch it too much to solve something it wasn't intended for and you'll be fine. Your job is not at risk from low/no code tools. It will simply open up a different class of problems to an intermediate level of automation.
    - ozim 5y ago
      Thanks for agreeing :) Unbounded flexibility is what most of business people expect. I am always a bit sad when I see the look on their faces when I have to tell them that their great idea is going to cost 5x more because they wanted their previous great idea ASAP/cheap/#timeToMarket and we have to build on top of that. I just imagine how it must look when someone tells "sorry, it is not possible, because our low code platform does not support something like that".

by ozim 5y ago

I have seen SaaS application owner who was thinking he could do SaaS with low code and cut the costs. On his place I would be selling "low code" but that guy was severely shortsighted.

jacquesm 5y ago

I'm sure there are countless examples of this. But even so: there is a vast number of applications out there that are more complex than 'excel' and much simpler than 'bespoke software', and that niche is widening as these platforms become more capable.

ozim 5y ago
I don't see it that way. In the moment that you want to have multiple users working on the same Excel/Dataset and changing formulas/calculations/rules it is basically bespoke software. Well good luck changing stuff by each employee on their own. Because there will be appointed one employee who will be making changes for that and as such "Excel" grows he will end up not working on whatever he was expert for but on maintaining that bespoke software. I don't see low code platforms solving maintenance issue, they promise that you will be able to write code quicker and without developers. When you get one of the employees working full time on updating and maintaining some low code, he becomes developer. Well you pay him the same salary and you don't have to shell out money for Java/.NET guy but you will pay for license on that platform. While you will be able to hire next Java/.NET dev, good luck finding that specific platform developers. Salesforce if probably going into good direction building their "consultants" base, where I don't see fundamental difference between "consultant" and "developer". Maybe you don't need consultant day in/ day out but they still charge like you would have them hired full time. In the end I am biased because I am a dev and businnes risks I see are from different side than business people. But as with Salesforce or any other CRM I see it as a huge lie as the system gets bigger and complex there is no running away from dedicated people doing maintanence. You just tie yourself to a proprietary tool where with Java/.NET you still tie yourself to an ecosystem but it is basically for free and you keep unbounded flexibility.
- jacquesm 5y ago
  > I don't see it that way > In the end I am biased because I am a dev I agree :) Unbounded flexibility for one party spells 'nightmare' for another... as with every other tool: use where applicable and don't try to stretch it too much to solve something it wasn't intended for and you'll be fine. Your job is not at risk from low/no code tools. It will simply open up a different class of problems to an intermediate level of automation.
  - ozim 5y ago
    Thanks for agreeing :) Unbounded flexibility is what most of business people expect. I am always a bit sad when I see the look on their faces when I have to tell them that their great idea is going to cost 5x more because they wanted their previous great idea ASAP/cheap/#timeToMarket and we have to build on top of that. I just imagine how it must look when someone tells "sorry, it is not possible, because our low code platform does not support something like that".