Philosophical question for all you SaaS Developers - Do you see yourself more as someone who provides a service or someone who writes software? As an example of the difference, and the origin of my curiosity, I was talking to a developer who is against using no-code tools like Zappier to solve problems because they wouldn’t be using their software skills.

I see myself as engineer first, I solve problems, if it is solvable using a no-code tool - that's fine by me. In the past where it was relevant, I recommended using MS Access (Gasp!), a Google form (why the heck code a form in HTML when you have that with a built in integration to sheets... Zapier is great for quick and useful integrations - it goes on These are all fine, when you want "quick and dirty", or demands are low, once the client gets an appetite, or demands a supportable tool, one where I can tell him what went wrong, and can provide timely fixes - it turns around... Or as the ever true answer of engineers anywhere: "It depends" 😇

I try to be useful as a human. Sometimes, that means using an off-the-shelf solution. As a hobbyist, sometimes it's fun to do crazy things yourself, such as write a bootloader from scratch for a mini raspberry pi and then build parts of an OS from scratch. But that's not "useful" to others outside of helping me learn and keeping me entertained (better than doomscrolling instagram)

I tell a story about a customer that insisted on using SUSE linux for Hadoop instead of Red Hat, because it was on our supported list and it was European (as were they) so they thought they'd be able to find support people easier. I advised them that while it was technically supported, the support for Red Hat was much more complete and battle-tested, so they would likely find many small edge cases that didn't behave well which would ultimately slow them down, and that they needed to make a deliberate decision about sacrificing velocity to support EU innovation, or going with the best-in-slot option in all the areas of the platform they weren't going to focus on. Turns out SUSE had a bunch of hardware incompatibilities that RH didn't at the time, and they lost more velocity than they expected. There's always hidden costs, so you gotta decide what you're gaining from the more DIY approach - do it if you want to, but understand what you're sacrificing. I'd 100% use Zapier unless I could articulate a good reason why I couldn't, not just because I didn't feel like it, because I could spend that time delta elsewhere in the product. Anyway back to your question, I think in our particular case it's more like the artificial introvert/extrovert spectrum - I'm more the service guy, and he's more the software guy, but we both agree where to focus.

I really think the "S stands for Service" part of SaaS needs to be more prevalent. My former job was as CTO at a biotech; the tech dept built a complex sw platform which was entirely inward-facing. But I still thought of our mission as SaaS. The total nature of SaaS doesn't apply in-house since you don't "sell" your software, but most aspects of it were still relevant. As I explained to our CEO there at one point: SaaS is "Software as a Service". That boils down to 5 things: 1. [Distribution] You don't install the software from a CD on your own computer, it's delivered to you online. 2. [Maintenance] You don't have separate sysadmins who maintain your installation; devops/SRE integrated with the SW engineering team that authored it keeps it running. 3. [Product mgmt strategy] As a result of [1] and [2], you don't have "big bang" releases; there is no "FooSoft 2.0 release", you just keep rolling out changes over time. For "boxed" software you need to suck less with every release; in SaaS the goal is "suck less, every day/week/sprint." 4. [Sales model] [not relevant for in-house] pay-as-you-go on some value- or capacity-driven model rather than "buy once upfront" 5. [Mindset] We are here to create value for users and help them accomplish their goals. It's not about getting the thing out the door and selling copies, it's about keeping a set of users engaged and finding continuous value so they want to keep using it. (Which ties to [3])