To your developer, it’s probably a lot more complicated.
Trigger warning for developers: this article may use words and phrases like OAuth, APIs, SDKs, databases, fast, easy, and uncomplicated together - sometimes even in the same sentence.
For years, I searched for the perfect to-do list app. I wanted to find an app that would help me keep track of my weekly, monthly, and yearly priorities. But, none of the To-Do list apps I found on the App Store did what I wanted them to.
Finally, I decided to build my idea myself. After several experiments with everything from YouTube courses to MIT App Builder, I realized I couldn’t do it alone. I began asking experienced mobile developers for help.
“It super simple,” I told them, “really easy. My idea is so basic you could do it in a day. I’ll pay you.”
I figured a To-Do list was one of the first things you learned to build in CS class. It had to be so easy that a developer could build it in their sleep.
Day 1: Hello World
Day 2: To-Do List
Right?
Again and again, the moment they heard “easy,” “simple,” or “basic” developers seemed to snap. It was as though I’d somehow triggered a flashback to whatever the developer version of ‘Nam is.
“Easy?!?” they’d gasp, eyes filled with confusion and terror. “Your app idea will be ‘really easy’ to build?”
I learned that many software developers have a strained relationship with the words “easy” and “simple.” Every developer seemed to have had a boss or client who demanded a quick fix for an incredibly complicated software product. Everyone had a story about being told a task was simple, only to run into something complex.
“Just pull the users’ location for the last time they used Apple Pay within ten minutes of logging into Twitter. Save that to iCloud. Then if you just throw together an AI...”
It turns out that mobile app development can be weirdly difficult. Even saving and retrieving data from device storage can get complicated, even though it’s something most apps will need to do. My app idea was comparatively, relatively simple, but even then, the developer and I faced many challenges getting it built.
The idea:
Users write in tasks like you’d do with a standard To-Do list. But, instead of adding due dates, users would assign each task to “this week,” “next week,” “this month,” etc. Tasks would move to the appropriate category as time passed. For example, a task added to “this month” would move to “next week” after two weeks had passed.
Right away, we ran into a lot of questions. If I entered a task for “this week” on a Friday, should it remain in “this week” for seven days, or one? How would we handle overlaps? Should “this month” include the tasks in “this week?” If you add a task for “this year” but it’s already December, should that go right to “this month?”
The problems:
That sounds simple, right?
Right away, we ran into a lot of questions. If I entered a task for “this week” on a Friday, should it remain in “this week” for seven days, or one? How would we handle overlaps? Should “this month” include the tasks in “this week?” If you add a task for “this year” but it’s already December, should that go right to “this month?”
Then there was the UI. I wanted to try neumorphism or “soft UI” that has become trendy on Dribble and Behance, rather than using standard, out-of-the-box defaults. But, a custom UI is a whole new layer of coding complexity and isn’t always as accessible for the visually impaired - or those who like dark mode.
Finally, there was data retrieval and lazy loading. We wanted users to be able to view their completed tasks in reverse chronological order. A power-user might have thousands of completed tasks, especially if they used the app for a year or more. It turns out that even modern phones don’t like pulling that much data at once.
So what is a simple app idea?
Here’s a general rule of thumb: think of every new feature you want as a new app. Whatever cost or time frame your developer estimated for your core, V1, most basic, minimal viable product might be about what you can expect for each new feature you want to add.
For example, imagine you have a To-Do list app, and you want to give users the ability to tag each task with a location. You are safest assuming the location feature might be as complicated as building the original app.
Of course, that’s a very rough rule of thumb. Some features are easy to add in mobile apps. Other features, like backing up to iCloud, might seem simple, but can be complicated.
The simplest mobile app would probably be one that only displays text when you open it. (Even then, you’d have to make some choices about fonts and sizing.) After that, a notes app or To-Do list with a standard UI might be straightforward for an experienced developer. Beyond that, every new feature ads a layer of complexity.
Imagine you ask a mechanic to build you a race-car. Then you get married and have a baby, and decide your race-car needs more storage. You might have to build a whole new vehicle, and you might find that speed and storage size aren’t that compatible. You can’t upgrade a Ferrari to a minivan. That’s what building an IOS app can feel like.
If you want to judge for yourself whether my app idea was simple, you can find it here on the IOS app store.