How To Plan An App Before You Start Coding

To start planning an app, answer three questions: Who is it for? When will they use it? What should it help them achieve?

These answers give your idea a clear purpose before you choose features or ask AI to write code.

You may already picture a dashboard, reminders, a calendar, or a place to write notes. Those ideas are useful starting points. The next step is to connect them to something a person needs to accomplish.

This blog explains that first part of app planning: describing the result your app should deliver.

Start With What The Person Wants To Achieve

A feature is something the app provides, such as search, a reminder, or a button for adding a task.

A result is what a person achieves with that help.

In our task app, “send a reminder” describes a feature. “Help someone remember an errand when they have a chance to do it” describes the intended result.

Several features could support that result. A reminder might help. So might a clear list that the person checks before leaving home.

Starting with the result gives you room to compare these approaches before committing to one.

It also helps you question additions. If AI suggests a chart showing how many tasks someone created each month, you can consider whether that information helps them accomplish what they came to do.

Decide Who Your App Is For

Begin with the information about the person that affects how the app should work.

Consider these two people:

• Someone recording personal errands throughout the day.
• Someone assigning tasks to other people at work.

Both might use a task app. However, their needs differ.

The person recording errands may need to capture a thought quickly and find it later. The person assigning work may need to know who is responsible and whether others can see changes.

“People who need to organise tasks” leaves those differences unclear.

A more useful description identifies the person’s relevant situation:

“This app is for someone who wants to keep track of their own everyday errands.”

That gives you a starting point. You can add details as they become relevant, without building a long profile of an imaginary user.

Understand When They Will Use It

Imagine someone remembers an errand while leaving the house. They have only a few seconds to record it.

Now imagine the same person sitting down on Sunday to plan the week.

A detailed form might be manageable during weekly planning but frustrating at the front door.

The situation helps explain what matters in the design. Consider:

• What is the person doing when the need appears?
• How much time or attention do they have?
• What information do they already know?
• What makes the situation difficult?

For our task app, we might describe the moment like this:

“A person remembers an errand while doing something else and wants to record it before they forget.”

This gives a reason for making task entry quick and easy to find.

Describe The Useful Result

“Make life easier” expresses a good intention, but it gives little direction for development.

“Let someone record an errand and find it when they are ready to act” is more specific.

You can imagine the person’s situation before and after using the app.

Beforehand, they are trying to keep the errand in their memory. Afterwards, they have a record they can return to.

The result should also be realistic. Recording an errand does not guarantee that someone will complete it. The app helps them remember and organise it, while the action itself remains theirs.

This distinction keeps your app’s purpose clear and helps you avoid promising more than the software can deliver.

Write Your App Idea In One Clear Sentence

Bring the person, situation, and result together:

“The app helps someone managing personal errands record a task when it comes to mind and find it again when they are ready to act.”

This sentence explains who the app helps, when it helps, and what the person gains from using it.

You can use this simple pattern:

“My app helps [a person in a particular situation] to [achieve a useful result].”

For example:

“My app helps a home cook use ingredients they already have to decide what to make for dinner.”

Or:

“My app helps a student collect assignment deadlines in one place so they can see what is due next.”

Each description gives a direction without deciding every screen or feature.

The sentence is a thinking tool. Adjust the wording until another person can understand the purpose without needing you to explain it again.

Use That Purpose When Working With AI

Compare these two requests:

“Build a task app with categories, reminders, a calendar, and a dashboard.”

And:

“I want to help someone record personal errands quickly and find them later when they are ready to act. Suggest a simple experience that supports that result, and explain your choices.”

The second request gives AI a purpose to work towards. It also gives you a basis for judging its suggestions.

For example, categories might make tasks easier to find, but choosing a category could slow down task entry. You can discuss that trade-off using the situation you described.

AI can help you explore options. Your understanding of the person and intended result guides the decision.

Keep Features Connected To The Purpose

As ideas appear, ask:

How would this help the person achieve the intended result?

