DEV Community: Tramline

Does sponsoring a developer conference help with sales or marketing?

Pratul Kalia — Wed, 31 Jul 2024 11:37:56 +0000

Droidcon San Francisco is one of two big Android community conferences (the other one being New York) that happen in the United States. We attended the 2023 edition to talk to people about Tramline, get feedback, and gauge interest, but we were not sponsors. We spoke to many people but in every case, we had to go up to them, pique their interest, and then show them our platform. In the end, it did not feel worth the time to travel so far with the intention to demo (and sell) but do it as an attendee.

In our past lives, we have sponsored events as a way to support the developer community. We had no experience of sponsoring with the intention to sell, and with Tramline, we were curious about what that would be like. So for the 2024 edition, we decided it was time.

Droidcon was not only supportive of an early stage startup like ours, but also patient and super nice. They answered our (many) questions when we were in two minds, and their team went above and beyond during the event to help us with what we needed. Shout out to Emiliano and Elissa for everything!

Intention

The biggest difference we felt this year was people’s intention. As a sponsor, people knew we were there to sell something. When people came to our desk and spoke to us, they came with the intention to listen to us. Some people dropped off mid conversation, but most people were interested in seeing the platform work. Some people had built similar systems at their workplace, and talking to them about their choices and tradeoffs was enlightening for us.

Discussing the problem space and giving demos repeatedly forced us to refine our flow on the fly. People are busy at conferences! Their attention is split between listening to talks, hallway conversations, the after-party, and other sponsor booths. On the show floor, you only have one shot with someone so it can get stressful. It took us a few runs to come up with a script that would convince people to want to see a demo.

Not everyone has the same strategy though: we spoke to Arnold from Screenshotbot, and he prefers giving people an overview of the product, answering questions, and scheduling a demo after the conference when people have more time on their hands.

Making friends

During the speaker talks, the hallways became empty and we used that time to talk to the other sponsors about their experiences.

We spoke to the Gitar team about the mobile DevOps tooling space, especially the role of AI. They also shared their experience of attending other developer events across the US and Europe.
Arnold of Screenshotbot was helpful to us throughout, sharing from his experience of selling and growing the product. It is refreshing to see solo developers trying to build a business in a market obsessed with raising venture capital.
Josh from Emerge Tools gave us good feedback on our positioning and pricing. Separately, Emerge has a neat inbound sales motion which is driven by their unique content strategy.
We love Sentry and we’re happy customers of the product. As always, they had really nice swag, and their sales engineers were eager to share their opinions on GTM and early-stage sales.

Swag swagger

We’ve attended so many conferences over the years that we had a ton of ideas on what we want to share with attendees. After much deliberation, we settled on canvas coasters with the Tramline logo on one side, and a QR code of our GitHub repository on the other (yay open source!).

We also wanted to do a book giveaway, so we requested the inimitable Chet Haase to sign some copies of his Androids book… which he did! He was super sweet and patient with us as we dealt with the logistics of moving the books around.

Our table would have looked incomplete without a big standee, but we wanted something that wasn’t boring or sales-oriented. So we channeled our obsession with apps, trains, and maps to come up with…

The Massimo Vignelli homage was a hit during the conference, and many people took photos with the standee. The design was illustrated to perfection by Bhavya Arora.

Outro

Sponsoring events is a great way to give back to the community, but if you’re building a product for developers which has some traction, sponsoring gets you a lot of eyeballs in a short amount of time. It costs time and money, but we think it is an effective use of both. Good luck!

Applelink: Practical API Recipes for App Store Connect Workflows

Pratul Kalia — Sat, 22 Apr 2023 17:50:14 +0000

Tramline is a modest Rails monolith (as opposed to a majestic one) that wants to stay a monolith for as long as possible. We tend to only mildly impose advice such as “you should always start out with a monolith” or “micro-services are actually a terrible idea for a startup” for our engineering decisions. As with most practical things, all our decisions have devils inside of the details rather than adages.

Since a release coordination platform talks to a variety of fragmented yet necessary tooling, the real value comes along when many integration touch-points are combined to ship new releases on a predictable and reliable cadence.

We presently integrate with:

GitHub for source control
GitHub Actions and Bitrise for post-commit workflows
Slack for notifications and sending builds
App Store and Play Store for shipping releases
GitLab, Sentry, and Firebase App Distribution coming soon

All of our integrations sit inside the aforementioned monolith. This is for simplicity of maintenance and deployments. That being said, we maintain a strict domain-agnostic layer for handling API calls so that if integration endpoints do need to move out — say, for accommodating higher concurrency — the contract from the layer “above” does not need to dramatically change (if at all).

However, by integrating App Store Connect, we intentionally break our own mild constraint against opening the gates to a service-based architecture.

App Store Connect & Fastlane

App Store Connect has an extensive developer API to manage releases on both TestFlight and App Store. You can do most things through the API (a notable exception being able to upload builds). The canonical library in Ruby that implements a large part of the API is the excellently named Spaceship. Spaceship is, in fact, an abstraction higher than what the API allows you to do. This is because it’s designed to be Fastlane-first. All the actions and recipes that Fastlane supports are sometimes direct interfaces implemented in Spaceship.

Using Spaceship gives us two benefits:

Use many of the battle-tested recipes directly
Integrate the Fastlane gem with Rails

Since Spaceship is a part of Fastlane, it makes integrating Fastlane directly with a Rails app quite tricky. Fastlane is a big gem and a lot of the code just isn’t useful to the primary Tramline service. More importantly though, Fastlane’s dependencies simply do not play very well with Rails 7.

And so, Applelink

We built Applelink, a small, self-contained, rack-based service using Hanami::API, that wraps over Spaceship and exposes some nice common recipes as RESTful endpoints in an entirely stateless fashion. These are based on the needs of the framework that Tramline implements over App Store. The API pulls its weight so Tramline has to do as little as possible. Currently, it exposes 13 API endpoints.

Tramline hops all App Store requests through this service:

In Applelink, a complex recipe, such as release/prepare, will perform the following tasks all bunched up:

Ensure that there is an App Store version that we can use for the release, or create a new one
Update the release metadata for that release version
Enable phased releases, if necessary

Similarly a simple fetch endpoint like release/live will give you the current status of the latest release.

Even though Spaceship has helped us come a long way, it isn't necessarily efficient at choosing the right combination of API calls underneath. For example, while preparing a release, Spaceship could end up making 3 separate API calls to look for the app, update its attributes (setting release type, version name etc.) and then select the correct build.

In some instances it’s just better to drop the interface from Spaceship altogether and make direct API requests. Applelink tries to choose the most efficient path by making use of the correct relationships.

Since Fastlane is mainly intended as a command-line tool for build pipelines, its primary focus may not be an efficient request-response cycle.

Where are we now?

Applelink has been operating smoothly for the past few months and this model has proven to be an effective starting point. It is possible that after a few more iterations we decide to retire the use of Spaceship. Nevertheless, we would have a solidified API in place, and it would only be a matter of swapping out the implementation.

Since Applelink is a separate service that is not reliant on Tramline’s internal state, all the API endpoints are valid outside of Tramline. It can be used in a standalone way from a CI action or a Slack bot that spits out release information periodically.

As with Tramline, Applelink is open source under the Apache 2.0 License.

Prior art

Cider by Aaron Sky, aims to implement a significant portion of the API in Go which has been helpful in confirming some of our assumptions.

Store Quirks is partly maintained by findings made during the implementation of Applelink.