Introduction
A couple of months ago I started a blog series on dusting off some of my engineering skills, and that quickly shifted to focus on learning how to leverage AI. What start as a silly exercise with entering bank transactions quickly changed to working on a side project.
The result is Builds. Builds is social media platform focused on car enthusiasts. It's mobile-first, using React Native. I knew it wasn't going to be easy, but I completely underestimated just how much work was required to get an app off the ground.
Concept Behind Builds
I've been into cars for a very long time. I started participating in car-related activities two decades ago, when I purchased a 2005 Infiniti G35 Sedan. I quickly found an online community for owners of that car (powered by vBulletin), and I deeply integrated into that community. The G35 wasn't a particularly special car, but that didn't matter. It was my car, and I did everything in it. I autocrossed it, I drag raced it, I attended car shows, dyno days, local meets and big national events. I heavily modified the car, and kept decent records. I had lots of dyno pulls and drag strip timeslips to measure the effectiveness of different mods.
That's when I first started to conceptualize this app. Though this was 2005, so pre-mobile. At the time I wanted to build a desktop app in c#/Winforms, that connected to an internet-hosted database (this was also pre "cloud"). I wanted to build a piece of software where I could keep a historical record of my car. It would support embedding media & attachments, such as dyno run data files and ECU datalogs.
The "killer feature", to me, was the concept of versioning; i.e., to apply the concept of version control to the automotive build log. I wanted to visualize changes over time, and include a diff viewer. There were secondary features, such as comparing data from timeslips or dyno runs, but versioning was the core concept.
I never actually started that project. I just never had time. Over the years, the concept evolved to incorporate social concepts. And of course that just meant the scope kept growing, which consequently meant I was even less likely to work on it.
Change in Personal Circumstances
In April of this year, I was laid off by my employer. I won't go into the details here, but it was a very difficult experience. Nearly 3 months later, I am still unemployed. I am diligently pursuing employment, with almost 200 applications submitted. But I also chose to use this time productively. I didn't take any "time off" after the corporate grind; instead, I've been working even more than before.
I will never claim to be thankful that I lost my job. But without this huge block of time, I never would have started this project.
Project Scope
So what is Builds now? The core concept remains the same, but with a social media twist. Users have a Garage which serves as their profile. A Garage can have 1 or more Rides, and each Ride can have 1 or more Builds. A Ride defines attributes like its Year/Make/Model/Trim, and each Build has an associated set of modifications, attachments, and custom attributes. Users can search for other users, follow/unfollow them, comment on rides/builds, share their own statuses and start discussions. Users can even create and check into events, with location support.
At a high level, this doesn't sound like a lot of work. But in actuality, everything I mentioned includes multiple screens and some fairly complex business rules. At this moment, there are 22 distinct screens. In the front end alone, there are over 600 unit tests and 100 journey tests. The front end is clocking in at 35k lines of Typescript, with the backend at 25k. Those aren't huge numbers, but there's no way I could have ever made it this far while still having a full time job.
Project Organization
I am using a monorepo, hosted in a private github repository. It currently has:
- The mobile front end (React Native + expo, Typescript)
- The backend service+api (Node/Fastify/Apollo GraphQL, Typescript)
- A separate database migration tool
- An administrative console with its own backend and front end
- A data seeding tool to feed data into the application via its api
- An external api data crawler to scavenge automotive Year/Make/Model/Trim data into my dev and prod databases
The backend has a rich suite of unit tests and integration tests. The integration tests use testcontainers and automatically apply database schema and seed data.
The frond end has its own unit tests and journey tests, including asserting on user telemetry. I haven't implemented on-device automated testing, but it's in the plans.
The database migration tool is feature rich, and has already saved me a few headaches. It also has a --dry-run option to the full application of all migrations before applying them to any of my environments.
Suffice it to say, there is quite a lot here, particularly for a solo developer. And I've leaned on AI heavily for this. First it was Cursor, and now it's Claude Code. AI has been absolutely indispensable.
Conclusion
This is the first in a new series of posts, following my experience in trying to launch my own app. I'm a complete novice with this process, and I'm sure much of what I've experienced will come as no surprise to many others. While I've found the technical side to be largely rewarding, there have been quite a few frustrations. I hope that my sharing those can help prepare others that are considering similar endeavors.
Top comments (0)