Spend more time playing.

I've been working with Ruby on Rails since 2012, mostly helping small businesses and startups get from 0 to profitable in the most cost-efficient way possible. You will learn from more than a decade of my experience as a software engineer & product manager, and from my new challenges as a founder. My goal is to help you build your business in a fast & maintainable way, while saving you time and money, and have fun the whole time.

Aug 29ย โ€ขย 3 min read

How I deal with doubt


Solo Rails / Issue #5

I've gone through a bad couple of weeks: compounding a back injury with a flu, I've been overall feeling like trash for a while. This has brought me to a place where I'm strongly doubting the long-term value of a SaaS project I'm working on, and my own ability to make it work.

While I know most of that doubt is not objective, but rather caused by circumstance, some of it is warranted, and merits examination. So, here's what I do to combat crippling doubt.

Worse-case scenario?

I start by asking myself: what's the worst that can happen? Objectively, the worse that can happen is I have wasted money in the hundreds or low thousands range on something that will not produce ROI as itself.

It's actually not that bad. But the time wasted, and the opportunity cost? Probably bad, if I didn't multiply the potential value of my time spent.

Hedging lines of codes

The original intent with that SaaS project was to bring my Rails front-end skills up to date with Hotwire & Stimulus, and get out of the funk of a few long years of doing and teaching React at work.

This alone has been a resounding success for me. If this were the only positive aspect of the experience, it would be enough. But it's already paid out more than that: talking about the process got me a spot at a conference last February, got me into a positive mindset for long enough to start this newsletter and multiple projects.

Defensive programming

Going further, if I examine the produced code itself, I can reasonably extract 80% of it as reusable framework-y assets, including a comprehensive UI kit built with Phlex.

Building almost everything as mini-frameworks so as to be resilient to rapid change is a habit I picked up from my early career in an agency, where requirements changed really fast and we had to anticipate broad swings in direction often.

A lot of techniques I still use now come from that time. I call it "defensive programming". I went full defensive with this project on purpose, suspecting the need to pivot at least once in search of fit.

At the very least, what will come of the project will be a high-quality blueprint for another project, with every teething question solved.

Something to talk about

One of the goals I had for this year was to be more active on socials and public communities. If nothing else, this project has given me endless things to show off, talk about, extract lessons and insights from (which you are currently reading, case in point).

I, and I suspect many others, tend to conflate time with an investment, that is completely wasted if not maximally profitably returned. Once something looks like it's not gonna go in the direction you originally had for it, even if you need to aggressively pivot, you may not need to throw out the baby with the bathwater just yet.

Where did it start?

It's also useful for me to go back to the initial intent of the project. I made it to solve a particular problem for me, and in trying to rush to market, I focused on consumer appeal and testing feedback, to the point that my initial problem still isn't completely solved.

This in part explains my loss of motivation and surrounding doubt. It explains why a part of me fears this will turn into resentment.

Where to next?

Having examined my doubts, when as much of the subjective as possible has been taken away, the valid criticism that remains is not enough to make me give up on the original idea, and I'll keep hacking at it for a little while longer, at least.

To conclude, I feel better than when I started writing this issue. Here are the takeaways on how I dealt with doubt about a software project:

  • Consider the objective financial investment.
  • Consider how much is the current mood or circumstance.
  • Consider the worst case, it probably isn't that bad.
  • Consider how you can multiply the return on your time.
  • Consider that, conversely, time applied is rarely time wasted.
  • Consider how much you can salvage and reuse.
  • Consider doubt about feasability may be hiding other valid emotions.

The key takeaway is probably that I was focusing on the wrong feedback, and ignoring the most valuable one: doubt creeping in means something. It doesn't necessarily mean "this is trash and you should stop while you're ahead".

It's a warning sign that I'm not following my north star: I'm not having fun and I'm not spending more time playing lately. Which is like, my one thing.

Hopefully, If I'm able to follow my own advice (๐Ÿคž), next week will be a more technically-focused issue.

Listen to your gut.

โ€” Kevin


113 Cherry St #92768, Seattle, WA 98104-2205
โ€‹Unsubscribe ยท Preferencesโ€‹


I've been working with Ruby on Rails since 2012, mostly helping small businesses and startups get from 0 to profitable in the most cost-efficient way possible. You will learn from more than a decade of my experience as a software engineer & product manager, and from my new challenges as a founder. My goal is to help you build your business in a fast & maintainable way, while saving you time and money, and have fun the whole time.


Read next ...