Re:If You Build It, They Will Complain
by vinceguidry on Wednesday December 30, 2015 @04:50AM
(#10811468)
> That's a pretty bad MVP then. Usually it takes a lot shorter than that, even for a fairly complex MVP.
I don't think most SaaS companies follow Lean Startup principles. Most of the ones I've had to integrate with have had horrid infrastructures and extremely brittle interfaces. It's a delight for me to actually have properly-maintained documentation available on the web and not an out of date Word document that I have to go back and forth with one of their engineers to understand. Non-standard format implementations are the norm and not the exception.
The general gist I got is that sales guys pluck mediocre, but hard-working engineers from the corporate ranks and build businesses around them. The whole thing is kept together with long hours and elbow grease when it frequently and inevitably breaks.
Re:If You Build It, They Will Complain
by jacquesm on Wednesday December 30, 2015 @05:13AM
(#10811508)
In my practice I see both. In the SAAS domain I see companies with successful models and crappy execution (but they still remain afloat and sometimes even win the race) and I see companies that are textbook examples of how one should implement a business and scale it. And everything in between as well for that matter.
Re:If You Build It, They Will Complain
by tahssa on Wednesday December 30, 2015 @06:34PM
(#10815125)
> That's a pretty bad MVP then. Usually it takes a lot shorter than that, even for a fairly complex MVP.
My math would be:
completion-time = complexity-factor / workers
The article isn't so much about end-users who will complain as much as it is about properly designed software systems as much as it is about in-house and ad-hoc created solutions that are not much more than cobbled together glue.
> Considering that it can take a SaaS company several years just to build an MVP
That's a pretty bad MVP then. Usually it takes a lot shorter than that, even for a fairly complex MVP.
And why limit the comparison to SAAS, there are pretty good reasons why companies may decide not to hop on the SAAS bandwagon that have nothing to do with not-invented-here, it may simply be that they are concerned with the privacy of their users, with the degree of integration that they can provide and with the dependency on an outside party for a (possibly) critical part of their business. They also may not like to leak information that is sensitive to the company or the end-users to third parties only covered by an SLA and not much insight into the design parameters and the degree of care for detail.
A better comparison would be between a piece of closed source off-the-shelf software or a piece of bespoke software created by outsiders but hosted by the company, preferably one for a fixed price to create and a monthly fee to maintain.
Ad-hoc glue stuff is usually extremely fragile (because any changes in the underlying software will break it), uses all kinds of interfaces intended for humans rather than proper APIs and is hard to maintain because of that.
TL;DR; Stuff I build is fragile, therefore you should use SAAS.