←Back

DrivnBye – We launched! 

On January 2025, we hit a significant milestone with the launch of Drivnbye, a social media platform built for automotive enthusiasts. This moment has been a while in the making; actual development didn’t start until January of 2024 after we defined features for the MVP. To see our vision come to life and resonate with so many users has been nothing short of incredible. Our excitement for this accomplishment is immeasurable, and we’re thrilled to share the technical journey that brought us here—the high points, the challenges, and everything in between.

I wanted to take this time to document some common themes that showed up during the development of this app along with some hurdles we ran into while deploying.

Bugs and Community-Powered QA

Building a community before launching on the app store proved invaluable for identifying and fixing bugs quickly. When we initially launched on test flight and google play console we invited our discord members to take part in our testing period where we established the environment was “alpha” and was subject to be wiped while we work out early kinks. Before our public app store release we had roughly 700 testers all reporting bugs, providing feedback and connecting with other users on our platform. Overall we squashed more than 150 bugs in 6 months and even implemented 20+ features that we felt added significant enough value to our MVP to justify; I know, scope creep – but these features were widely requested and made the app feel more “complete”! This collaborative environment ensured that we were able to address critical issues before a wider audience encountered them.

Designing as an Engineer 

As a full stack engineer, I’m not a designer, which made creating an intuitive and accessible user interface a major challenge. From finding suitable color palettes to be accessible and aesthetic to designing components that took advantage of gestures that feel natural, the process was far from straightforward.

A great example of this is we initially implemented a “swipe” gesture to edit or delete a vehicle’s modification, business reviews and post comments. To us the gesture felt natural; other apps were using this gesture for the same purpose – why cant we do the same thing? Unfortunately the first couple days we received numerous bug reports, emails, DMs and inquiries asking how they can delete a comment or how they can edit a vehicle modification. It took some time and consulting with some very talented members in our discord server to redesign how we treat the “swipe” gesture and instead wanted to maintain the “minimal” theme throughout the app. We removed the swipe gesture from certain screens in favor of a simple, small, “Edit” button.

The Importance of Quick Iteration 

The choice to use Expo, React native and EAS to build, deploy and test the app also enabled us iterate quickly. It wasn’t unheard of to have several updates a week addressing bugs, implementing features, and improving the app’s performance. Expo + EAS Updates (over the air updates) are just a part of the solution – we needed a way to automate these processes so our team of 2 engineers could work asynchronously. With the help of 2 self-hosted github runners (Ubuntu and Mac OSX) we could build binaries, run tests, apply migrations, and push out OTA updates.

Each of our repositories took advantage of these self hosted runners which proved to be significantly quicker than github’s runners and allowed us the flexibility of defining cache rules so we’re not constantly downloading and installing the same node modules all the time.

Unit Testing and Infrastructure stability  

Deploying a mobile app was half the battle – we still have a backend, websocket server and workers to take care of. The app can’t function without our core backend, an Express server that serves graphQL and REST endpoints to the mobile application.

The importance of unit and integration tests became obvious almost immediately since graphQL is strongly typed, if we changed the type of a field or changed the graphQL schema it would easily break the client. We ended up utilizing vitest for this test suite with code coverage at around 80% (we are still working on improving this further).

For workers we chose to maintain a monolith architecture so all workers and crons, although running independently, are hosted separately but built and deployed from the same build directory as the express server. This allowed us to share functions from the express server without having to copy and paste code or publish a private npm package. At the moment we have 7 cron jobs that help gamify the app, keep our S3 file storage clean by removing orphaned files, removing users that have not verified their email after a certain amount of time, and more.

For our websocket server we decided to go a different route – instead of writing our own service we decided to use an off the shelf open source solution: Centrifugal (I wrote an blog post about this earlier). Centrifugal allowed the customization we were looking for with the security we required. Since we initially deployed this server we have no had to scale up past 1GB of memory and 1 vcpu; even when serving ~600 concurrent clients all at the same time.

Infrastructure and Performance Challenges

This has 4 workers currently running but imagine a 1GB instance hitting 108% memory utilization. We have since switched to a different hosting provider that offers a better selection of auto-scaling and offers memory-optimized instances

Handling such a quick adoption in the automotive market was a humbling experience. On one hand I was excited so many people were registering on DrivnBye; on the other hand I was panicking because i was watching CPU, memory usage, and latency climbing. Initially we hosted our express server on heroku dynos and anticipated quite a bit of traffic so we created 3 dynos on the “standard 2X” configuration (1GB Ram, 2 vCPU). With our test flight users a single instance was more than enough to handle their traffic so we figured a couple more instances would have been fine. This became obvious we chose the wrong dyno type – we should have optimized for memory since we were running into instances maxing out on memory way before we were going to run into CPU constraints (Herku does not allow dynos to autoscale based off memory).

We were able to react quickly and did not experience any downtime (although response times where ~10-15 seconds). At the end of the 2 hours post-launch we onboarded ~2,500 users. One week later and we’re over 10,000 users and steadily climbing everyday

Teamwork Makes the Dream Work 

None of this would have been possible without our incredible team. Each of us bring something special to the table allowing DrivnBye to function cohesively as a single operation. Members on our staff specialize in marketing, business/ sales, engineering, and community relations. We’re a lean team handling an app in its very early stages efficiently with very effective communication. I could not ask for a better team to work along side.

It goes without saying we’re also incredibly grateful for all the members that decided to follow up throughout the entire journey and stay active in our discord constantly making the app better.

Stability and Reviews  

DrivnBye has achieved remarkable stability, with crashes or hangs occurring in just 0.025% of sessions. This reliability, coupled with receiving over 100 reviews on app stores with an average rating of 4.9 stars within the first 72 hours; this speaks volumes about the effort we poured into building a robust app and how thorough our testers were prior to releasing the app. In the same time period we also climbed the iOS charts to 30th place for social media!

Looking Ahead

Posts (blue) and events(red) spreading across 50+ countries in the past 7 days (since release)

The journey of building DrivnBye has been one of growth, learning, and collaboration. This milestone is just the beginning, and we’re excited to continue improving the app. Here’s to the road ahead and the community we’re building.

Leave a Reply

Your email address will not be published. Required fields are marked *