Before I Write a Line of Code, I Listen: How I Start Projects

If you've never hired someone to build software, the first conversation can feel like a mystery. Do you need a spec? A budget? The right words? You don't. You need a problem, and I'll start there.

I've been solving problems with software since 2007, alongside universities, hospitals, household-name brands, nonprofits, churches and small businesses. The tools have changed a lot in that time. How I begin hasn't: before I write a line of code, I listen.

Why I don't start with what to build

Most people arrive with a solution already in mind: "We need an app." "We need a new website." Sometimes that's right. Often it's a guess at the answer to a problem that hasn't been described yet.

If I start building from the guess, we can end up with something that works perfectly and still doesn't help. So I set the solution aside for a while and get curious about the problem.

Step one: I talk to the people living with it

The person who contacts me is rarely the only one affected. A small business owner has staff who fight the same clunky process every day. A ministry leader has volunteers who dread the Sunday sign-in. A nonprofit director has donors, board members and a team who each see a different piece.

I want to hear from the people who live with the problem, because they know things that never make it into a project brief. They know the workaround everyone quietly uses. They know which step gets skipped when it's busy. They know what they'd fix first.

Sometimes that's one long conversation with you. Sometimes it's a few short ones with the people around you. Either is fine.

Step two: I ask what's actually going wrong

Then I ask plain questions, and I keep asking until the answers get specific:

• What happens today, from start to finish?
• Where does it slow down, break or get dropped?
• Who gets frustrated, and when?
• What does it cost you: time, money, missed people?
• What have you already tried?
• What would "fixed" look like a few months from now?

Notice that none of those are about technology. That's on purpose. A good answer to "what's going wrong" is usually a story, and the story tells me far more than a feature list would.

Step three: only then do we decide what to build

Once I understand the people and the problem, we can talk about the fix. Sometimes it's a web app or site built for your situation. Sometimes it's fixing the email, payments or connections between the tools you already use. Occasionally it's a smaller change than you expected, and I'll say so plainly, even if it means a smaller project.

I'll also be honest if I'm not the right fit, or if something you're hoping for won't solve the problem you described. I'd rather tell you that in the first conversation than discover it halfway through.

Whether you're a business or a ministry

The approach is the same for a founder with a new idea and a church trying to care for its people better. The details differ. A business may be thinking about customers and growth. A church or ministry may be thinking about volunteers, members and the people they're trying to reach. In both cases, the best software is the kind that makes life easier for real people, and I can't build that without knowing who they are.

What to bring to the first conversation

Nothing fancy. A description of what's frustrating is plenty. If you have examples, like a spreadsheet that has grown out of hand or a screenshot of the form people hate, bring them. If you don't know what you need, that's the very thing we'll work out together.

I take on a small number of outside projects each year, so I like to spend real time understanding each one. If you'd like to know more about who I am first, you can read about me or my story. You can also see the products I build for a sense of how I think, or browse my writing.

Have a problem that needs solving? Tell me the problem, and let's start with the people.