What I Look for Before Writing a Line of Code

Before I open a code editor, I ask a series of questions, not just about what I'm building, but why, for whom, and how it fits into the bigger picture. In my experience, the most expensive problems in digital projects aren't technical, they're strategic. They come from building the wrong thing, in the wrong way, at the wrong time.

"The most expensive problems in digital projects aren't technical, they're strategic."

That's why I treat planning, scoping, and early alignment as part of the build process, not as a separate phase. Code is execution. But clarity is where the real value begins.

1. Is the problem clearly defined?

Too many projects start with a solution in mind before the problem has been fully understood. I look for clarity on what we're solving, and why it matters. This includes understanding the user's pain points, the business objectives, and the desired outcomes, not just features.

"If we can't explain the core problem in one sentence, we're not ready to build."

2. Does the solution align with real-world use?

I always aim to pressure-test ideas before they're coded. That might mean using Figma for a quick prototype, running a stakeholder workshop, or just asking hard questions. Will users actually do this? Does this reduce friction or introduce it? Is there a simpler version worth testing first?

My goal is to cut through assumptions and reduce waste.

3. What's the fastest way to validate it?

I'm a big believer in building lean, even in complex systems. I look for the quickest, cleanest path to a working version, one that gives us feedback early. That might involve reusable components, boilerplates, AI-assisted scaffolding, or integrating existing tools instead of reinventing the wheel.

Speed doesn't mean rushing. It means reducing unnecessary decisions.

4. How will this scale and evolve?

Even when building MVPs, I think about what comes next. Can this architecture support new features? Will this tech stack hold up under load? Will we regret this decision in six months?

I aim to avoid over-engineering, but I also build with modularity and change in mind. Projects grow. The codebase should be ready for that.

5. Who needs to understand this later?

I write and organise code so that it's understandable not just to me, but to the next person who works on it. That means clear naming, purposeful comments, and a structure that makes sense. I also consider the documentation, onboarding, and knowledge-sharing practices that surround the code.

Because sustainable systems aren't just built, they're maintained.

"Writing code is the easy part. Writing the right code, the part that solves the right problem, integrates well, scales properly, and makes people's lives easier, that's where the real work is."

And that work starts long before the first line is written.

If you're looking for someone who thinks before building, challenges assumptions, and delivers with intention, I'd be happy to connect.