For the personal errands app, quickly entering a task has a clear connection. Assigning work to a team introduces a different experience involving other people and new responsibilities.

That could become a worthwhile direction, but it changes the purpose you originally described.

Keeping a short written description makes those changes easier to recognise. You can choose them deliberately instead of allowing the app to expand through unrelated additions.

Your first description can also change as you learn. You may discover that finding tasks later is harder than recording them. Update the purpose to reflect that understanding.

You now have a foundation for choosing what belongs in the app. In the next blog, we will use it to define the smallest complete experience that can deliver the intended result.

When AI can write code for you, how much do you need to learn yourself?

You do not need to memorise every command or understand every line before you begin. However, you need enough understanding to guide the work and make decisions about the result.

That starts with being able to explain what your app should do, how its main parts work together, what happens to its information, and how you know whether a change succeeded.

These are things you can learn gradually as you build.

Know What The App Is Meant To Do

The first thing you need to understand is the result you want someone to achieve.

For the task app used in our earlier examples, you might say:

“A person can write down something they need to do, find it again later, and mark it as finished.”

That sentence gives you a clear purpose against which to judge changes.

If AI adds a calendar, colour themes, and a points system, you can ask whether those additions help deliver the intended experience. You have a basis for deciding what belongs in the app.

You should also understand its important rules.

For example, should a finished task remain available? Can someone change its name? What should happen if they try to add a task without entering any text?

AI can help you explore these questions. The decisions should reflect what you want the app to do.

Know the main parts and their responsibilities

You do not need to remember where every line of code lives. You do need a basic picture of how the app works.

For a simple task app, that picture might be:

• The screen shows tasks and receives actions.
• The app’s rules decide what those actions mean.
• The saving system keeps information available for later.

These responsibilities may be spread across several files. Understanding them helps you locate the area involved in a change.

Suppose tasks appear correctly but disappear after the app closes. You can recognise that the problem may involve saving or loading information. Changing the colour of the task list would not address that behaviour.

A useful explanation from AI might answer:

“Which parts of this project display tasks, change them, and save them?”

The aim is to build a simple map you can use when discussing the work. Chapter 3 will develop this understanding in more detail.

Know what happens to the information

Many apps receive information, change it, and keep some of it for later.

You should be able to follow that movement in everyday language.

In the task app:

“The person enters a task name. The app creates a task, saves it, and shows it in the list. When the person finishes it, the app saves that change too.”

This description helps you connect what appears on the screen with what the software is doing.

It also raises important questions:

• Does the information stay on the person’s device?
• Is any of it sent to an external service?
• What remains after the app closes?
• What happens when someone deletes it?

These questions matter even if AI writes all the code involved.

For example, introducing an online service could change where task information is stored and who has access to it. You need to understand that decision before accepting the change.

Understand the consequences of a change

When AI proposes a change, aim to understand its purpose, the parts it affects, and its possible consequences.

Consider a request to remove finished tasks from the main list.

There are at least two ways to interpret it:

• Hide finished tasks from that view while keeping them saved.
• Delete finished tasks from storage.

Both could make the screen look the same immediately afterwards. Their consequences are different.

If the tasks are only hidden, the person might view them again later. If they are deleted, that information may be gone.

You do not need to understand every instruction used to make this change. You do need to know which behaviour you are accepting.

A useful question is:

“Does this change only affect what the person sees, or does it also change or delete saved information?”

The more lasting the consequences, the more understanding you need before proceeding.

Know How To Recognise A Successful Result

Before accepting a change, you should be able to describe what would show that it worked.

For example:

“When I mark a task as finished, it should look finished and remain that way after I reopen the app.”

You now have something specific to compare with the result.

This connects to the previous blog’s distinction between claims and evidence. Your role includes understanding whether the available evidence addresses the behaviour that matters.

A successful check of the screen’s appearance would cover only part of this example. You would still need evidence that the change was saved.

Later chapters will explain testing in more detail. The foundation is knowing what success means for the particular change.

Know How You Could Recover

