Delivering a first-class health app with Bitrise: An interview with Maven Clinic

Today's consumers are more health-conscious than ever, leading many to turn to mobile apps to manage their health and well-being on the go. According to Insider Intelligence, over two-thirds of Americans have used a health-related app in the last year.

As a result of this shift in behaviour, healthcare providers now have a unique opportunity to reach out to new audiences and form stronger relationships with their customers. For developers, the challenge is to build apps that stand out in an increasingly crowded marketplace.

With this in mind, Maven Clinic, the world's largest virtual clinic for women and families, partnered with Bitrise to transform its mobile development and deliver a superior app experience for its healthcare clients.

We caught up with Ben Piatt, Mobile Software Engineer at Maven Clinic, to chat about the partnership, what it's helping them achieve, and why he believes mobile development deserves special attention.

1. What was your ultimate goal in transforming your mobile strategy at Maven?

Over the past few years, we've evolved significantly as a company, and as a result, our focus has shifted. With more people relying on mobile devices to manage their health, we wanted to overhaul our mobile development processes to meet rising consumer expectations.

We didn't want to replicate our web experience for mobile. We wanted to embed native mobile features—offering targeted deep links, enhanced video calling, and improved messaging—to offer clients a more personalized experience. Essentially, we wanted our app users to feel like first-class citizens by giving them the high-quality experience they now expect. 

Our ultimate goal was and still is to have a one-click build and deploy solution for mobile releases. We are very close to making this a reality, especially now that we are using Bitrise's Release Management product. It has removed a lot of the burden that we've previously been responsible for in managing releases. 

2. What makes mobile development different from traditional approaches?

Mobile development is quite different from web and back-end development for a few reasons. For one, web and back-end teams can publish, review, and merge code almost instantly. However, with mobile releases, we typically follow a two-week release cycle. 

It also requires building application binaries and making them available for both virtual and physical test devices. Plus, our apps have to go through each store's review process, something we cannot control. There are definitely some unique challenges in mobile development that don't apply to web and back-end work.

3. What led you to explore a new solution for mobile development at Maven?

When I joined Maven, our iOS team ran builds and performed CI/CD on a server in one of the engineers' apartments. Additionally, our Android team also used a round-robin approach to running builds; depending on who was managing the release, they would take turns running the scripts on their local machines. It's not unusual for a company like Maven to operate like this, but it was not scalable and something I was keen to address fairly quickly. 

As you can imagine, the whole build and CI/CD process was extremely manual from start to finish, with only a couple of steps automated within the local scripts. As a result, most of our work required manual intervention, resulting in many time-consuming and redundant tasks.

Getting everything in order to release a build could easily take an entire day between meetings and other responsibilities. Even then, the handoff was far from seamless. Depending on who was managing the release, follow-ups and additional support were often needed during the Quality Assurance process. 

In short, the whole process was inefficient, prone to human error and required a great deal of manual intervention at every step. From an efficiency perspective, it's no exaggeration to say this was one of the most challenging operational setups I'd ever experienced. It was clear we needed to take a fresh approach.

4. Before Bitrise, you were using GitLab for your CI/CD solution. What challenges did that present?

We used GitLab for source control, and before Bitrise, all our pull requests went through GitLab's CI runners. GitLab has a CI/CD solution that was used across all our engineering teams at the time. The challenge, however, was maintaining it. Our infrastructure team handled the setup and upkeep. But on the mobile side, engineers had to customize it to create mobile releases. Not only was it a highly manual process, but as only one person on the Android team really understood the process, it created a single point of failure.

Essentially, the setup meant Android and iOS engineers had to learn to manage Docker containers and spin up infrastructure—skills that weren't typically part of the tech stack or the knowledge base for mobile engineers. On top of that, we were self-hosting GitLab CI, which limited our infrastructure resources since we were sharing a single instance across all teams.

In 2023, we hit a breaking point. The company was growing rapidly, and engineering was hiring more people, but we weren't increasing the shared resources on GitLab accordingly. As a result, pull request and deployment jobs slowed down across engineering. Everything was becoming constrained.

