After three months of developing ContactHive, it’s time to reflect. This project is not just an experiment but a concrete application available on both Apple and Google stores. Through this retrospective, I will share the key development phases, the mistakes made, and the improvements to implement for the future, both for this application and future projects.

Before reaching this stage, I spent several months in an intensive theoretical learning phase, studying an average of two hours per day and working on various exercises. Then, I decided to dive into real projects, tackling development from a more pragmatic perspective. This transition to action was a decisive turning point, and I have no regrets about this approach.

This retrospective is part of a mini-series of articles where I will share the different stages of my journey in developing the ContactHive application.

# Project Genesis

Initially, the idea was simple: create an application that facilitates contact management and optimizes networking. Having previously developed a small application for a service desk (former colleagues can testify to its usefulness), I thought this project would be relatively simple. However, reality turned out to be quite different.

I started with brainstorming on Whimsical to map out all the envisioned features. From there, I extracted the essential functionalities and quickly assessed the project’s viability without conducting an in-depth market study. The main goal was to create a tool that would be useful to me and address a need I had identified.

# Development and Initial Choices

The initial approach was based on Expo and React Native for the front end and Firebase for user data management. I had designed a first data model based on Firestore, but as I progressed, a major issue emerged: data privacy. Many people were reluctant to have their data stored on a third-party server.

This led me to my first pivot: adopting a “local-first” architecture, where all data is stored on the user’s device. This decision required a complete overhaul of the initial architecture.

# Major Architectural Changes

## Switching from Firestore to a Local Database

Initially, data was stored in Firestore via APIs, making the app dependent on external cloud services. To gain more control and enhance user privacy, I transitioned to a local approach, first using JSON as an intermediary step to structure the data correctly. Eventually, I migrated to SQLite, which provided better performance and a more structured database management system.

## Reorganizing the Data Structure

The first data model I designed no longer aligned with the new local-first approach, which required substantial modifications. As a result, I had to rewrite several parts of the code, leading to an extensive refactoring process. This restructuring introduced unforeseen bugs, necessitating continuous adjustments to the architecture and optimization of data access methods to improve performance and stability.

## Optimizing Contact and Event Management

Initially, the app retrieved contacts and events from the calendar and replicated them into the database, leading to unnecessary data duplication—a common issue in database management. To resolve this, I refactored the approach by directly accessing the user’s contacts and synchronizing updates dynamically with the calendar, eliminating redundant data storage. The goal was to ensure consistency and real-time updates while preventing data conflicts and inconsistencies.

# Mistakes and Lessons Learned

## Do not underestimate the complexity of a mobile project

A project that seems simple at first can quickly become complex. Managing performance, permissions, and component interactions requires anticipating challenges from the outset. I initially believed that integrating a database and syncing contacts would be straightforward, but in reality, it required multiple iterations and optimizations to achieve smooth performance.

## The importance of testing hypotheses quickly

I could have identified the need for a local-first model earlier by validating this hypothesis in the initial stages. Testing minimal viable versions allowed me to confront ideas with real-world constraints and avoid costly redesigns. Implementing small prototypes before committing to full-scale development proved invaluable in refining my approach.

## Optimizing contact and event synchronization workflows

A well-designed synchronization process is crucial to maintaining data consistency. Instead of duplicating contacts and calendar events, native and non-duplicative integration provided better consistency and gave users real control over their data. The lesson here was to favor real-time synchronization over redundant storage, reducing complexity and enhancing reliability.

## Use proven solutions

I discovered solutions like WatermelonDB or Realm too late, which would have significantly simplified data management. These tools are designed for mobile applications and, in some cases, offer better performance than SQLite. Had I explored these options earlier, I could have reduced development time and avoided some of the refactoring work. These alternatives might be considered for future updates.

# Next Steps

This project has taught me a lot about managing end-to-end development, from ideation to production. There is still a long way to go, but I am convinced that ContactHive has great potential.

In the upcoming phases, we will discuss topics such as performance optimization and integrating artificial intelligence into the development process and lessons learned along the way.

# Conclusion

Developing ContactHive has helped me better understand the challenges of mobile applications and gain maturity in project management. If I had to start over, I would integrate data management and user experience considerations earlier.

And you, what mistakes have you encountered in your projects? Let me know in the comments or on social media—I’d love to hear how you handle these challenges!