How To Break Large Coding Features Into Manageable Steps

A large software feature is rarely one piece of work.

It is usually a collection of smaller changes that depend on one another.

The important skill is not simply making the tasks smaller. It is discovering what depends on what, then choosing an order that lets you learn whether the approach works before too much is built on top of it.

This is especially useful when working with AI. AI can produce a large amount of code quickly, but speed does not remove dependencies between parts of a system.

Before asking AI to build a large feature, first understand its shape.

Find What Must Exist First

Suppose our errands app eventually allows people to share a task list with someone else.

“Add shared lists” sounds like one feature.

But other capabilities may be hiding inside it:

• The app must know which list is being shared.
• It must know which people can access that list.
• Shared information needs somewhere both people can reach.
• Someone needs a way to invite another person.
• The invited person needs a way to access the shared list.
• Changes made by one person need to become available to the other.

These pieces are connected.

You cannot meaningfully build the invitation experience if the app has no concept of who can access a list.

And there is little value polishing the sharing interface if you have not established that information can actually be shared between two people.

This relationship is a dependency between pieces of work.

One step is a prerequisite for another.

A useful question is:

“What must already work before this part can work?”

Keep asking that question and the internal structure of the feature begins to appear.

Think Of The Work As A Dependency Map

A simple to-do list suggests that every task is just the next item in a sequence.

Software work is often more like a map.

For shared lists, part of that map might look roughly like this:

Shared information
↓
List membership
↓
Invitation
↓
Member management

But another part of the work might be relatively independent.

For example, the visual design of a small “Shared” indicator may not need to wait for every member-management feature to exist.

Thinking this way helps distinguish three kinds of work:

Prerequisite work must happen before something else can function.

Dependent work relies on an earlier capability.

Independent work can be developed without waiting for another branch of the feature.

You do not need specialist planning software to do this.

Even a few arrows on paper can reveal that what looked like one large task is actually a set of connected changes.

Do Not Automatically Build Entire Layers At Once

There are different ways to divide a feature.

One approach is to complete an entire technical layer before moving to the next:

Build all the storage → build all the application logic → build all the interface.

Sometimes that order is necessary.

But it can also mean doing a large amount of work before you see whether the pieces actually cooperate.

Another approach is to build a small path through the whole system.

For example, instead of building every possible part of shared lists, you might first prove one simple journey:

Person A shares one list → Person B opens it → Person B can see one task.

That narrow path might involve a small amount of interface, logic and storage.

It does not complete the feature.

But it proves that the main parts can work together.

This kind of end-to-end piece is often called a vertical slice.

The name is less important than the idea:

Build the smallest meaningful path through the system that proves something important.

Once that path works, you can expand it.

Perhaps the next slice allows Person B to add a task.

Another might allow the owner to remove someone from the list.

You are growing a working capability rather than building several large disconnected layers and hoping they join correctly later.

Build The Uncertain Part Before The Polished Part

Not every part of a feature carries the same uncertainty.

Imagine you are unsure whether your chosen approach can reliably keep a shared list available to two people.

At the same time, you already know how to build a polished invitation screen.

It may be tempting to start with the interface because it is visible and straightforward.

But the uncertain part is more important.

If the underlying sharing approach turns out to be unsuitable, much of the polished interface may need to change.

A stronger sequence would prove the difficult assumption first:

Can two test users reliably access the same information?

You might initially use an ugly temporary interface to find out.

If the answer is yes, you have learned something valuable.

Now investing in the full experience makes more sense.

If the answer is no, you have discovered the problem before building several other pieces on top of it.

This leads to an important principle:

When possible, test an important uncertainty before building heavily on the assumption that it will work.

The riskiest part does not always need to be the first code you write. It may have prerequisites of its own.

But once those prerequisites exist, important uncertainty should not be buried at the end of the plan.

A Working Slice Can Teach You More Than A Detailed Plan

You can plan a feature carefully and still discover things only when the software begins working.

Suppose the first simple version of shared lists works technically.

But when you use it, you realise that people cannot easily tell whether a list is private or shared.

That reveals a requirement that may not have seemed important on paper.

Or perhaps sharing one list works well, but supporting other shared lists exposes confusion about ownership.

The working software has taught you something.

This is why useful implementation plans leave room for learning.

You do not necessarily need to design every later step before starting the first one.

Plan enough to understand:

• The main dependencies.
• The first useful path.
• The important uncertainty you want to resolve.

Then use what you learn to improve the remaining sequence.

Some Changes Should Stay Together

Breaking work apart has limits.

Suppose one change would leave the project unable to run until the immediately following change is also completed.

Those pieces may belong together.

For example, imagine changing how the app represents a task in a way that requires the code loading those tasks to change at the same time.

Doing only half of that work may create a temporarily broken project without providing any useful checkpoint.

The aim is therefore not:

“Make every step as small as physically possible.”

It is:

Make every step as small as practical, while still leaving a coherent result.

A good stopping point should give you something understandable.

You should be able to say:

“This capability now works.”

or:

“This foundation now exists and the existing app still works with it.”

If you cannot explain what the intermediate state means, the division may not be useful.

Use Dependencies To Choose The Order

Once you can see the pieces, ordering becomes easier.

Consider a simplified shared-list feature:

A. Store information somewhere multiple people can access.
B. Represent who belongs to a list.
C. Allow one test user to see a list belonging to another.
D. Build the invitation experience.
E. Allow members to add and complete tasks.
F. Add controls for removing members.

Some ordering is forced by dependency.

You cannot remove a member before membership exists.

Other ordering is a strategic choice.

This is a much stronger way to plan than simply asking:

“What screen should we build first?”

The better question is:

“What needs to be true first, and what should we prove before more work depends on it?”

Ask AI For A Dependency-Aware Plan

For a genuinely large feature, AI can help you find the structure before it starts writing code.

You might say:

“Do not implement this yet. Break the feature into coherent pieces. Show which pieces depend on others, identify the smallest useful end-to-end version we could build first, and point out any important assumption we should prove early.”

This is different from asking AI for a generic checklist.

You are asking it to explain the relationships between the work.

You can then examine the proposed order.

Perhaps AI has placed a polished interface before an uncertain technical capability.

Perhaps two supposedly separate steps actually need to happen together.

Perhaps the first version is still much larger than necessary.

Planning before generation gives you the opportunity to change the sequence while changing it is still cheap.

The Goal Is Earlier Evidence

Breaking large changes into smaller parts is not valuable merely because smaller tasks look more organised.

The real advantage is that each useful step can tell you something.

You learn:

Does the underlying approach work?

Then:

Do the connected parts work together?

Then:

Does the next behaviour work on top of them?

Instead of making one enormous bet, you make a sequence of smaller bets and learn between them.

That is a powerful way to build software with AI.

AI can accelerate each implementation step.

Your responsibility is to make sure those steps are being taken in an intelligent order.

For a large change, remember three questions:

What depends on what?

What is the smallest end-to-end path that would prove the idea works?

Which important uncertainty should we resolve before building more on top of it?

Those questions turn a large feature from a vague block of work into an understandable sequence.

As those sequences grow across multiple conversations and development sessions, another problem appears: important decisions and discoveries can be forgotten.

In Blog 14, we will look at how to preserve project knowledge so earlier decisions continue to guide the project as it evolves.