20 Questions to Ask in a Client Interview

Introduction

Ahead of a recent interview with a consulting company, I found myself revisiting a question I've grappled with for years: How do you explain technical decisions to someone non-technical? Or maybe more pointedly: How do you communicate what you're building in a way that shows its value to your client?

As a freelance and consulting engineer, I’ve worked with early-stage startups, large orgs, and everything in between. I’ve had to bridge this gap over and over again. This interview pushed me to synthesize a lot of what I’ve learned, so I decided to turn it into a blog post.

The Setup

The interview format was interesting. It simulated an initial client meeting, asking how I’d gather requirements, communicate architecture, and clarify the scope of a project. I wanted to impress, so I came in with a playbook: visuals, questions, and even a cost estimation tool I built using an AI UI generator.

Here’s a breakdown of my approach.

High level overview

Requirements Gathering

I started by pulling together the types of questions I’ve asked clients in the past. It quickly became clear that 20+ questions would never fit into a one-hour call, but they’re the kind of questions that guide my thinking. Think of them like modular prompts I can pull from depending on the client and project.

Visual Thinking: Diagramming

One of the most effective ways to bridge the tech-client gap is with visuals. Here’s a diagram I brought to the interview (insert your image here).

It outlines a modern JavaScript stack with CI/CD, frontend deployments to Expo or a Remix/Next.js instance, and an optional microservice backend architecture. For most clients, this is a great way to start the conversation around “what lives where” and “how things talk to each other.”

Anticipating the Money Question

Although cost didn’t come up in this interview, it’s something I always try to be prepared for. Clients often ask, “So what will this actually cost to build and run?”

The 21 Questions: Requirements Gathering

These are the questions I came in with, organized by category and numbered.

Pre-Client Interview

0. 0. What do we already know about the client?
   // This is the biggest question I want to ask before going into any client interview. It sets the context and ensures you don’t ask questions you should already know the answers to.

Goals & Constraints

1. 1. What is the core problem you’re trying to solve?
   // Helps uncover the real business need beyond feature requests.
2. 2. What kind of discovery or validation work, if any, has been done on this idea so far?
   // Indicates how much confidence the client has in their solution and how much learning still needs to happen.
3. 3. What would success look like for this project?
   // Reveals how the client measures impact or return on investment.
4. 4. Are there any technical constraints?
   // Prevents misalignment on architecture or infrastructure early on.
5. 5. Does the project need to run on existing infrastructure?
   // Helps avoid surprises and scope creep when integrating with legacy systems.
6. 6. What would a successful project handoff look like for you?
   // Clarifies expectations for documentation, ownership, and training post-build.
7. 7. What is your timeline?
   // Affects technical choices and helps define MVP scope.
8. 8. Do you have a budget in mind?
   // Shapes tradeoffs and solution design from day one.

Users & Access

9. 9. Who are the different types of users?
   // Guides UX decisions and permissions architecture.
10. 10. What devices do they typically use?
    // Helps prioritize platform-specific functionality and performance constraints.
11. 11. Are there any accessibility or language requirements?
    // Ensures you’re not leaving key user segments behind.
12. 12. How many users do you anticipate at launch?
    // Helps estimate load and determine minimum infrastructure needs.
13. 13. How many users do you anticipate post-launch?
    // Informs scalability planning and long-term architecture choices.

Features & Functionality

14. 14. What are the core features you imagine?
    // Defines the shape and scope of the MVP.
15. 15. What are the most common workflows?
    // Centers the build around real user goals, not just interface screens.

Security & Compliance

16. 16. Do we need to worry about HIPAA, GDPR, or similar standards?
    // Compliance needs can dramatically affect design and hosting decisions.
17. 17. Will any sensitive data be collected (e.g., medical info, addresses)?
    // Triggers risk mitigation work like encryption, secure audit logs, etc.

Tech & Maintenance

18. 18. Do you or your team have any tech stack preferences?
    // Aligns with internal team comfort and existing tooling.
19. 19. Are there third-party services or APIs this needs to integrate with?
    // Integration work can impact both timeline and architecture complexity.
20. 20. Who will maintain the system after it launches?
    // Affects codebase design, documentation, and support strategy.

On the Importance of Visual Storytelling

When working with clients, especially those who are not deeply technical, words often fall short. That is where visuals come in.

For this interview, I created a quick sketch using Excalidraw to illustrate how a modern JavaScript stack might be assembled for a greenfield project. The goal was not to show off every technical detail, but to provide a common reference point — something both technical and non-technical people could look at and say, “Okay, I see how this fits together.”

In a client setting, I would likely upgrade the fidelity using a tool like diagrams.net (formerly draw.io). It supports better layering, annotation, and export options that make it easier to hand off or revisit later. But for early-stage conversations or discovery interviews, the speed and flexibility of Excalidraw made it ideal.

Visuals do not just clarify, they validate. They turn abstract conversations into something concrete. If there is one habit I would recommend to any engineer who wants to get better at client communication, it is this: make more diagrams.

“So what will this actually cost to build and run?”

Back when I was freelancing, I used to browse agency sites and noticed many had price calculators. So I built my own using Loveable. It’s a quick, back-of-the-napkin tool I’d actually use live in a meeting to help clients estimate infrastructure and engineering costs.

Turns out Loveable is great at rapidly prototyping UI with Radix and vanilla React. I hit some hallucination walls, but with a bit of cleanup, the result was something pretty slick.

I had my thoughts, and I will definitely be writting a follow up article about it in the near future.

Lessons Learned

Despite the prep, the interview skewed much more toward traditional system design with a strong emphasis on database schema and performance. One key topic was how I’d structure data for surveys with nested conditional questions.

I reached for flexibility and suggested JSON objects. The interviewer noted this could work, but might be suboptimal. We didn’t get to refine the structure together in the limited time, but it reminded me that system design interviews are often database design interviews in disguise.

Final Thoughts

I didn’t get everything perfect. But I walked away with a better sense of how to balance:

• Clarifying business needs
• Communicating architecture visually
• Anticipating client concerns (cost, timeline, handoff)

And I got to learn a few things along the way.