When starting new substantial functionality one of the first questions that pops up is: “What should we do first?”

That question is deceptively simple but you’ll get different answers based on who you ask.

Here are four different perspectives.

Back-end

If you were to ask a back-end engineer where to start from, surely they’d answer the back-end.

You can’t effectively design something if you don’t know what the business logic is. Only after you know what the actual process is can you build an interface for it.

An even more hardcore subset of this is the API-driven approach that focuses on what data and processes might be exposed to others.

Front-end or design

Similarly, a front-end engineer or a designer would definitely say that you need to first see what actions the user will need to preform. Only after that’s done will you have an idea of what data will be generated and how it needs to be manipulated.

Business logic is important but the way users actually get things done is even more so.

Basecamp

In Shape Up Basecamp presents a very compelling argument that you need to get one complete piece done.

That helps you progressively build up more and more of the feature while having each intermediate state at least somewhat functional.

Squarespace

Squarespace offers a different perspective within the context of building a risky feature. In an article about good tech debt the author argues that the most risky part should be built first.

First of all, you’re minimizing risk in case it doesn’t work out.

But besides that, you cannot accurately plan something that isn’t well defined. You often come up with new and better ways of doing things as you’re doing them.

This approach is also good because the first version is often not what ends up in production.

So, what should be done first?

As with most questions the answer is it depends. All approaches have their place.

If a feature manipulates a lot of data the back-end might be the most impacted so should be done first.

If a feature is used very frequently, it would be prudent to ensure that the user experience is designed well at the start.

If you’re building something exploratory but with a specific purpose in mind, getting progressively better versions up and running might be a better approach.

And if it’s something that’s very complex or not very well defined, the parts most likely to fail should probably be investigated before building the rest.

The part that everything else depends upon

From the examples above it’s the part that everything else depends upon is the most impactful.

If the base dependency fails, or isn’t well designed or built, the rest is irrelevant.

If the design of the back-end process doesn’t take into account all the data needed, the interface can’t be designed well.

Conversely, if the experience isn’t designed well for a particular job, the backend will have to be redone as well.

You don’t want to spend time building a big feature without understanding how to do all the intermediate steps well.

If the uncertain technically complex part can’t be done well, then the rest doesn’t matter.