I like the end of the year. It’s that magical time when you look back, judge your decisions, celebrate your wins, and pretend that next year you definitely won’t repeat the same mistakes. My year was great—I learned a lot, officially leveled up to “senior” (which mostly means I’m now allowed to say the word architecture with confidence), and discovered that system design is a whole new playground.

The end of the year is also the perfect moment to plan a new learning project. And I have one: in 2026, I’ll be working on designing an iOS weather app (specifically for iPad). It will be fun, chaotic, educational, and absolutely a reason to start a new blog series. So today, let’s begin with the essential part: what you need to do before writing a single line of code.

1. Research First: Understanding the Problem Space

Research is the most underestimated part of building any app—yet it’s the part that saves you the most tears later. As a mobile developer working on an iOS weather app, the first step wasn’t opening Xcode. It was opening… the App Store. And Google. And everything in between.

Market research means:

What weather apps already exist?
What do they do well?
What do they do terribly?
What key features do users actually care about?
And my favorite: how do we avoid adding features just because someone whispered the word AI in a meeting?

One of my 2026 goals is personalization done right, not personalization because “AI magic will surely fix it.”

2. Defining the Core Value of the App (AKA: Why Does This Thing Exist?)

Before setting up the project, naming folders, or arguing about SwiftLint rules, you need to answer the golden question:
What’s the point of this app?

Not every idea makes it into Version 1.0. That’s normal. That’s healthy. That’s how you avoid crying later.

So you gather the team (or your internal committee of voices, if you’re a solo developer like me), and you discuss what absolutely must be included.

For us, the essential weather app features are:

maps
forecast
severe weather alerts
widgets
modes for the weather (yes, I’m teasing—stay tuned)

v1.0 will not win a design award yet. But it will exist, it will work, and it will not collapse under its own ambition. That’s a win.

3. Understanding Your Future Users (No, You Are Not the Only User)

Sure, we all use weather apps. But we also have actual users for our weather data—and the mobile app is for them too. So before jumping into development, we asked them what they wanted.

Do they need a more accurate forecast? Do they crave simplicity? Are they dreaming of features we haven’t thought about?

Talking to users early:

helps prioritize
saves time
prevents building features that nobody loves
protects your sanity

Think before you code. Communicate always. And occasionally pretend you’re not offended when users hate your favorite idea.

4. Exploring Existing Weather Data (AKA: What Exactly Do We Have?)

Great news: we have data.
Less great news: I had no idea what kind at first.

Weather state? Air quality? Hourly data? Alerts? Historical patterns? Magic?

This stage involves exploring what the backend already offers and identifying its limitations. This influences everything—from UI to system design to which features are realistic for v1.0.

5. Designing the System Early (Save Future You From Burnout And Refactoring)

High-level architecture is my best friend now. Designing the system after writing the first classes? No, thank you. I’ve done enough refactoring in my career to know that it kills joy, excitement, and also company money (and yes, the cliché “time is money” is still true, even though I hate it).

Good system design means:

scalability
maintainability
fewer nightmares
fewer meetings where someone asks, “Why is this like that?”

Share your system design with other engineers. They will have great ideas, and your project will thank you later.

6. Sketching the User Interface (My Love/Hate Relationship With Figma)

Ah, Figma. My favorite tool and also the reason I sometimes question my life choices.

As a mostly solo developer, Figma is my go-to for UI design—even if I complain about it loudly. And the good news is: AI can help generate clickable UIs with mock data, which is delightful in a “please don’t replace me” kind of way.

Start with messy sketches. Then build flows. Then create prototypes.
This is the moment when discussions escalate, and significant design decisions are made. And it’s 1000× cheaper than redesigning after development starts.

7. Finalizing the Pre-Coding Checklist

Before writing the first line of Swift, make sure you have:

Confirmed feature list for v1.0
User flows mapped
UI prototype approved
Backend capabilities understood
Architecture plan drafted

If all of this is ready, coding will feel like a well-deserved vacation. Or not.

Conclusion: Why All This Planning Matters

And that’s it. Before you write a single line of code, you plan, draw, research, discuss, fight, make peace, and sometimes stare at the ceiling questioning your career choices.

What have I learned after 5 years of programming?
Sometimes the code is the least important part of the entire system.

Good design prevents expensive bugs, catastrophic refactors, and mysterious production issues nobody saw coming. Invest time in planning so future you doesn’t have to whisper “why did I do this?” at 2 AM.