5 ms·

As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server gene

As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server generated. PJAX style partial page updates is (mostly) dynamic enough. The maintenance burden of operating a JavaScript frontend is too high to justify for a 1-2 person team. The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future. I began doing Ruby and Ruby on Rails (RoR) development in 2006. Ruby had been around for awhile but the growing popularity of RoR was driving a lot of changes in the ecosystem in those years. It was a fun time but I was working for a large company that allowed me the time to keep up with everything. I see today’s frontend and container ecosystems in the light of that experience. I’m now more content to wait it out and let the dust settle as much as I enjoy learning new technology.

ticmasta 6y ago
You didn't seem to get much of a reaction, probably because of your recommendations to go with proven (read: old & boring) tech, but I appreciate it. Front-end churn is real and, coupled with rapidly evolving and ever-abstracting containerization approaches, staying on top of it is a full-time job, best done as an employee.
- zomgwat 6y ago
  Thanks! Best done as an employee is spot on.
  - herodoturtle 6y ago
    If I may chime in here, I would humbly suggest that it is best done by whoever enjoys it. Sometimes that might be your employee, and sometimes that might be you. I guess it depends on where your passion lies, and what your objectives are? I imagine that achieving one's financial ambitions in a relaxed and enjoyable work environment is great - irrespective of which part of the stack one enjoys tinkering with the most.
  - vmception 6y ago
    I use people I employ as my education I usually assume a role like engineering manager and learn from the teams feedback, challenges and commits Making money, getting tax deductions and sometimes research credits
- arcturus17 6y ago
  FWIW, I disagree with GP. I'm more productive in React than in SSR, and I'm much better at code design and architecture with it. React is pretty much old and boring by now. Just build in what you know.
  - zomgwat 6y ago
    > Just build in what you know. Yup, I agree. The apparent difference in our situations is that you know React and everything that comes with it. It seems like that'd be a good choice for you. I'm not proficient in any of the currently popular frontend architectures. Gaining that proficiency and moving a 10+ year old product to a SPA type architecture would be a massive investment. I enjoy learning new things and pushing things forward but I can't justify that investment when it comes to the frontend. Instead, I invest in other areas to move forward in.
  - edgyquant 6y ago
    Yeah same here. I did years of generating JS heavy frontends with PHP for Ajax apps. Once I learned to keep all data on the server and functionality on the client I’ve become so much more productive when slapping together an MVP with react (and any backend capable of spinning up a rest, though I prefer python or go at this time.)