You also need to understand what would happen if a change went wrong.

Could you return to the previous working version? Would doing so restore only the code, or would saved information also need attention?

You will learn about version history and backups later. For now, keep this distinction in mind:

Restoring an earlier version of the code does not necessarily restore information that was changed or deleted.

Knowing the recovery options helps you judge whether a proposed change is ready to try. It is especially important when the app already contains information that matters to someone.

Know Which Responsibilities Remain Yours

An app can affect people beyond its creator. It may collect personal information, request access to a device, take payments, or depend on another company’s service.

You need to recognise when those choices require further attention.

For example, if the task app begins sending task names to an external service, you should understand why that is necessary, what is sent, and what users need to know.

Chapter 7 will cover legal and platform responsibilities, including privacy policies, user agreements, and distribution requirements. When those issues affect an early design decision, you can read the relevant guidance before continuing.

The same principle applies to technical decisions with consequences you cannot yet assess. AI can help explain them, and there will be situations where review by an experienced developer or another qualified professional is appropriate.

Part of directing the work is recognising when you need that help.

Build your understanding around decisions

You do not need to pause the project and study every unfamiliar detail.

Focus first on the knowledge needed for the decision in front of you.

If you are changing a button’s wording, understand its meaning and where it appears. If you are changing how tasks are saved, understand what information is affected, how existing tasks will be handled, and what could happen if saving fails.

This gives your learning a practical direction.

When an explanation is unclear, you can ask:

“Explain this using the task app as an example. What changes for the person using it, what happens to their information, and what could go wrong?”

Then try to describe the answer in your own words. Any part you cannot explain points to something worth clarifying.

You are ready to delegate more confidently when you understand the purpose, consequences, and evidence well enough to make a decision. Your knowledge can deepen as the software grows.

In the next chapter, we will turn that first responsibility into a clearer foundation for development: describing the result you want before choosing the features.

Why Plausible Code Can Still Be Wrong

AI gives you a piece of code and explains what it does. The explanation is clear. The code looks organised. It even includes a message saying the problem is fixed.

How much confidence should you place in that answer?

The difficulty is that an answer can look correct before anyone has shown that it works. This is what plausible means: something seems reasonable and believable.

When you build software with AI, you need to recognise the difference between a convincing answer and a result supported by evidence.

---

A clear answer can contain a wrong assumption

Imagine you are building the task app from the previous blog. You ask AI to let people mark tasks as finished.

AI creates a button that changes the task’s appearance. When you press it, the text becomes grey and a tick appears beside it.

That looks right.

However, after you close and reopen the app, the task appears unfinished again.

The change handled what appeared on the screen, but it did not save the completed status.

This can happen even when the code is neatly written and the explanation sounds sensible. The proposed solution may cover only part of what you meant.

Sometimes your request leaves an important detail unstated. Sometimes AI overlooks a requirement you did provide. Either way, the result needs to be compared with the intended behaviour.

---

Code can be valid without doing the right thing

There are different ways for code to be wrong.

Some mistakes prevent the software from running at all. Others allow it to run while producing an incorrect result.

Consider a shopping app that calculates the total price of two items:

• The first item costs $10.
• The second item costs $5.
• The app displays a total of $10.

The code might run without showing an error. It may simply leave the second item out of the calculation.

The computer has followed the instructions it received. Those instructions failed to produce the required result.

This is why “the app runs” and “the app works correctly” are different claims. Running successfully is useful evidence, but it answers only part of the question.

---

Correctness depends on the surrounding app

A piece of code can make sense on its own and still be unsuitable for your project.

For example, AI might add a new way to save tasks without realising that your app already has one. One screen could then read from the existing saved information while another uses the new version.

Each part may appear reasonable when viewed separately. Together, they can produce confusing behaviour.

A person might add a task on one screen and be unable to find it on another.

To judge a change, you need to consider how it fits the existing software:

• Does it use the information the app already stores?
• Does it follow the app’s existing rules?
• Does it change something another part relies on?

