←back to thread

413 points martinald | 1 comments | | HN request time: 0.199s | source
Show context
nine_k ◴[] No.46197061[source]
Had the cost of building custom software dropped 90%, we would be seeing a flurry of low-cost, decent-quality SaaS offering all over the marketplace, possibly undercutting some established players.

From where I sit, right now, this does not seem to be the case.

This is as if writing down the code is not the biggest problem, or the biggest time sink, of building software.

replies(28): >>46197121 #>>46197162 #>>46197191 #>>46197790 #>>46198132 #>>46198182 #>>46198282 #>>46198425 #>>46198498 #>>46198608 #>>46198655 #>>46198747 #>>46198991 #>>46199214 #>>46199310 #>>46199646 #>>46199706 #>>46201118 #>>46201177 #>>46202111 #>>46202477 #>>46202670 #>>46203360 #>>46204030 #>>46204863 #>>46204917 #>>46207989 #>>46214063 #
martinald ◴[] No.46197121[source]
It is happening though internally in businesses I've worked with. A few of them are starting to replace SaaS tools with custom built internal tooling. I suspect this pattern is happening everywhere to a varying level.

Often these SaaS tools are expensive, aren't actually that complicated (or if they are complicated, the bit they need isn't) and have limitations.

For example, a company I know recently got told their v1 API they relied on on some back office SaaS tool was being deprecated. V2 of the API didn't have the same features.

Result = dev spends a week or two rebuilding that tool. It's shipped and in production now. It would have taken similar amount of time to work around the API deprecation.

replies(3): >>46197614 #>>46197637 #>>46198649 #
nugger ◴[] No.46197637[source]
I don't understand the timelines here at all.
replies(1): >>46199196 #
figers ◴[] No.46199196[source]
We were paying for Salesforce, then built the features we needed to do the same tracking into our interal tool and got rid of Salesforce to save money and simplify the data internally across departments
replies(1): >>46199283 #
raw_anon_1111 ◴[] No.46199283[source]
And now you have to spend money on developers for a system that “doesn’t make the beer taste better”. Does it give you a competitive advantage in the market?
replies(3): >>46199980 #>>46201179 #>>46204148 #
1. torginus ◴[] No.46204148[source]
We did the same. We replaced a proprietary build system with our own. The SaaS product we used was super expensive, had a very gougy licensing scheme, had a bunch of features that either didn't work for us, or were so overcomplicated, that we ended up not using them. Before the rewrite, we bypassed like 90% of the internal features, and relied on custom scripts to do everything.

Every SaaS feature in my experience ends up being a mess due to having to support a billion use cases, and figuring it out is more trouble than its worth, might not be able to do what you want, might be buggy.

But even if you do all that stuff, you end up with a mess that can be replaced with 5 lines of shell script. And many more people know shell scripting than figuring out the arcane BS that goes on inside that tool.

It's the eternal lowcode story.

> 'doesn’t make the beer taste better'

I'd say it did. Having a CI/CD pipeline where you don't have to wait for other people's builds, the build logic is identical to what's running on dev PCs, and everything is all-around faster, and more understandable (you can read the whole source) makes testing easier, and surprises less frequent.

All in all, making a hour-long CI/CD turnaround time into 5 minutes or less has been an incredible productivity boost.