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

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 once met a guy who had a good idea about an app, something that became fairly mainstream two years later. He asked me to code the app for free and we'd share revenues. When asked what his contribution would be, he offered to "run" the company and otherwise his 50% was "having the idea". I thanked him and told him that he has a head-start of 6 months, if his app hasn't hit the market by then, I'd write the thing myself.

Why is it so important for you to be the one to solve this problem? Why is it so important for your solution to the problem to be a business? Running a business is about creating value for yourself and for your customer - if you're obsessed about the problem, be thankful that someone else is putting so much effort into solving it; if you're obsessed about the customer, then you would've shipped something to the customer a long time ago to get feedback.

People are always like "why don't you just ship your app?" ... so I did!

I'm happy I went through with and it's way WAY better than any competitor in this category

Check it out at https://benji.so (landing page is still w.i.p)

After giving up on the project I decided to try and actually started using it as if I was a user. I realised that as users, we are used to countless minor issues, and we automatically find ways around that. When you are the creator of something, you sometimes forget that a lot of sloppyness will not be a dealbreaker, and the user will effortlessly work around many of the shortcomings. Obtaining perfection is more about ego at that point.

So trying to actually use it, ignoring that you are the one who made it, and forbidding yourself to make any modifications for a while, can change everything!

So you made a proof of concept and rested on your laurels. Too bad, that’s life. They did the work and reaped the rewards.

Lesson learnt. You can’t claim ideas

It didn't work and we found no buyers but imagine we still were working on a product without knowing if anyone would ever want to pay for it, keeping our hopes up in the dark.

By now we went with the backup plan and open sourced and have a few cool users. Could maybe even say it's a small community: https://github.com/kviklet/kviklet

It's not the startup success story that I hoped for a year ago. But it's a lot better than still hoping for it and not being a bit more grounded. Also open-source doesn't mean I can never sell support or a premium version and still make a few bucks right? For now it's just a fun side project though.

Then again, none of the many personal projects I've got in my head and on paper (few of them even actually started) are ones that I would release to sell. They are things that I want or that friends/family/other might find useful. Heck, if I had something Alpha quality maybe I'd release that in the hopes someone would see it and think “this idea is useful, but the implementation is shite, I'll write a better one”.

> I wanted an app that combines Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips, and many many more features.

Surprised Pikachu face.

Most apps and services you use were not first to market.

If you want to produce a product to sell, then yes, for the most part you want to ship as soon as you have a minimum viable product - something that at least accomplishes something valuable, even if it could be better.

But if you're working on something for fun and you consider open sourcing it, don't rush into shipping it. As soon as you release it to the public, people will start hounding you to fix bugs and add features. If you try to please them, you'll quickly find yourself working a part time job for no pay - your hobby will turn into a burden.

Releasing anything to the public - whether for profit or not - opens you up to a lot of pressure and judgement. You are making a commitment, whether you intend to or not.

Before shipping it, think carefully about whether you want to commit to supporting it. If not, then just keep it to yourself.

Giving up on a project - even one that works - isn't a bad thing. People change. Just because you wanted to work on it 6 months ago doesn't mean you want to do it now. Don't feel obligated to keep doing something you no longer enjoy. Often the important thing is that you went through the process - you learned a lot and you overcame a challenge. You can leave it at that and still be a success.

It's called advertising or spam they say

I have a side project that's just an internal tool for my music visualizer/ lyric video generator.

It has no functional sign up for new users and is very difficult to use. It's "shipped" as in I use it for my projects.

Another is a simple web app a friend requested. He uses it occasionally. I'm sure y'all on HN could probably find half a dozen issues with it. But it's what my friend wanted and I learned a lot.

The moral of the story is use Flutter from the start, don't worry about shipping apps( do you really want to struggle with the various app stores for what's just a web app anyway), and ship early and often.

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.

Just as I'm getting real close to being finished enough to release - something changes - life changes - or some other thing changes - or I don't believe in the product any more - then I do believe in the product again - then blah blah blah. Always "legitimate" reasons - outcome always the same - haven't shipped anything in years except a bunch of open source projects.

In the end you learned a lot about new technology, about your pace of development, about you thinking, about aspects you like and don't like. The lessons learned "ship it" prepares for next time.

In fact, after 2 years, someone approached me saying he is building the exact same product, but in Germany. We had several zoom calls. He shipped it, failed and iterated. I'm just watching him and hoping someday I get some time to actually do something with mine.

Its your first devops product, and how well you do that is going to affect your actual product

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.

There's a very good reason why people are on guard with pitch decks. Cause those very people you pitched could just take the idea and throw money at it.

Currently my problem is being a one-man band. I've realized I can't "just ship" a product that relies on a hand-rolled user-authorization scheme that I create with very little experience. So now I've interrupted my whole project to learn Supabase and oh yeah, containers... because I've never used those either and as far as I can tell I'd better use those for deployment and scalability.

And oh yeah, I had to learn SwiftUI (already knew Swift & iOS pretty well) to write the app... and also JavaScript/TypeScript and Deno for the back end. So now I'm entering year two and still trying to vacuum up knowledge fast enough to get this thing out the door before someone else announces it.

I've been thinking that I'd have to hire someone to consult on security and scaling as I finish up actual functionality. But the days go by...

> Their mobile app is terrible and it needs 10 seconds to sync. It doesn't matter, they shipped. And I'm looking forward to every single update they release.

> Their backlog of things to do is huge, but it doesn't matter, they ship every single week, and the app is growing along with the community.

Sigh. I agree, and I can empathize, but as a user I am so sick and tired of half-finished crap being shoved out the door just to beat the competition to the starting line. Every day the software we use becomes slower, more bloated, and less stable, and part of it is exactly this attitude of throwing crap at the wall and hoping it sticks. And the sad part is, since everyone is doing it, you can't really not do it, otherwise--as the author discovered--you get left in the dust.

Can you name the largest factor to why you did not ship it? Is it fear? shyness? Thinking that you only have 1 chance with your clients?