Aviation & Community
How Cru Social Turned Pilot Logbooks Into Profiles and Posts on a 4.8-Star App
Techparser built pilot profiles, logbook flight posts and push notifications for Cru Social, a live aviation social app rated 4.8 stars on the App Store.
- Client
- Cru Social
- Industry
- Aviation & Community
- Timeline
- August 2025 – January 2026
- Team
- 1 Flutter engineer embedded in the client's development team
Results
- 4.8★
- App Store rating as of September 2026
- 2
- Stores live: App Store and Google Play
- 6 months
- Engagement, August 2025 to January 2026
The problem
Cru Social is a social network for aviation: pilots, mechanics and crews. It already had a feed, forums, groups, messaging and a digital logbook, and it was live on the App Store and Google Play with its own development team behind it. What it lacked was a way to make a pilot's flying history social. Flights sat in the logbook as rows of data, and profiles did not show the experience, certificates and aircraft that pilots care about when they look each other up.
The work had to be done inside a codebase the client's team maintained, using their BLoC architecture, their Supabase backend and their review process, without slowing their own releases. It also had to handle the awkward cases that make or break a profile: pilots with no photos on a flight, no job title yet, several aircraft types, several certificates, and flight-hour totals that have to add up when they are shown next to each other.
What Techparser built
- The pilot profile: experience, certificates and type ratings, aircraft, achievements, hangar activity, and recent flights drawn as routes.
- Posting from the logbook: a logged flight becomes a post with photos and video, take-off and landing times and airports, with media stored in Supabase Storage.
- Support for several aircraft and several certificates per pilot, with checks on logged flight hours.
- An animated action button that offers the right actions on every screen.
- Push notifications for posts and invitations, wired to the backend.
- Link previews in posts, instant post deletion that also removes the media, and chat fixes such as duplicate messages.
- Crash and error reporting across the app, so problems show up before users report them.
- Rich-text forum posts composed and rendered with flutter_quill, and paginated lists for friends, friend requests, crus (groups) and invitations using infinite_scroll_pagination.
Decisions that mattered
Think the feature through before building it
Profiles and flight posts were built from the client's designs, but designs cannot cover every state a real pilot produces. Techparser worked through those cases on screen before writing code: a flight with no photos, a pilot with no certificates yet, a missing job title, a logbook long enough to need paginated loading. The client's review of the engagement described the work as 'very thoughtful and diligent in helping to think through features and UX on our app.'
Fit into the team's codebase, not around it
Cru has its own development team, a BLoC-based Flutter architecture with go_router, and a Supabase Postgres backend with migrations promoted from staging to production through GitHub Actions. Every change Techparser made went through the team’s code review and followed the structure they already used: a bloc per feature, services for Supabase and the Flightradar24 API, typed environment config through envied. The result is code the team can maintain after the engagement without a document explaining a second style.
Ship to a live audience in small steps
Because the app was already in both stores, features landed one at a time between August 2025 and January 2026: the profile first, then logbook posts, then notifications, then the fixes to chat and deletion. Crash reporting went in early so each step could be watched in production rather than assumed to work, and so the team had evidence when a user reported a problem.
Real flight data, paginated lists, cached media
A pilot social network lives on flight data and media. The app pulls flight summaries and positions from the Flightradar24 API so a logbook entry can be checked against the real flight, and route drawings on the profile come from that data rather than from typed airport codes. Lists that grow without bound, such as friends, group members and invitations, load page by page, and images and video thumbnails are cached on device so a feed full of cockpit photos does not stall on mobile data.
Outcome
Cru Social is live on the App Store and Google Play. As of September 2026 it holds a 4.8-star rating on the App Store, and the pilot profile, logbook posts and notifications Techparser built are part of the shipping app, on a codebase at version 1.0.4.
The six-month engagement, from August 2025 to January 2026, closed with the client's recommendation for front-end Flutter development, and the review credited the work for helping to think through features and UX rather than only implementing them.
Questions about this project
- How long did the Cru Social work take?
- Six months, from August 2025 to January 2026. Features shipped incrementally to a live app during that period: the pilot profile, flight posts from the logbook, push notifications, then a round of fixes to chat, deletion and link previews. Each step went through the client team’s code review before release.
- What stack is Cru Social built on?
- Flutter with go_router for navigation, on a Supabase backend: Postgres, Auth and Storage, with typed environment config through envied. Database migrations move from staging to production through GitHub Actions. The app also integrates the Flightradar24 API for flight data and supports Google, Facebook and Apple sign-in.
- Can Techparser join our existing mobile team rather than start a new project?
- Yes. That is exactly how Cru Social worked: one Techparser Flutter engineer inside the client's team, using their architecture, their backend and their review process. If you have a live app and a roadmap longer than your team's capacity, Techparser can add an engineer who ships features in your codebase rather than around it.