For example, pull requests and build/deploy jobs for Android and iOS were taking 45 minutes or more to complete when they typically should have taken 15 minutes or less. Jobs would frequently time out and fail, requiring reruns because we simply didn't have the resources to complete them.

While all of this was happening, I was already strongly advocating for a switch to Bitrise. Fortuitously, these issues emerged as a severe pain point impacting our team's velocity and ability to work efficiently. 

5. What was most important to you in finding the right solution?

We needed a solution that could fully automate our build and testing workflows and would allow us to create releases in a scheduled, consistent, and repeatable fashion. 

Our non-negotiable requirement was that the solution have a strong mobile focus and cater to the specific requirements of the mobile development space rather than being considered an afterthought or add-on.

6. How did you first discover Bitrise?

Fortunately, I had previously worked with Bitrise at my former company and had a really positive experience with both the platform and the team. As it turned out, another iOS engineer at Maven also had a positive experience with Bitrise, so we decided to champion it to the leadership team as an effective CI/CD solution for mobile. We knew it would help eliminate many of the manual tasks we were carrying out at the time and give us a partner we could rely on with a solid reputation in the mobile industry.

7. Did you explore any other solutions besides Bitrise?

Although we were confident Bitrise was the solution we were looking for, we wanted to ensure we explored other options on the market and did our due diligence. As a result, we decided to look into Jenkins and CircleCI as well.

Jenkins had all the features we needed, but we quickly realized it would require extensive customization and configuration, which wouldn't alleviate the burden we already faced with our existing setup. Plus, it lacked the embedded mobile support that was crucial for us.

CircleCI, on the other hand, has definitely come a long way in supporting mobile, but it still lacked the level of support we needed for our automated processes.

Bitrise stood out for a few key reasons. First and foremost, it is mobile-focused, which is crucial to us. Second, it includes a step library that eliminates the need to write scripts to test and deploy apps to the app store. With a little configuration, it's ready to go.

8. What solution did Bitrise provide?

Our goal was to completely automate the Android and iOS build and release processes. To do this, we had to first ensure that all pull requests were routed through Bitrise rather than GitLab. As I had already set this up at my previous company, I was able to get this going pretty quickly at Maven. 

Essentially, once we connected the webhooks, we were able to connect our GitLab self-hosted instance to Bitrise and set up all the necessary triggers. As a result, we were no longer dependent on GitLab to build pull requests. Migrating this part of the process to Bitrise while still communicating job status back to GitLab was a huge milestone for the team.

Our longer-tail goal was then to migrate our release processes and automate things that had never been automated at Maven before. This required a lot of experimentation, trial and error, and testing to ensure that the solution we were building would meet our requirements. On the upside, however, this allowed us to make improvements along the way and simplify the whole process.

In this first iteration, Bitrise Release Management was still in development. So, when it became available in beta, we jumped on board. I'm proud to say I actively engaged in its development from the start by helping to identify issues and bugs and suggesting new features and improvements. It has been great to see so many of the changes I suggested being added to the roadmap and then to the product as it matures. Having that direct engineer-to-engineer feedback loop with Bitrise has been invaluable. 

With Bitrise Release Management, we have been able to fully automate the release processes for both platforms and create a suite of workflows for each team to use in testing and quality assurance (QA). As a result, we have been able to completely remove our dependency on GitLab for all build, deployment, and testing processes.

9. Could you elaborate a bit more on Bitrise Release Management and how it is helping you?

I was very excited to hear that Bitrise were launching a release management product. Although we had the automations coded ourselves, there wasn't quite the visibility we needed to keep track of releases, especially for stakeholders outside of engineering. Bitrise Release Management has helped us add more transparency and visibility to the process and allowed us to track the course of our releases over time more accurately. 

There are still things to work through, but it's been great to see how well the product has matured and how much it has enabled us to slim down our automation footprint and minimize the need for human intervention.

