In 2020, I decided to build a mobile app from scratch. Not just an iOS app or an Android app, but something that worked seamlessly on both platforms. That project became Exchanger—a currency exchange app built with Flutter that could run on Android and iOS from a single codebase.

The Idea

The concept was straightforward: a mobile app where you could check real-time exchange rates, convert between currencies, and track your conversions. Nothing revolutionary, but it was a problem space I understood, and it let me explore cross-platform development.

Plus, I wanted to build something that felt like a real app, not just a portfolio project. That meant:

• Clean UI that didn’t scream “first project”
• Actual API integration with real data
• Proper backend with a database
• RESTful API architecture

The Tech Stack

Frontend (Mobile)

• Flutter - Google’s UI toolkit for building natively compiled apps
• Dart - Flutter’s programming language (similar to JavaScript/TypeScript)

Backend

• Node.js - JavaScript runtime for the server
• Express.js - Web framework for building the API
• MSSQL - Microsoft SQL Server for data storage

Architecture

• RESTful API - Clean separation between frontend and backend

Why Flutter?

At the time (2020), there were a few options for cross-platform mobile development:

• React Native (JavaScript)
• Flutter (Dart)
• Xamarin (C#)

I chose Flutter because:

1. Single codebase, two platforms - Write once, run on iOS and Android
2. Hot reload - See changes instantly during development
3. Performance - Flutter compiles to native ARM code
4. Google’s backing - It felt like it had staying power

The tradeoff was learning Dart, which wasn’t as widely used as JavaScript or C#. But Dart’s syntax is clean, and if you know JavaScript or Java, you can pick it up quickly.

Building the Mobile App

Flutter’s widget-based approach took some getting used to. Everything is a widget—your layout, your UI components, even your app itself. It’s very declarative:

// Simplified example
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: Text('Exchanger')),
    body: CurrencyConverter(),
  );
}

The hardest part wasn’t the language or framework—it was thinking about mobile-specific concerns:

• Screen sizes - Your app needs to look good on a tiny iPhone SE and a massive Android tablet
• Network reliability - Mobile connections aren’t always stable
• Offline functionality - What happens when the user has no internet?
• State management - How do you handle data flow in a mobile app?

I used Flutter’s built-in state management initially, but as the app grew, I learned why people use solutions like Provider or Bloc.

Building the Backend

The backend was built with Node.js and Express, which felt more familiar coming from web development. The API had endpoints for:

• Fetching current exchange rates
• Converting between currencies
• Historical rate data
• User preferences (stored in MSSQL)

RESTful API Design

I structured the API to be clean and predictable:

GET  /api/rates              - Get all current rates
GET  /api/rates/:currency    - Get rates for specific currency
POST /api/convert            - Convert between two currencies
GET  /api/history/:currency  - Get historical data

This was my first time designing a RESTful API from scratch (not just following a tutorial). I learned:

• Versioning matters - /api/v1/rates is better than /api/rates
• Error responses need structure - Consistent JSON error format helps
• Documentation is essential - Future me needed to remember what each endpoint did

Database Design with MSSQL

I used MSSQL for storing exchange rate data and user preferences. The schema was relatively simple:

• Rates table - Currency pairs, exchange rates, timestamps
• Users table - User preferences, favorite currency pairs
• Conversions table - History of user conversions

One lesson: don’t over-normalize your database if you don’t need to. I initially split everything into a ton of tables, then realized I was doing complex joins for simple queries.

Challenges I Hit

1. Platform-Specific Issues

Even though Flutter is cross-platform, iOS and Android still have differences:

• Different design guidelines (Material Design vs iOS Human Interface)
• Different permissions systems
• Different performance characteristics

I ended up using platform-specific widgets in some places to make the app feel native on each platform.

2. API Rate Limiting

I was using a third-party API for exchange rates, and they had rate limits. I hit them constantly during testing.

Solution: Cache exchange rates locally and only fetch new data every 10 minutes. Most users don’t need real-time-to-the-second exchange rates anyway.

3. State Management

Flutter’s setState() works fine for simple apps, but once you have data flowing between multiple screens, it gets messy fast. I eventually refactored to use Provider for state management, which made the code much cleaner.

What I Learned

Cross-Platform Has Tradeoffs

Flutter let me build for iOS and Android simultaneously, which was amazing. But I sometimes found myself fighting the framework to get platform-specific behavior.

There’s no perfect solution. Native development gives you more control but requires two codebases. Cross-platform saves time but requires compromises.

Mobile Development Is Different

Building mobile apps taught me to think about:

• Battery consumption (polling APIs constantly drains batteries)
• Data usage (users on cellular don’t want your app eating their data plan)
• Touch targets (buttons need to be big enough for fingers, not mice)
• Loading states (mobile users are more patient, but not infinitely patient)

APIs Need to Be Fast

On a desktop with a fast connection, a 500ms API response is fine. On mobile with spotty 4G, it’s painful. I learned to:

• Minimize payload size
• Cache aggressively
• Show loading states immediately
• Handle timeouts gracefully

The Result

By the end of the project, I had:

• A functional cross-platform app running on both iOS and Android
• A RESTful backend that handled exchange rate data
• Experience with Flutter, Dart, Node.js, and MSSQL
• A working app I could show in interviews

Did it become the next big fintech app? No. Did I learn a ton? Absolutely.

Would I Use Flutter Again?

Yes, especially for:

• MVPs where you need to ship fast
• Apps with heavy custom UI (Flutter’s widget system is powerful)
• Projects where you don’t need deep platform integrations

For apps that need tight OS integration or bleeding-edge platform features, I’d consider going native.

Final Thoughts

Building Exchanger taught me that finishing a project is harder than starting one. It’s easy to get 80% of the way there. It’s hard to handle edge cases, polish the UI, and actually ship something you’re proud of.

If you’re thinking about building a mobile app, pick a problem you care about (even if it’s already been solved), choose a stack, and ship something. You’ll learn more from one completed project than from ten half-finished ones.

Tech Stack: Flutter, Dart, Node.js, Express, MSSQL
Platforms: iOS & Android
Project Year: 2020
Status: Completed and deployed to test devices