SaaS Builders: Where is your undifferentiated heavy lifting?
What are the pieces of your app that aren't core to your unique value prop but you spend way too much time on because you just gotta have 'em?
I'll start:
- Authentication & Authorization
- Customer org structure and membership
- Notifications
- Email digests
- Customer security assessments
- Extracting and integrating data from services in the development pipeline (Project management, source control, CI, deploy, etc)
There are interesting services popping up to address this kind of "undifferentiated heavy lifting" for app developers. I'm wondering what other opportunities exist in this space.
Trending on Indie Hackers
Main pain points are:
At Pirsonal :
Can you elaborate a bit on your "User database management" bullet? I've spent a lot of time in my product building hierarchical team structures to model our customer's organizations and authorization requirements within those structures. Users are members of Offices which are in a Region which are in an Organization and have different permission levels depending on roles within their Org, that kind of thing.
Does that resonate with your user database management challenges? What other problems are you solving in this area?
What you are building makes sense. What I meant is more from a marketing, customer success and sales perspective. Basically, it would be great to easily segment leads, users, paying users from a journey perspective. Also, to be able to make changes in db without the need of technical help (I'm not a developer), in order to make experiments faster.
If you want to replace wordpress let me know :)
Oh man! I was thinking about that today. The reality is that it also gives me "freedom" to make changes all the time :-/.
Yeah it can give you that illusion :)
Usually after a plugin or DB issue folks come to me.
You got an amen there! It will probably be the next step later down the road.
Back in the days I would start to complain about the boundary between backend and frontend. Using REST it was a pain to quickly create an interface between those two, but technology such as GraphQL has made this significantly easier.
Emails have also been a problem, but I believe there are possibilities to solve those problems using libraries instead of products. (See my other comment here, and my project over at https://github.com/skyhop/mail.)
One thing which I believe is going to be a big thing in the future are data pipelines, or whatever people like to call them. Many big data projects rely on many small processing units which are all operational all the time, and should be able to be used without too much hassle for small tests, which may or may not be included within the pipeline. I believe such project is one of the few ways to keep large data processing projects up and running in the long term. For this to succeed you'd need knowledge and integration with many languages all at once.
It was CSS for me. I would literally stop progress trying to be 'cool' and 'modern'.
I am not in anyway a designer or creative. (aka, NOT focusing on my strengths)
My moment of truth came when I realized that in the my industries upper-class (my eventual target market) they spend in the upper-thousands monthly on products that reminds me of Microsoft Windows 95 or DOS.
Fast forward to today I simple focus on validation of features. Anything that doesn't get feedback in a few days its trashed (or added to the bottom of the list). Anything that causes my users to want to say "send me the link so we can start using it" gets added to the top.
No where in there do they say "Does it look pretty?" or "Is it Bootstrap 3 or 4 or 5?". But, I supposed I had to learn the hard way.
I wouldn't say "popping up". On the back end powerhouses like AWS, Stripe, Microsoft etc. are going after the full solution. It's the front end where monetization for shared heavy lifting has not come through.
Uclusion is using React and Material UI on the front end but mostly we have to fend for ourselves.
Oh for sure - this is very far along at the infrastructure level.
But we're also seeing commoditization move up the stack to the application layer - Auth0 for authentication, a million email gateways, customer comms, etc. There are so many options to buy vs. build these days. It feels like we're moving to a world where you will be able to just drop your business logic into an ecosystem of services that gives you all the common functionality with little effort (for a price). It's interesting to me to think about what that might look like and what can be built to get there.
You are absolutely right on the FE side - the tooling has come a long, long way and is only getting better but interfaces are incredibly bespoke. Maybe they need to be?
Maybe you are seeing it move up the stack if you are building a website. If you are building an app then most of the JavaScript is on you. We do have libraries like Material UI, AWS Amplify, React, Quill, LocalForage, Lodash and browsers themselves do a lot but the code is still monolithic and very hard to write.
This comment was deleted 5 years ago.
I feel you! I figured that most of my own problems had to do with the structure of my codebase. Given email is quite a complex topic on its own it can too easily lead to unmaintainable spaghetti code.
Although probably not the right language (written in C#), I have solved a bit part of this problem by writing a library which enforces a strong separation between the mail template, data and the code which triggers an transactional email. You can find the library at https://github.com/skyhop/mail.
A blog post in which I have described the underlying logic, as well as the mental model can be found at https://corstianboerman.com/2019-05-27/rendering-razor-views-by-supplying-a-model-instance.html.