The saddest "Just Ship It" story ever (2020)

I feel this deep in my bones. I worked on a long while back because I wanted to scratch an itch, and I thought that some of the problems I was seeing, hey, maybe someone else was having them too. So I start kinda-sorta-half-heartedly exploring the idea, writing some pilot code, then I discovered hacker news. And oh boy did people have things to say about the general problem, it's impossible to solve, no one should waste their time, we can just , definitely no need to waste time trying to implement something new from scratch.

Then I dropped it, because, hey, the glitterati of hacker news and all of the others must be right, huh? I let it wither, while working on other things, working for other people, making them wealthier, while all in the back of my mind I keep thinking: "maybe I should keep working on it."

Services doing the same exact thing started popping up. They get traction. Users are mostly happy with what they were doing, but they didn't have half of the features that I had already implemented in the code that hadn't seen any use outside of my testing environment. Some take off so well they have a now-publicly traded company doing the same thing. Ten years after I started my little project.

Fuck.

Lesson learned. The naivete of youth is a harsh teacher. Work on it. Put more effort into it. Ship it. Go with your gut--you probably have a better sense than you think you do of what will work and what won't. Ignore the hivemind. Don't leave room for the regret you will inevitably feel when you're scooped.

There's massive caveat with all of these "and then the story ends because we didn't just ship it :(" stories: sometimes the value of the "app" you're working on is in the technical details that cannot really be "hastened" and you can't "just ship it".

Also, and this is something a lot of the managerial class people don't want to hear:

Your job as a sw engineer/architect is to resist the "just ship it" pressure from the management as much as possible. So unless you own what you're coding and you really need it out of the door for your own benefit, if more time makes your work more professional, then take more time. Anyone telling you otherwise is a 100% hack. You are not an automaton that takes in JIRA tickets and spits out hacky code as soon as possible. Or at least you shouldn't be. Not to mention that not taking time (doing things properly) is incredibly taxing on your psyche and you WILL burn out. There are only so much garbage tasks you can take.

It's worth repeating: Unless you have a stake in the company, it is NOT your job to make sure the company is the most profitable it can be. Your job is to create great software. What's great software? The kind you'd be willing to put on your resume without feeling bad. This is the thing that will ultimately make you feel good about the work you're doing. Hitting that arbitrary deadline for a 1425474th time may feel like a relief but it's short term and a form of negative motivation - and in the workplace, those NEVER work over a long period of time. So RESIST that pressure from the top and do your work properly. If they fire you, then who cares, the only way up these days is job hopping anyways.

I've always thought that hanging a "beta" on a logo isn't an excuse to ship junk, but as you allude to, sometimes product and service quality isn't the priority.

I'm also reminded of Dave McClure's talk [0]: "Don't do your viral marketing campaign until your product doesn't suck! Because what will happen is people will tell other people that your product sucks! ...So don't do that!"

[0] https://www.youtube.com/watch?v=irjgfW0BIrw

As someone extremely logic and programming oriented, I -wish- I'd met someone like that. I'm just not an idea guy, apparently.

If the idea was truly good so much so you believed in it, it was a heck of an offer tbh.

A few years ago I built a payment system for Google Forms as a side business (made about $3k from it before eventually turning it off to focus on other things). I'd found a problem nobody was actually solving and wanted to see if they'd be willing to pay to solve it. Like many of us I also had a bunch of partly finished projects that were never released, so I knew it could be a struggle to ship things.

What I ended up doing was writing a list of all the features that I wasn't going to work on, and all the compromises I was going to make to get something out there. Some of those compromises really hurt when I was writing them down, but didn't end up mattering enough to change them for over a year. Once I had them on the list, it gave me permission not to thing about them while I implemented the rest.

I also staged the development to avoid anything unnecessary if it flopped. For revenue, the idea was that I'd get a card on file from you, then bill it each month. But I launched the thing with no integration at all for the card on file. My plan was to give people a 14 day free trial, and if anyone actually used it in that time I'd use the time to build a card acceptance flow using Square (their API is like Stripe's). It turns out people did find and use it, and I had to extend the trial a bit, but eventually built the form. Then I had until the first of the next month to build the system to total up their bill (based on usage) and charge the card on file using the rest of Square's API.

I also didn't build anything at all for scheduling account lifecycle events. I used varmail.me (a little thing I wrote forever ago) to have my app email me when someone signed up, and check my inbox a couple times daily and send a canned welcome message to any new users. Then I'd write an email reminding me user X's trial expired, set myself as the recipient, and use Gmail scheduled messages to schedule it 14 days in the future. When I got that email I'd check if they're still using the product, send them a reminder to put in their card on file, and manually mark their account as inactive until they enter a form of payment. Billing jobs were run manually by me on my laptop for a while. Over time I got more users and it was worth the effort to replace these manual processes with automated ones. If nobody had used my product, it wouldn't have been worth the effort to automate any of this.

Testing was another thing I experimented with doing differently. At first I tested everything manually. Automating tests was difficult anyway because the key flow redirects through PayPal, and there were parts written in Google Apps Script. Eventually I built an end-to-end selenium test. Then I started adding unit tests where appropriate. Basically my principle was that I added automated tests to any area where I felt uneasy about making changes for fear of breaking something. Since I'm fairly risk-averse, the product was small, and I worked on it solo, this worked well for me.