Hacker News Reader

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 :)

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?

> 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.

Nice response. You should put an extra new line between your bullet points. HN mangles your bullet points text if you don’t.

Thanks, I enjoyed writing it.

Yeah there was a second's regret as I saw my submission's resulting format.

An interesting trick by the devs, this temporarily available edit window.

But fair is fair. I like it.

Good job HN devs.

#486dx2 #zerocool #gorilla.bas #mode13h #0x5f3759df #lamp #vi

> Of course I'm aware of the cons of programming in PHP versus other languages

PHP has come a long way. With v7 (and soon v8) and with Laravel programming in PHP is not only a delight, but also extremely robust and fast.

For the front-end, jQuery to Vuejs is not a big leap. You can sprinkle it around to test waters and gain confidence. Such a pleasure to work with.

Re: the frontend - Livewire components also work great, and might be an even easier leap.

Doing your own thing while supporting your family is awesome. It's a difficult thing to do.

The SaaS I run isn't mine. Back when you were starting your SaaS, I was probably spending all of my time chasing the latest shinny tech :) Some of that was worthwhile but some not. The experience taught me to slow down a bit. Sometimes I wonder if I've slowed down too much. We'll see.

> feel like I'm waaay behind the tech curve with my use of such an old stack, and am somewhat scared to admit it.

If it pays your bills and gives you the work life balance you want, why do you care?

Running on the perpetual treadmill of cutting edge tech (especially with JS and containers where everything new is old every other month) is nothing to strive for. I know plenty of engineers who are very up to date on the latest trends but have no personal lives or families and are basically married to their job. I don’t envy them, I envy you.

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.

Thanks!

Best done as an employee is spot on.

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.

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

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.

> 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.

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.)

> 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.

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.