
Ship.io says goodbye - marc_omorain
https://ship.io/
======
pbiggar
[Disclaimer: I'm founder of a competitor
([https://circleci.com](https://circleci.com), which offers CI/CD for iOS and
Android as well as web apps, open source, etc).]

I don't know why it shut down, but my guess: customers didn't want to use one
CI system for their iOS builds and another for their server-side builds. This
was one factor in CircleCI acquiring distiller.io (which was a ship.io
competitor) last year.

The history here is very interesting:

The original ship.io product was built by CISimple, and the assets were sold
to Electric Cloud after CISimple shut down in 2013.

Electric Cloud is a ~13 year old VC-backed startup that sells a C/C++ build
distribution service (think distcc, but much faster and better). (Interesting
side-note: EC was founded by prolific HN contributor jgrahamc, and by John
Ousterhout, who created TCL and coined the term "scripting language".)

EC's customers are mostly very big embedded systems makers, so it's a very
enterprisy market. This market was good but AIUI their revenue growth
flattened out sometime after hitting $10m/yr in revenue many years ago

A few years ago EC branched out into the Continuous Delivery space to rekindle
that growth. Their continuous delivery products are AFAIK being sold in the
same enterprisy top-down fashion as EC, as opposed to the bottom-up developery
approach that CircleCI, GitHub, New Relic, Heroku, etc, use.

Ship.io was, I think, the first of EC's products to be sold bottom-up, and
that was aimed directly at developers. I believe this is the best way to sell
into this market, so it seems ship.io was going in the right direction. In
fact, I believe it even operated somewhat autonomously from Electric Cloud,
with a separate team based in SF instead of Silicon Valley.

I would guess they shut down because they didn't get product market fit (which
would be true if their customers wanted server-side CI in the same product).
But it's also possible (pure conjecture here) that the bottom-up autonomous
feel of ship.io didn't gel with the top-down enterprisy culture of the
mothership.

~~~
zacwest
I use CircleCI for iOS CI/CD and one of the biggest reasons is it doesn't try
to be an all-encompassing solution for what I need: it executes tests and
reports results.