You will learn more about software structure later. For now, remember that code belongs to a larger system. Its surroundings affect whether it is correct.

---

Familiar examples may leave out important conditions

A solution may work for the example used to create it while failing in another ordinary situation.

Suppose AI creates a feature that finds a task using its name.

You try it with one task called “Buy groceries,” and it works.

Later, you create two tasks with the same name. When you mark one as finished, the app changes the other.

The first example did not reveal the problem because every task had a different name. The solution depended on an assumption that was easy to miss: task names would always be unique.

This is one reason a successful demonstration cannot answer every question about reliability. It shows what happened under the conditions of that demonstration.

The useful habit is to ask:

What conditions does this solution depend on?

You do not need to imagine every possible failure. Start by noticing ordinary variations in how someone might use the app.

---

Separate explanations, claims, and evidence

When you read an AI response, it helps to distinguish three things.

An explanation describes how something is meant to work

For example:

“When the user finishes a task, the app updates its saved status.”

This helps you understand the proposed design.

However, an explanation alone does not establish that the code behaves that way.

A claim states that something is true

For example:

“Completed tasks now remain finished after restarting the app.”

That is a statement about the result. It may be correct, but you still need to know what supports it.

Evidence shows what was actually checked or observed

For example:

“I marked a task as finished, closed the app, reopened it, and confirmed that the task still appeared finished.”

This gives you a concrete observation to assess.

It also has a limit: it describes one check under particular conditions. It does not automatically establish that every related situation works.

These distinctions help you ask a better follow-up question:

“What did you check, and what did you observe?”

That question is more useful than asking for reassurance alone.

---

Confidence should match the evidence

Different checks support different conclusions.

If the code has only been read, you have a review of the code.

If the app has opened successfully, you know it can start under those conditions.

If someone has completed the task journey and confirmed the saved result after reopening, you have evidence about that journey.

Each adds confidence, but each covers a different amount of ground.

Be careful when an answer moves from a narrow observation to a broad conclusion. “The app opened” does not support “all features work.”

The same principle applies when AI performs checks for you. Its report should make clear what it checked, what happened, and what remains untested.

---

Asking AI again does not settle the question

If you feel unsure, it is natural to ask:

“Are you sure this is correct?”

AI may reconsider the code and find a problem. That can be helpful. But another confident answer still needs support.

You can make the review more useful by asking specific questions:

• “Which assumptions does this solution make?”
• “Does this change save the result or only change the screen?”
• “What ordinary situation could make this behave incorrectly?”
• “Have you run this, or are you judging it by reading the code?”

These questions encourage a more precise account of the work.

If uncertainty remains, the next useful step is to investigate the behaviour. Repeated agreement does not replace that evidence.

---

You can make judgments without understanding every line

As a beginner, you may not yet be able to spot a mistake by reading code. You can still recognise important differences between the intended result and the actual result.

You can notice that a task disappeared, a total is wrong, or a button changed the wrong item.

You can also recognise when an answer offers reassurance without explaining what was checked.

Your technical understanding will grow. Until then, clear expectations and concrete observations give you a useful starting point for evaluating the work.

In the next blog, we will define what you need to understand yourself so you can delegate to AI while keeping control of the software you build.

What It Means to Build Software With AI

An app turns actions into results

Your description leaves decisions to be made

You direct the work

Progress means a useful result works

Receiving a large amount of code can feel like progress. So can adding several new screens.

A more useful question is:

What can a person now do successfully?

In the task app, being able to add a task, find it after reopening the app, and mark it as finished is meaningful progress. It is a small experience that works from beginning to end.

This gives you a practical way to think about building. Each change should help produce a result you can explain and observe.

---

The idea to carry forward

Building software with AI is a cycle of describing, creating, running, checking, and improving.

AI helps turn your intentions into code. You guide that process by making decisions and comparing the software’s behaviour with the result you want.

The next blog explains why code can look convincing and still be wrong—and how understanding that helps you make better judgments.