It has also allowed us to automate different events throughout the process in accordance with industry standards. As a result, I have been able to create documentation for each platform and formulate a set of easy-to-digest and structured steps that work well for both hotfixes and traditional releases—something that was a huge pain point before. Also, now that people can self-serve and run the process themselves, I'm finding that I don't need to answer as many questions or make as many corrections as I had previously. That's always a good thing!

10. What results have you been seeing since rolling out Bitrise?

The business impact has been huge. 

There is much better visibility into our mobile release process among other teams in our business. Our collaboration with other dev teams and QA has also improved as well. Everything just feels much more streamlined now. 

Our efficiency has increased as a result of automation. For instance, Slack messages can be sent to the right channels, and the right people are tagged automatically when certain things happen during a release. Whoever manages the release doesn't have to worry about remembering to do it manually any more. We automatically create a link to a list of Jira tickets that have the version label applied for that release, tagging in the QA person. It works really well.  So, when a release candidate is ready for testing, there is a clear notification and a direct link to all related tickets. The QA lead is automatically notified, and regression testing can commence.

Our automated tests are immediately triggered because the QA teams have their own GitLab repositories for both platforms, and everything flows from there. Since moving our build workflows to Bitrise, we can send build triggers to their projects and run the automated tests without dealing with external systems. The turnaround time for regression cycles used to take days, but now, it's less than one, which is amazing.

We've also leaned heavily into feature flagging, which has been a huge help. Now there is a clear distinction between which releases have been updated and when. As a result, whoever is managing feature flags can see exactly when they need to flip something on or off or target specific audiences based on the rollout that's occurring on the mobile side. That's been extremely helpful.

One of the most significant improvements has been to our infrastructure. We're now using Bitrise's Remote Build Cache for Android, and it's been a game changer. Our build times have almost halved – we've gone from around 12-13 minutes for a pull request to somewhere between 3 and 8, depending on how much cache capability we're able to leverage for any code changes. So it's almost half of what it used to be.

We've also reduced our risk profile by not having to share resources with the rest of the engineering team. No more bottlenecks. Plus, we're not managing our own infrastructure any more – that's now handled by Bitrise. 

Now with our own dedicated Slack channel that gives us direct access to Bitrise developers, we have total peace of mind knowing we can get answers to any questions or issues really quickly. 

As for costs, while our contract renewal will be a bit higher this year, Bitrise's expenses are small compared to what the rest of the org spends on GitLab and associated infrastructure. 

So far this year, we have actually been underspending on our committed infrastructure spending. Halfway through, we were only at 30%, which is great as we’ve used those savings to upgrade our virtual machines for faster build times and better performance while still staying under our committed spending. That's been really cool.

Overall, Bitrise has had a very positive impact on our business. We've created a much more efficient process that's visible to the entire engineering organization and even stakeholders outside of it. As a result of the work we have done together, Mobile is now treated as a first-class citizen within the company, with its own unique release process and considerations. 

11. What's been your highlight of working with Bitrise?

For me, the highlight is the trusted partnership we've built together. Unlike other vendors I've worked with, I've had a direct line to engineers at Bitrise from the outset and have had the opportunity to shape the product directly. Seeing the features I suggested come to life has been one of my most rewarding experiences. It's even more exciting to see what's on the roadmap for the near future.

I'm delighted to see the product maturing and the company evolving, and even though I don't work for Bitrise directly, it's been wonderful to have my feedback and feature requests treated as if I'm part of the engineering team there.

As we move forward, mobile will continue to be an integral part of what we do at Maven. With our new setup, we are able to fully embrace its possibilities while recognising that it needs a unique approach and focus across the organisation.

With Bitrise, we're well-positioned to unlock mobile's full potential for our customers. Not only are they a great team to work with, but their expertise and focus on mobile make a huge difference in what we've accomplished together.

Want to grow your revenue and build stronger customer relationships? Contact our team today to discover how Bitrise can transform your mobile development and customer experience.

‍