
11 min read
Idea → Code → App: My Build Story
Published by

Abdul Rafay
Alright, let’s hear it. We’ve all been there—you have an idea for an app that could help you out, and you realize it could help others as well. But you don’t know how to create a good application, or moreover, you have no idea how to build one.
Now, you go on YouTube and start searching, and the number of videos is overwhelming. You watch one, then two, but when it comes down to actually starting from nothing, things start to get a little rough.
You don’t know the app flow, how users will interact with it, or even what features you need. And that’s perfectly normal. As a beginner trying to build an app, you don’t yet understand how things should flow.
The purpose of this blog post is to show you all how to build an app from scratch. I’ll go through everything—from the idea to development, all the bugs I encountered, how to solve them, and how AI can be helpful.
The Idea?
For this app, I was writing my notes on a website and could access them via the web. But what about mobile? It was really inconvenient to open a browser, enter a URL, and then visit my notes. And sometimes, the internet isn’t reliable. So, now what?
The solution for me was simple—I needed an app where I could read all my lecture notes with offline access.
With that in mind, I started writing down what I needed. The core idea was that I should be able to read my notes without an internet connection. My website already has API access, so I could call that API and render the content in the app, right?
It’s simple and can be done.
The Features
Once the core idea was set, it was time to think about what features would support it and ensure the app wasn’t misused. So, I added these features:
- Offline & Online Access
- Auth System
- Color Choices
- Note-Taking
These features would make note reading much smoother and more convenient.
Tech Stack
Once you have all the features listed and know what you want, the next step is choosing a good tech stack. People say it doesn’t matter what tech stack you choose, but let me tell you—when it comes to apps, you generally have four options for the frontend:
- Flutter
- React Native
- Java (Android)
- Swift (iOS)
And for the backend, there are several good options:
- Firebase
- Supabase
- Appwrite
- PocketBase
All of these options have their own pros and cons. If you’d like to see a core difference between Firebase and Supabase, check out my previous blog post.
I haven’t used PocketBase or Appwrite yet, but I’ve heard they are good options.
My Choice
For me, I’ll be using Flutter for the UI and Appwrite for the backend. The backend will handle user sync, note-taking, user authentication, and the auth gate—nothing more than that. The UI will be coded using Flutter because I use Flutter for everything, and I love its flexibility.
Your Choice
Don’t choose blindly—do your research and pick what makes you comfortable and what you feel confident coding in. If I weren’t used to Flutter, I would have gone with React Native, since I know how React works but have no experience with React Native. So, choose what works best for you.
Defining The Flow
You know the features, you know how to choose a tech stack, now it’s time to define the flow. By flow, I mean how the user will navigate from one page to another. And this is actually very simple. When a user installs your application, what will they see first? It could be a Login Screen, an Introduction Screen, a Splash Screen, anything—it all depends on your thought process and your application.
Here’s the flow I created for my application:
The Auth Flow
The auth flow shows how the authentication process is handled in the app.
Login Flow
- Installed -> Introduction Screen -> Login -> Success -> Home Screen
- Installed -> Introduction Screen -> Login -> Failed -> Error Message
Register Flow
- Installed -> Introduction Screen -> Register -> User Created -> Login -> Success -> Home Screen
- Installed -> Introduction Screen -> Register -> User NOT Created -> Error Message
Auth Gate
- User Logged In -> Home Screen
- User Not Logged In -> Login Screen
Note Fetching Feature
This flow illustrates how the app operates under the hood.
Getting Notes via API
- App Opened -> Internet Connection -> Call API (Get Data) -> Store in Local Database -> Show to User
- App Opened -> NO Internet Connection -> Switch to Offline Mode
Taking Notes
- Open App -> Switch to Note-Taking UI -> Create Note -> Write Some Content -> Save Content
Flow Thoughts
You can see how the app flow is structured. This is just the beginning. As you add more features, you’ll naturally have more flows to define. It’s better to set up a structure early and start coding, because as you develop, the flow will reveal itself more clearly.
I’m only able to describe this flow because I’ve actually done it—I’ve built the app, faced real challenges, and figured out how each UI should connect to the next.
Coding
Okay, you have everything set up. Now what? This is the question most people don’t know how to answer. You’ve got the design, the flow, the idea, and the tech stack. What’s next?
Here’s the short answer: Google and use AI.
In the beginning, Google a lot. Don’t just rely on AI—you’ll forget what you learn that way. Google, Stack Overflow, documentation—they’ll stick in your brain better. Watch some tutorials to get a solid foundation. And then… start coding.
My App Issues (The Rollercoaster)
Now, let me be honest. It wasn’t all sunshine and rainbows.
I initially aimed to finish the app in a week. If you look at my GitHub, it did take me about a week—but, oh boy, it wasn’t easy.
Appwrite Woes
Everything started fine. I created the UI, set up Appwrite as the backend, and things were rolling smoothly. Until… Appwrite refused to add users to my database. I tried everything, but the issues just kept stacking up. So, I decided: forget this, I’m switching to Firebase.
Thankfully, I had separated my UI from my backend. All I had to do was change the backend implementation. Nothing broke in the frontend—lesson learned: keep frontend and backend loosely coupled via a repository file where all the logic meets.
API Struggles & Hive Mastery
Once Firebase was up and running, it was time to fetch notes from my website’s API. I used the http
package from pub.dev, which worked fine. But for some reason, the body of the notes wasn’t coming through.
To handle offline data, I integrated Hive, which was great, but initially tricky to set up. I created models, commands, and started syncing API data to Hive. The issue? Still no note body! Eventually, after hours of frustration, it turned out the API itself had the problem, not Hive.
Once fixed, data was flowing and saving properly.
UI Layer & Card-Based Madness
Next challenge: UI design. There were multiple subjects, multiple lectures, and I wanted a card-based interface. One card leads to another, leading to lecture notes at the end. I made templates to dynamically pass data—whether it’s research notes, lecture notes, etc.—and the experience became seamless.
Search: Fizzy Finder or Bust
Search was another beast. Firebase’s built-in search? Nah, it won’t cut it. I wanted powerful search capabilities, so I turned to Fizzy Finder and built my own search functionality. This was crucial for scaling.
Note-Taking Feature (The Hell Moment)
After deploying V1, I decided to add a note-taking module. The big question: What editor? Markdown, Rich Text, something else? I found Flutter Quill—perfect!
Or so I thought…
I installed it, ran the emulator… and everything broke. Dependency hell. Turns out Flutter Quill v2.9 had conflicts with my Introduction Screen package. I had to pick one. So, Introduction Screen had to go. I rebuilt the entire introduction UI from scratch with custom animations and flows. Painful—but fun.
Once that was sorted, Hive became my best friend again. I created Hive Operations
and Note Taking Actions
services. I set up controllers, wired everything up, and data was being saved smoothly.
Google Keep-Inspired UI
For displaying notes, I wanted something like Google Keep. I wasn’t sure how to achieve this, so I turned to Google Studio AI—it generated a UI I didn’t love, but hey, it worked.
CRUD’s Biggest Nightmare: Deleting Notes
Deleting notes became my nemesis. I wanted a recycle bin feature. Hive doesn’t support moving content between boxes. So, I had to manually copy content from one Hive box to another, then delete it, and vice versa if restoring. Hive team, if you’re reading: please add move support—it would make life so much easier!
The Sync Layer (The Final Boss 💀)
One thing left: the sync layer.
All notes were stored locally, but users needed backups in the cloud. Easy in theory, painful in practice.
Where should sync happen? How should users know if their data is backed up? At first, I triggered sync on save, update, delete—but it slowed down the app by 2-5 seconds. Not acceptable.
Solution? Sync runs when the app launches. It detects changes and pushes them to Firebase. I added settings to give users control over sync, and made sure sync runs off the main thread so the UI stays smooth. (Shoutout to AI for helping me figure this out—I was lost!)
Wrapping It Up
After all the battles, late nights, and debug sessions, I finally had a polished app. I called it MS Bridge.
Every flow, feature, and issue taught me something valuable. And trust me, whatever app you’re building, you’ll hit similar hurdles. Just stay patient, keep separating concerns, Google like crazy, and enjoy the ride!
Try It Out Yourself
Download App
The app isn’t live on the Google Play Store just yet, but you can still give it a spin! Simply head over to my website or download it directly using the link below:
Explore the Codebase
Curious to see how I built this? Check out the entire codebase on GitHub:
I’d love to hear your thoughts! Tell me how I coded, what you liked (or didn’t), and how badly I might have messed things up 😄. Drop your feedback, suggestions, or even a roast in the comment section—I’m all ears! 👇
Final Thoughts
Now, it’s time for some final thoughts. I did this not just because I’m getting a blog post and a future video out of it, but more importantly—because it was fun. Coding for fun is something I’ve missed, and writing down my thoughts, sharing my experiences—that’s something I truly enjoy.
Here’s the thing: don’t be afraid. You’re an engineer. You’re meant to break things, to see how they unfold, to figure out how things can be done. Coding is fun. Find an idea, and start building. It might look like chaos at times—some parts definitely felt like that—but I genuinely enjoyed every bit of it.
So go on, start coding.
Until then, goodbye nerds.