herodoturtle 6y ago
I'm glad you shared this. I've been reading the comments here with much interest but simultaneously also a sense of impostor syndrome, for I've been running my one-man SaaS on generic LAMP since 2005, and aside from adopting jQuery early on, I haven't much touched any other piece of exciting tech that's come out since. My old and boring stack works just fine on the VMs that it runs on, and and continues to support me and my family financially with little to no downtime and decent work/life balance. Of course I'm aware of the cons of programming in PHP versus other languages, but after 20 years of coding in it, I like to think that my code isn't all that bad. Still, I'm reading some comments here and feel like I'm waaay behind the tech curve with my use of such an old stack, and am somewhat scared to admit it. Your comment brought me relief :)
- blackrock 6y ago
  Nice work. Your SaaS has been providing you income for 15 years. Tell us about your SaaS. What were your challenges early on? What were your hardships? And what were your lessons learned? What would you do differently?
  - herodoturtle 6y ago
    > Tell us about your SaaS. I'm a private guy. But I will say that it's a Greek startup, birthed in my English dorm room (Comp Sci grad; taught myself programming at age 11 by reverse engineering GORILLA.BAS; shout-out to all you DOS 6.22 babies #486dx2 #duneiichani #zerocool #snowcrash #bbs #qbasic #mode13h #nehe #0x5f3759df #lamp #vi). > What were your challenges early on? From a life standpoint, it would have to be student loans. But in crisis lies opportunity, because by working to pay these off, I programmed database integration layers between a bunch of local companies that ultimately led to a sweet SaaS system. From a technical standpoint, there were many fun challenges, such as 2,000+ days of uptime with multi-master replication. But the biggest challenge was probably getting an early version of Quixote and a cranky SOAP protocol to talk to a bunch of SAP EDRs; that's when I learnt people skills. > What were your hardships? The usual stuff... paying the rent, feeding myself, no free time. It was all systems go back in the day, and dating wasn't really an option; but I'm thankful for lots of genuine friends, who welcomed my intermittent visits. From a business standpoint, the biggest hardship was my constantly wrestling with the idea that I could do anything but I couldn't do everything. Once I concluded that exercise I found peace, and then everything else just clicked into place. > And what were your lessons learned? 1. There are multiple SaaS strategies. One such strategy is to go super niche. Emphasis on super. 2. Going super niche doesn't scale, but it will allow you to prioritise free time - whilst living a steady, balanced lifestyle. 3. To go super niche, build your SaaS in such a way that you can run it from your mobile phone. 4. Always keep an eye on your phone, so that when the need for customer comms arises, it flows with elegant efficiency. 5. The quality of your communication with your customers is your competitive edge. Excel at this to justify your pricing. 6. Optimise all your business processes around minimising your phone's notifications - the goal is to maximise your free time. 7. At your leisure, routinely check in on your customers for a friendly catch-up. This enhances your competitive edge and bargaining power. 8. Always add value to your customers, and if you can't add value, walk away. You'd be surprised how much you can earn and still add value. 9. Enjoy time. Discover who you are. Explore life with your family and friends. Exercise your body and mind outdoors. 0. Help others. Volunteer your skills and resources. I advise several entities and it brings me great joy. > What would you do differently? Perhaps I'd have picked a name that was easier to recall, and easier to spell. But when you go super niche, it doesn't really matter what name you pick.
djitz 6y ago
After finally getting a SaaS product off the ground a few months ago, I cannot agree more. I fell into the shiny object trap so many times before. This time, I stuck to what I know inside and out and jazzed things up where I could. Long live the monolith.
2ion 6y ago
> The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future. VMs (even self-updating ones) can be built easily using templates with tools like Packer. And without containers, a lot of things can be done very simply, often more easily, using modern versions of systemd. You get ad-hoc namespacing, ro storage, resource (CPU/network/memory/I/O) limiting, CPU pinning, private networking, logging and much more by the power of a single line more in the .service file. Throw a tight selinux configuration on top of it and you got a pretty good per-service, secure "container" on your system. Additionally, you get smart .service dependency handling, service auto-restarts, notified restarts if you care to implement it, scheduled tasks, and so on in a multiprocess environment that makes you just sad thinking back to having to resort to stuff like supervisord.

ticmasta 6y ago

You didn't seem to get much of a reaction, probably because of your recommendations to go with proven (read: old & boring) tech, but I appreciate it. Front-end churn is real and, coupled with rapidly evolving and ever-abstracting containerization approaches, staying on top of it is a full-time job, best done as an employee.

zomgwat 6y ago
Thanks! Best done as an employee is spot on.
- herodoturtle 6y ago
  If I may chime in here, I would humbly suggest that it is best done by whoever enjoys it. Sometimes that might be your employee, and sometimes that might be you. I guess it depends on where your passion lies, and what your objectives are? I imagine that achieving one's financial ambitions in a relaxed and enjoyable work environment is great - irrespective of which part of the stack one enjoys tinkering with the most.
- vmception 6y ago
  I use people I employ as my education I usually assume a role like engineering manager and learn from the teams feedback, challenges and commits Making money, getting tax deductions and sometimes research credits
arcturus17 6y ago
FWIW, I disagree with GP. I'm more productive in React than in SSR, and I'm much better at code design and architecture with it. React is pretty much old and boring by now. Just build in what you know.
- zomgwat 6y ago
  > Just build in what you know. Yup, I agree. The apparent difference in our situations is that you know React and everything that comes with it. It seems like that'd be a good choice for you. I'm not proficient in any of the currently popular frontend architectures. Gaining that proficiency and moving a 10+ year old product to a SPA type architecture would be a massive investment. I enjoy learning new things and pushing things forward but I can't justify that investment when it comes to the frontend. Instead, I invest in other areas to move forward in.
- edgyquant 6y ago
  Yeah same here. I did years of generating JS heavy frontends with PHP for Ajax apps. Once I learned to keep all data on the server and functionality on the client I’ve become so much more productive when slapping together an MVP with react (and any backend capable of spinning up a rest, though I prefer python or go at this time.)

herodoturtle 6y ago

I'm glad you shared this. I've been reading the comments here with much interest but simultaneously also a sense of impostor syndrome, for I've been running my one-man SaaS on generic LAMP since 2005, and aside from adopting jQuery early on, I haven't much touched any other piece of exciting tech that's come out since. My old and boring stack works just fine on the VMs that it runs on, and and continues to support me and my family financially with little to no downtime and decent work/life balance. Of course I'm aware of the cons of programming in PHP versus other languages, but after 20 years of coding in it, I like to think that my code isn't all that bad. Still, I'm reading some comments here and feel like I'm waaay behind the tech curve with my use of such an old stack, and am somewhat scared to admit it. Your comment brought me relief :)

blackrock 6y ago
Nice work. Your SaaS has been providing you income for 15 years. Tell us about your SaaS. What were your challenges early on? What were your hardships? And what were your lessons learned? What would you do differently?
- herodoturtle 6y ago
  > Tell us about your SaaS. I'm a private guy. But I will say that it's a Greek startup, birthed in my English dorm room (Comp Sci grad; taught myself programming at age 11 by reverse engineering GORILLA.BAS; shout-out to all you DOS 6.22 babies #486dx2 #duneiichani #zerocool #snowcrash #bbs #qbasic #mode13h #nehe #0x5f3759df #lamp #vi). > What were your challenges early on? From a life standpoint, it would have to be student loans. But in crisis lies opportunity, because by working to pay these off, I programmed database integration layers between a bunch of local companies that ultimately led to a sweet SaaS system. From a technical standpoint, there were many fun challenges, such as 2,000+ days of uptime with multi-master replication. But the biggest challenge was probably getting an early version of Quixote and a cranky SOAP protocol to talk to a bunch of SAP EDRs; that's when I learnt people skills. > What were your hardships? The usual stuff... paying the rent, feeding myself, no free time. It was all systems go back in the day, and dating wasn't really an option; but I'm thankful for lots of genuine friends, who welcomed my intermittent visits. From a business standpoint, the biggest hardship was my constantly wrestling with the idea that I could do anything but I couldn't do everything. Once I concluded that exercise I found peace, and then everything else just clicked into place. > And what were your lessons learned? 1. There are multiple SaaS strategies. One such strategy is to go super niche. Emphasis on super. 2. Going super niche doesn't scale, but it will allow you to prioritise free time - whilst living a steady, balanced lifestyle. 3. To go super niche, build your SaaS in such a way that you can run it from your mobile phone. 4. Always keep an eye on your phone, so that when the need for customer comms arises, it flows with elegant efficiency. 5. The quality of your communication with your customers is your competitive edge. Excel at this to justify your pricing. 6. Optimise all your business processes around minimising your phone's notifications - the goal is to maximise your free time. 7. At your leisure, routinely check in on your customers for a friendly catch-up. This enhances your competitive edge and bargaining power. 8. Always add value to your customers, and if you can't add value, walk away. You'd be surprised how much you can earn and still add value. 9. Enjoy time. Discover who you are. Explore life with your family and friends. Exercise your body and mind outdoors. 0. Help others. Volunteer your skills and resources. I advise several entities and it brings me great joy. > What would you do differently? Perhaps I'd have picked a name that was easier to recall, and easier to spell. But when you go super niche, it doesn't really matter what name you pick.

djitz 6y ago

After finally getting a SaaS product off the ground a few months ago, I cannot agree more. I fell into the shiny object trap so many times before. This time, I stuck to what I know inside and out and jazzed things up where I could. Long live the monolith.

2ion 6y ago

> The second thing I’ve done is avoid containers. VMs work fine for many types of applications. That’s especially true if provisioning and configuration is mostly automated. A product like Google Cloud Run looks interesting for a few low-volume backend services that I operate. Containers are a good fit there because it simplifies operations rather than increases complexity. The core infrastructure will remain VMs for the foreseeable future. VMs (even self-updating ones) can be built easily using templates with tools like Packer. And without containers, a lot of things can be done very simply, often more easily, using modern versions of systemd. You get ad-hoc namespacing, ro storage, resource (CPU/network/memory/I/O) limiting, CPU pinning, private networking, logging and much more by the power of a single line more in the .service file. Throw a tight selinux configuration on top of it and you got a pretty good per-service, secure "container" on your system. Additionally, you get smart .service dependency handling, service auto-restarts, notified restarts if you care to implement it, scheduled tasks, and so on in a multiprocess environment that makes you just sad thinking back to having to resort to stuff like supervisord.