[HN Gopher] Launch HN: Runway (YC W21) - Easier iOS and Android ...
___________________________________________________________________
Launch HN: Runway (YC W21) - Easier iOS and Android app releases
for teams
Hi HN! I'm Gabriel, one of the co-founders of Runway
(https://runway.team). We're building a SaaS platform that makes it
easier to coordinate your team's mobile app releases. Runway is an
integration layer that sits on top of mobile app teams' existing
project management and development tools, making it possible to
understand at-a-glance the status and progress of release cycles
and to communicate tasks and blockers -- allowing teams to spend
their time on improving their product instead of managing releases
and tooling. When I was an iOS engineer, my team rotated everyone
through the release manager role for each release cycle. I remember
dreading the weeks I was assigned this role - I'd get stuck
spending a few hours with multiple Chrome tabs open checking on the
status of different tools, killing time while waiting for builds to
upload, Slacking the owners of various tasks, and referring back to
a 40-line spreadsheet that was often out of date. . I also felt out
of practice each time it was my turn - it was hard to remember the
sequence of stuff that needed doing, and there weren't any
guardrails to guide me through the process again. New additions to
the team felt even more lost when it was their first couple of
turns in the role! If anything, the problem has worsened over time
as mobile apps became first-class platforms at lots of companies,
and tech orgs naturally started to grow those development teams and
implement more robust and complex toolchains to support them -- but
much of the process of coordinating those people and tools in order
to release regularly has remained frustratingly ad hoc. While some
build-centric tasks can be automated (e.g. using fastlane or
scripts), we see that a lot of the overhead of releases is actually
very people-centric: keeping your PM up to date on progress,
looping in marketing for release notes, or syncing with QA on the
status of regression testing. We also noticed that, even with a
solid CI/CD pipeline in place, there are often still lots of manual
tasks along the way - build selection, branching and tagging,
compiling changelogs, pinging the right people with status and
updates, etc. We built Runway to connect all those dots. It pulls
in all Jira tickets and code relevant to the release, side-by-side,
to surface and resolve any out-of-sync tickets or code. You can set
up custom, interactive checklists with item-specific owners to
replace the monster Google spreadsheet, and our Slack integration
will ping the appropriate people or notify everyone when important
milestones happen. Design/marketing can enter 'What's New' release
notes directly in Runway for all localizations (with a handy list
of new features in the release to reference) without you having to
hunt them down. Plus, Runway helps teams maintain good workflow
hygiene by automatically tagging releases in GitHub and applying
missing labels to Jira tickets. Typically, tasks like these
represent lost time that adds up quickly and silently for teams and
release managers, between context-switching, monitoring jobs for
completion and waiting to get someone's attention on Slack (all of
which only gets harder as teams become more distributed with remote
work). In talking to lots of companies, we've also noticed that
some larger orgs eventually try to build something like Runway in-
house, but at a steep cost of dedicated engineers, time, and
recurring maintenance. Runway is made for any team building and
shipping mobile apps - we currently support both iOS and Android,
and have built-in support for OTA (over-the-air) deploys as well as
SDK releases. And, we're language and framework agnostic: whether
you write in Swift, Objective-C, Kotlin, or Java, or use a
framework like React Native, Expo, or Flutter, Runway has you
covered. We envision Runway as a better way for most teams to
manage the release process -- one that can save an average-sized
mobile team releasing bi-weekly about $50K a year. We're still
experimenting with pricing strategy, but for now we're charging a
monthly subscription fee per app - there's a lower tier to access
most features, and a higher tier with added features is in the
works. Currently the product is in private beta, but we're actively
onboarding new teams of all sizes. If you and your team are
interested in trying Runway out, head to https://runway.team/demo
for a detailed demo video and we'll get you onboarded right away!
There are lots of possibilities for further automation and
intelligent monitoring on a platform that serves as the glue
between the pieces of a release workflow, and we're excited to hear
from the HN community about their unique release process challenges
(and general thoughts as well!)
Author : gsavit
Score : 74 points
Date : 2021-06-08 14:06 UTC (8 hours ago)
| bredren wrote:
| Any thoughts on the Xcode cloud service described in the WWDC
| keynote yesterday?
|
| Curious how this can be folded into your business.
| gsavit wrote:
| We were super excited by the Xcode Cloud announcement! It's a
| neat evolution of the Apple dev ecosystem and could be
| especially helpful for smaller teams wanting to more easily and
| quickly level-up their Apple DevOps.
|
| We more or less see it as a substitute for any of the other
| cloud CI/CD providers teams are already using and integrating
| with Runway - on the Apple side only, of course. So, a
| complementary product that Runway will certainly integrate
| with! We're especially excited by the prospect of it helping
| less mature teams get an out-of-the-box build pipeline that
| better positions them to take advantage of Runway.
| goodcjw2 wrote:
| Neat! Looks like a great release tool.
|
| I'm wondering whether there is a specific reason to mobile apps?
|
| Would be nice if all releases (web, mobile, etc) can be going
| through the same pipeline. After all, those "people-centric"
| tasks are generally applicable to other projects as well.
| gregdoesit wrote:
| In my experience, mobile is a completely different beast
| compared to web thanks to things like: - You ship a binary that
| you cannot revert. Mistakes are very expensive: which is not
| the case for web. - The App Store review process. -
| Localization often being shipped with the binary (and you can't
| fix it once shipped) - The business impact for mobile apps can
| be large: your highest value customers often use the native
| apps
|
| There are similarities, but web has the massive advantage that
| you can deploy a fix anytime, for your whole user base. With
| mobile, you need to tread much more carefully.
| gsavit wrote:
| Some aspects of mobile (e.g. deploying binary, dealing with app
| stores) make it a more gated and complicated process. That,
| coupled with our team's domain experience in mobile, led us to
| focus there to start with. But you're totally right - there's a
| lot of overlap with any kind of deployment and we have an eye
| towards a future where Runway is the single place where teams
| ship everything they need to ship. Plus, there's extra value to
| unlock in coordinating releases across platforms - e.g.
| coordinating backend changes with app releases, or sync'ing
| product launches across web and mobile.
| goodcjw2 wrote:
| +1000 to focus on mobile first. Totally understandable :)
|
| That being said, I think "more gated and complicated process"
| are the key here. Guess it's easy for web/backend developers
| to hold to the key and deploy as they see needed.
|
| But for mobile, there are typically only a small set of
| gatekeeper at the entire company had the key to publish a new
| release to AppStore/PlayStore. Thus the more process is
| required.
| gregdoesit wrote:
| This is a really cool project. When I worked at Uber, the team
| built a custom release train called Metro, automating as much as
| possible, integrating with various internal tools and
| touchpoints. It worked really well: except if you want this, you
| need to build it yourself.
|
| When I researched my book Building Mobile Apps at Scale [1], the
| best advice I could give for large teams and release trains is...
| maybe build one yourself? Given I didn't know of any products
| that would work from medium to large teams.
|
| It's great to see someone tackling this problem space. You should
| talk with Uber's mobile platform for some hard-learned lessons
| when building Metro.
|
| [1] https://www.mobileatscale.com/
| gsavit wrote:
| It's definitely a problem area that's currently tricky to
| tackle properly for all but the largest of teams/orgs. Building
| in-house is often a luxury, and one which requires a big
| investment not just up front but into the future with upkeep
| and support. Of course it's nice to have a custom solution, but
| we've been working hard to make Runway flexible and able to
| adapt to every team's specific workflows and processes.
|
| PS - thanks for the kind words - we're big fans of the book!
| Maybe you can squeeze us into a second edition? :)
| sanjayio wrote:
| We've been using Runway at ClassPass for the last several months.
| The engineers love it, we can create a release in one click, not
| to mention improved coordination. The possibility of having an
| automated RC cut is exciting.
|
| How'd the team land on savings of $50k/year?
| gsavit wrote:
| We started with some napkin math, graduated to a complicated
| spreadsheet, and then tried to distill that into this rough
| calculator: https://runway.team/release-cost-calculator.
| General idea was to capture the cost of wasted time spent
| coordinating and herding cats instead of doing real work! We
| think there are even more hidden costs not captured here though
| - e.g. upkeep for in-house tooling or effort spent onboarding
| new team members.
| mitko wrote:
| Seems about right ballpark, if not undercounting it.
|
| My team doesn't releases a mobile client but we release
| desktop client / chrome extensions every week. It takes about
| a day of work for an engineer to go through the builds, QA,
| prepare notes, check the status of things in flight that are
| trying to land in there, fix some related bugs and so on. And
| that is with a lot of automation we have. It is also a big
| distraction from other work, so the opportunity cost is quite
| high too.
| an_opabinia wrote:
| Let's say I have an iOS app. Not a single thing changes in my
| repo. I would like to build and submit to the App Store every
| day. On how many days out of 100 does Runway successfully result
| in an app submission status of "Under review by Apple" or
| whatever, _without any input_ from me?
| gsavit wrote:
| Interesting question :) Our "full autopilot" mode isn't yet
| launched but once it is, if you have a recurring cadence set up
| with scheduled kickoff and submit days, and if each release's
| interim steps/gates are green, you'd theoretically be able to
| submit 100 out of 100 with no manual intervention. The real-
| world limiting factor is that in App Store Connect only one
| submission can be in flight at a time, and they'd usually be in
| flight for longer than a day.
| an_opabinia wrote:
| > to submit 100 out of 100 with no manual intervention
|
| Apple breaks fastlane automation at least once a quarter. I
| would expect about 5-20 days when submissions will fail.
|
| However, if you could get that to zero, emphasis on _no
| manual intervention_ , like not asking me for configuration
| changes or to approve something or change or check some box,
| that is easily worth $400/mo from me.
| gsavit wrote:
| Runway doesn't actually rely on fastlane, we're interacting
| directly with the App Store Connect API. So, to the extent
| Apple avoids breaking things on their own API, Runway
| should remain operational!
|
| In terms of config and checkboxes through the submission
| process, Runway allows you to set defaults so you should be
| able to set and forget. Of course, Apple does sometimes
| introduce new requirements and new checkboxes - we plan to
| help surface those changes to teams.
| an_opabinia wrote:
| > Of course, Apple does sometimes introduce new
| requirements and new checkboxes - we plan to help surface
| those changes to teams.
|
| People who got this far in the thread probably thought,
| "Yeah, but things like the Encryption Export Compliance
| checkbox, that's such a nuisance, Apple breaks your
| automation over stuff that is basically never material."
| Which is sort of the opposite of what's going on in the
| flows I saw on Runway's site.
|
| Nevermind what your customers think. If there's a
| difference between having 100/100 zero intervention
| upload days, and 80/100, a clear metric, an obvious thing
| that is valuable - which checkboxes, really, do you think
| are material? You personally. Because personally, I find
| the vast majority of checkboxes to be immaterial. CYA and
| IDC are two sides of the same coin.
| gsavit wrote:
| I think it's a good point. Down the road it could be
| smart to explore an expanded idea of release defaults and
| the ability to assume away new questions about edge cases
| that show up in the flow. For now, we're committed to
| having Runway perform reliably and safely - which to
| start with means being explicit about options/changes
| that occur on a third party provider's side.
|
| In general, my opinion (or Runway's!) isn't as important
| as factors on the customer side - types of apps,
| industries/verticals, team makeup - which are likely to
| make a difference in which checkboxes and options are
| considered important or not. It probably makes sense to
| include those factors when thinking about how we can
| further streamline everyone's release process in the
| future.
| danpalmer wrote:
| This looks great for medium-large size teams, but I've often
| found these sorts of tools to not have the same impact in smaller
| teams where communication and processes are a bit leaner and
| requirements simpler. Is this a market you're aiming for, and how
| do you think Runway suits small teams?
|
| Related, I often find pricing doesn't scale down well for smaller
| teams (for understandable reasons!). What sort of ballpark are
| you thinking about?
|
| Lastly, are you tackling the case of agency model development
| with external clients who may be involved in QA or other steps in
| the process? I see this as a common model in iOS.
| gsavit wrote:
| You're definitely right, in its current form Runway is aimed
| most squarely at mid to large sized teams. But, we do think
| there's still value for smaller teams - and in fact, a couple
| of our early customers are on the smaller side. Although some
| of the coordination and process overhead isn't there, there's
| still value in creating a source of truth and reducing context-
| switching between tools during releases. And, it's really
| valuable to get a framework like Runway in place earlier on, to
| better position a team for growth! We envision helping small
| teams out early on in a lighter-touch way and then helping them
| mature.
|
| At the moment our main tier is $400/mo, but we're exploring
| other options for those teams that are smaller and/or at
| earlier stages.
|
| Re: external clients - This is a really interesting use case
| that we've chatted to some agencies about. The way we've been
| thinking about users and roles, it would make a lot of sense to
| give scoped access to clients and allow them to participate in
| specific areas as needed!
| danpalmer wrote:
| +1 to the external clients. Not sure if it makes sense for it
| to be agency driven with external client stakeholders, or
| company driven with external agency developers/PMs. I'd
| imagine the former would be more common but could be quite a
| different solution for the latter.
|
| At the moment, $400/mo is more than the savings calculator
| suggests we can save, but we're currently 1 full time, 1 part
| time iOS engineer, 1 release a month, 2 apps (same codebase,
| whitelabelled). I think $400/mo for ~10 devs makes sense, at
| that scale it's similar in cost to our other collaboration
| and CI tools, but I suspect we'd have a hard time justifying
| it until we're at that sort of scale.
|
| Are there costly features you can cut that could make it,
| say, $100 for < 5 people perhaps? Something that opens it up
| to small teams who can then "grow up" on the platform?
| gsavit wrote:
| Based on what we've heard from agencies, it seems it could
| be driven from either side: sometimes the agency handles
| the tooling and that's actually some of their value-add
| (having everything in place already), sometimes it's all
| BYO tools on the part of the company/client. Anecdotally,
| the former seems more common, like you say.
|
| We hear you on the math! Our pricing is a work in progress
| and there's more we'll do on the lower end of the scale for
| sure. We're hesitant to cut/bundle the product too much but
| it's a likely option.
|
| If you and your team are interested in trying us out, let's
| definitely chat though!
| [deleted]
___________________________________________________________________
(page generated 2021-06-08 23:00 UTC)