Step 1: 3 Weeks of Deep Work Before Writing a Single Line of Code
Before we jumped into design or development, I spent 3 weeks just thinking, writing, and questioning everything about the idea behind MedNote.
Here are the 5 key questions that shaped the foundation of the app:
1. What problem are we solving?
If there’s no clear problem — there’s no point in building.In our case, it was the chaos around medical information: test results here, doctor notes there, reminders lost in messages…People are doing their best to stay healthy, but the system is fragmented.MedNote’s mission became simple: Bring order to the medical mess.
2. Are there similar solutions out there?
Yes — but that’s a good thing. You should check what already exists.We realized that while people could use tools like OneNote, Evernote, or their phone’s native notepad, these tools weren’t built for healthcare organization.Their UX doesn’t match the needs of people managing personal medical histories. That gap became our opportunity.
3. Can it scale?
I’m not excited by static, single-function apps. So I explored different growth paths:- Feature expansion- B2B integrations- Building a community
This project needed to have room to grow, and the possibilities were endless.
4. Does it reflect me?
This one is underrated.I didn’t want to build an app just to sell it.I wanted something I could tinker with, improve over time, and love working on — like restoring a classic car. If I couldn’t see myself doing that, I’d stop right there.
5. Is there a higher mission behind it?
A strong mission makes it easier to attract people who care.
Ours? “Prevention is the key to a healthier life.” Most health issues can be avoided through regular checkups and awareness — MedNote’s long-term vision is to make that easier, more accessible, and even inspiring.Before design, before code — comes clarity. That’s what these 3 weeks were about.
Step 2: One User Story is Enough (At First)
This part took a few days, but can be done in a day. After working through the idea and answering the key questions, it became clear — the direction was right, and the problem was well defined. So we moved on to the next step: writing the initial user stories.
The very first one I wrote was simple:
As a user, I want all my health documents to be stored in a single place.
That was it. Nothing more.
If you’re building an MVP, remember — having one well-defined user story might be the best place to start. It brings clarity and focus, which is everything at this stage.Once we had that core story, we broke it down into sub-stories to understand what “storing” really means in real-life usage.
For example:
- As a user, I want to take and add pictures to the records I already made
- As a user, I want to group my records to track health issues
- As a user, I want to add media to the records I already created
- As a user, I want to have categories (Appointment, Investigation, Treatment, Note) to navigate my data
And so on.
We knew from the start — expansion is the enemy of MVPs. So we kept it simple, clear, and essential.
Step 3: Documentation — Your Future Self Will Thank You
Once the idea and user stories were defined, I knew I needed solid documentation — for the team and for future me. I used Confluence to keep everything in one place, and planned to use Jira for managing tasks.
The first doc I wrote was the Project Scope — just two short paragraphs explaining the core problem and how the app solves it. It started as a mini-essay:
“Many people struggle to keep their medical documents in order… Our app will help bring clarity and structure to their health data…”
If you’ve done your thinking and user stories well, this part flows easily.
User Stories
These formed the backbone of the project.
For MedNote, they evolved from:
- Quick search- Linked records
- Scanning
- Fast entry
- Tags & notes
- Chronological view
- Custom categories
- Security
- Reminders
List it all out. Then tag each as Must Have or Nice to Have. Cut the nice-to-haves. Focus on delivering value with minimal effort.
Functional Requirements
Many skip this — don’t. You’ll thank yourself later when working with new team members.
MedNote’s list included:
- Google/Apple login
- Create/edit/delete records
- Group into cases
- Categorize & filter
- Media upload
Even a rough list gives clarity, helps estimate time and cost, and avoids misalignment.
Roadmap
I like to see things visually. My roadmap wasn’t perfect, but it grounded me:
- Documentation — 2 weeks
- Naming — before design ends
- Design ready — before dev
- Hire dev — after docs & design
- Development — 4–5 weeks
- Landing page — while development
Some tasks had dates, others didn’t. Doesn’t matter. Just start. I used Confluence Whiteboard for it.
Step 4: Wireframes
After finishing the documentation, we moved on to wireframes. The most logical next step was to visually support our user stories — every single one of them.
If you’re documenting user stories, the best thing you can do is follow each one with a basic screen structure.That turns abstract ideas into something real. It also saves a ton of time later — for design, for onboarding, and for development.
You don’t need to overthink the tools. I started with Lucidchart, then switched to Figma. Here’s one of the good template in Lucidchart. Goal was simple: take every user story and translate it into screens.
For example:
“As a user, I want to add a record” — okay, that means:
- A dashboard or main screen
- A new record screen with input fields
- A button that connects the two
You do this for each user story.
Don’t skip. That’s how the project starts to take shape. Not just in your head — but on paper (or screen).
Important note: Wireframes are not design.Keep them functional. Monochrome. Simple.Use minimal color only if you need to show interaction or warnings.Don’t waste time on icons, fonts, or styles.
If your tool supports prototyping — even better. Click through the screens on your phone. That’s where you’ll realize what you forgot: settings, onboarding, password recovery, legal screens. You’ll need to adjust — and that’s part of the process.
The rule is simple:
Only build what’s required to get the user from point A to point B. No more. Not yet.
Step 5 : UI Design — Just Enough to Get It Done
After wireframes, we moved on to UI design — but with the same lean mindset.
We didn’t aim for beauty, branding, or wow-effect. We focused on what was needed to move forward.
We designed the core screens first, and in parallel, I built a small UI Kit to save time on the rest. It included:
- Two button styles
- A basic input component
- A simple text hierarchy (titles, body, captions)
That was the bare minimum — but it allowed even developers to assemble decent-looking screens without constantly waiting on design updates.
This didn’t take long. I have a solid background in design, so I handled this part myself — fast and focused. No Figma wars, no endless revisions.
We intentionally left full branding and visual polish for later. Still, we wanted the app to feel clean and pleasant to use — even at MVP stage.
Fun fact: we initially went with blue as the primary color. It looked good, but didn’t feel right. On the second try, we switched to green tones — and it clicked. Subtle, soft, calm — just what we needed.
In the next chapter: choosing the name, registering the domain and starting development.
Download and experience Mednote on Mednoteapp.com