Introduction

A while back, I read about this process, from another developer, can’t even remember where, but it described a way of building software that felt oddly familiar. Almost like it had been plucked from my own memory, but written down with more structure and clarity.

That structure helped me refine the way I already worked. And now, even 20 years later, it’s still my go-to process whenever I’m starting something new. Whether I’m building a quick prototype, helping a client, or launching a new product — this method keeps me sane, clear, and productive.

It’s simple. Surprisingly simple. So simple you might think, “Well, duh.” But the truth is, most developers and teams still don’t do this. Not consistently. Not thoroughly. Not early enough.

Let me show you what I mean.

Don’t Start with the Code

Most people open their editor the moment an idea hits. I used to do that too. It feels good — like you’re moving fast.

But often, you’re just rushing into a mess.

You start building screens before you know what data you’re working with. You guess at features instead of solving real problems. You paint the walls before laying the foundation.

Here’s what I do instead.

Step 1: What, Who, and How

Before anything else, I write — in plain, simple language — what I’m building, who it’s for, and how I expect people to use it.

No fancy frameworks. No personas. Just clarity.

“This is an app for freelance designers to track their projects. It’s meant to help them stay organized, see deadlines at a glance, and feel less overwhelmed. I expect them to check it every morning and use it again in the evening.”

That’s already plenty.

Want to go deeper? Great. Add problems you’re solving. Outline user pain points. But don’t overthink it. The point is to start with a real reason and a real person in mind.

Step 2: Map the Data

Once I know the “what” and the “who,” I move on to the data.

This is the part most people skip — but it’s one of the most valuable things you can do.

I ask:

  • What are the main objects in this system?
  • How do they relate?
  • What actions can be taken on each?

For example:

  • A user creates projects
  • Projects have tasks
  • Tasks can be marked complete or given a due date
  • Tasks can belong to a category

You don’t need to draw out the perfect schema. Just start sketching relationships. Think in terms of nouns and verbs. It gives your product structure, and makes everything else easier — especially when you’re building fast.

Step 3: Sketch the Flow

Next, I think about the screens.

  • What’s the first screen users see?
  • Where can they go from there?
  • What actions happen on each page?

Sometimes I’ll sketch this on paper. Sometimes I just jot down a list.

This part is about flow. It’s how your app feels in motion. The data model gives it bones. The flow gives it life.

You can go back and forth between steps 2 and 3. They inform each other. But together, they build the whole system before you touch a single line of code.

Step 4: Choose the Tech

Now that I know what I’m building, who it’s for, what data I need, and how the user moves through the product — now I choose my tools.

  • What frontend makes sense?
  • What kind of backend do I need?
  • Is this mobile-first? Web-first?
  • Do I need real-time sync, or will a simple API do?

At this point, the tech stack almost picks itself. There’s no guessing, no overengineering. You’re just filling in the gaps.

Step 5: Build It

This is the fun part — and now, it’s actually fun, because I’m not wandering.

The product is already half-built in my mind and on paper. I just need to assemble it.

Coding becomes fast and focused. Design decisions are grounded in user needs and data. And best of all, I stay motivated because I know exactly what I’m trying to deliver and why.

Try It Yourself

You’re probably doing some of this already — maybe without realizing it. That’s great.

But I invite you to try doing it on purpose. Start your next project by writing out the “what, who, and how.” Map your data. Sketch your flow.

It doesn’t take long. In fact, it saves you time.

This method has helped me build faster, design better, and stay focused — for 20 years. It might just do the same for you.

Let me know if you try it.

– Jake