I wanted it to do more, so I wrote some simple tooling to do more. I wrote up
in a blog post for ease of reproduction: [http://zacwe.st/blog/automating-ios-
builds/](http://zacwe.st/blog/automating-ios-builds/)

I think for most users, just running the tests is a step in the right
direction. Handling distribution (the CD part) is something you grow into if
you haven't seen it before. If I have to think about how to configure every
aspect, I'm probably not going to get very far into the setup.

------
nathancahill
I'm curious about the shuttering timelines that failed startups use. Three
weeks is awfully fast to go from operational to shutdown for a service that
customers rely on. I see two options, either could be reasons that a startup
would fail:

1\. Customers don't rely on the service.

2\. There are no customers.

Otherwise, why not leave the servers on for another month?

EDIT: 3. The service isn't automated enough to be run without human
intervention, even for a month. Which would also likely create failure when it
scales.

~~~
chrissnell
If your priority is returning the remaining investors' money to the investors,
why would you keep the lights on?

~~~
nathancahill
I'm wondering specifically about keeping the servers on. Server costs are much
less than the cost of "keeping the lights on".

~~~
grrowl
I agree, even shutting down compute/cost-intensive features (i.e. the actual
functionality) and leaving the login screen open might prevent a few people
from losing work.

Then again, if the code is mirrored on github/bitbucket/whatever, then the
risk of data loss is minimal and the product is actually all functionality.

------
eterm
So apparently they only launched less than 6 months ago:

[https://ship.io/ship-io-launches-out-of-public-beta/](https://ship.io/ship-
io-launches-out-of-public-beta/)

I'm not in touch with the startup world but does that seem a short time to see
if it sticks? Did they just have too short a runway?

~~~
tauntz
Ship.io was previously known as Cisimple which launched already in the spring
of 2013 ([http://techcrunch.com/2013/04/09/cisimple-exits-beta-
makes-m...](http://techcrunch.com/2013/04/09/cisimple-exits-beta-makes-mobile-
app-building-testing-deployment-well-simple/))

------
bdcravens
I should start keeping track of the services for developers I hear about for
the first time when they declare the end.

~~~
chadzawistowski
[http://ourincrediblejourney.tumblr.com/](http://ourincrediblejourney.tumblr.com/)

~~~
joe5150
Oyster shut down?? That may explain why I haven't had to spambox any of their
emails in a while.

~~~
nulltype
Even shutdownify has shut down:
[http://www.shutdownify.com/](http://www.shutdownify.com/)

------
minimaxir
Ship.io apparently never raised money according to CrunchBase, which means
this shouldn't be that unusual.

~~~
squiguy7
They should be able to get some funds by selling their domain though. I
imagine someone would want to pay a good chunk of change for that.

~~~
fuddle
$ 13,951 According to www.siteprice.org

------
bevacqua
"This ship has sailed."

~~~
smoyer
But what about sunk costs?

~~~
nathancahill
I hope they didn't anchor any debt.

~~~
smoyer
Sounds like it might have been a fluke - like a windlass day on the rode to
success.

~~~
nathancahill
Seems to be the case, moor often than knot.

~~~
betamaxforever
Olive startups as much as the next guy, but it's Brutus out there.

------
viktorbenei
[Disclaimer: Co-founder of [https://www.bitrise.io](https://www.bitrise.io) ,
one of the alternatives mentioned on ship.io 's page]

Back when we started only a handful of CI services were available for iOS
developers. One of them was CISimple which was later aquired and rebranded as
ship.io . Our motivation to start our own service was that none of the
available hosted services at the time were flexible enough to handle the
projects we were working on.

Ship.io did improve a lot, allowing custom scripts to be executed, but, at
least for us, they always seemed to be too locked down, too much of a black
box.

This is exactly why we recently introduced our [open source
CLI]([https://github.com/bitrise-io/bitrise](https://github.com/bitrise-
io/bitrise)), so that you can run your CI and other automation configurations
on your own machine if you want to, and of course in the (highly unlikely ;)
case we would decide to close the shop you can still export your configuration
and run it anywhere you want to.

I remember, just a few months ago, we felt that ship.io had a spy in our team,
as they introduced new features almost at the same time we did (Slack support,
Deliver support, ...).

It's surprising they closed so quick, they had quite an active marketing team
and released new features frequently. I guess this decision was not up to the
people who actually worked on the product, most likely they failed to meet the
(monetary) expectations of their parent company.

Fairwell old friend, we'll always remember you!

------
mikefriesen
This is too bad. This was a useful service. Part of the problem might have
been that individual accounts were free. I would have paid for this service.

------
pearlsteinj
Damn, this was actually a really helpful and easy to use service...

~~~
JimDabell
Unfortunately, we had the opposite experience.

Our builds were failing because even though we could check out our Git
submodules fine, they could not. They couldn't resolve it and told us to stop
using submodules instead.

Then our builds were failing because they weren't respecting our scheme's
settings. First they didn't even understand the problem and told us to
restructure our project, then when they did understand it, they didn't treat
it as a bug report, but a feature request.

To be honest, it felt like we were just an inconvenience to them. We stopped
using their service because they seemed more interested in us doing work to
solve their problems than them doing work to solve our problems.

------
tonyjstark
Wow that was fast, I attended a conference in February this year where they
advertised their Beta version to developers. Also they released a new feature
back at September 21st, it is really surprising.

------
pavornyoh
This was a service I'd pay for. Not good..

------
hardwaresofton
Am I the only one that sees a failed sticky footer as a lack of attention to
detail/not enough effort on the part of devs?

It's surprisingly (and sadly) non-trivial to make a sticky footer (that stays
at the bottom of a page, even if the page's contents are not long enough to
fill out 100% of the screen), but this is something I expect just about every
experienced front-end dev to know _by now_.

For those curious about how you solve this (without flexbox, which is
something I'd expect frontend devs to know/remember from repeated lookups):
[http://ryanfait.com/sticky-footer/layout.css](http://ryanfait.com/sticky-
footer/layout.css)

~~~
hardwaresofton
Just to make sure no one thinks badly of ryanfait (or whoever manages
ryanfait.com) -- this comment was in no way endorsed/sponsored by that site
(just one of the first reasonable explanations google produced when I
searched).

Comment is purely heavily downvoted passerby-opinion, not sponsored content.

