Article summary
Startups and enterprises operate on different timescales. Small teams move fast, iterate quickly, and can pivot on a dime. Large organizations have established processes, multiple stakeholders, and approval chains that exist for good reasons. Building software for these kinds of organizations can lead to friction due to the differences in development styles and frameworks.
But that friction doesn’t have to slow projects down. The key is identifying where these differences will show up before they become blockers. When you address the right questions early, before the contract starts or in the first few weeks, you can turn potential friction into productive collaboration.
I’ve worked with large organizations like state governments (Michigan and Louisiana), the Veterans Administration, and large private-sector enterprises, including some in the Fortune 500. This guide is what I wish I had at the beginning of those engagements: a checklist of the questions that matter most when forming a team with enterprise clients.
The goal isn’t to change how enterprises work. It’s to understand their systems and working styles early enough that you can work effectively within them.
Topics
1. Organization & communication
Why this matters: The person who approved the contract budget often isn’t the person giving you daily feedback. If information doesn’t flow back to decision-makers, you risk building the wrong thing—or building the right thing but having no one positioned to advocate for it internally.
Questions to ask:
- Who approved this engagement, and what’s their relationship to the team we’ll work with daily?
- Who are our users, and how do they relate to the technology group within the organization?
- If they’re different groups, how do we balance priorities and needs between them. It may be helpful to use the cost | quality | speed triangle framework to discuss these priorities.
- Are there specific communication channels or meeting cadences we should follow?
- How does feedback reach stakeholders who aren’t in our standups?
- Who has final sign-off on major decisions or scope changes?
Map it out: Create an org chart early showing direct collaborators, indirect stakeholders, and how information flows between them. Then map out their priorities and identify potential mismatches to address as a group.
2. Development methods/frameworks
Why this matters: Many enterprises say they’re “agile” but still budget and plan in waterfall phases. This mismatch creates friction when your team expects iterative discovery but the client expects a fixed scope with phase gates. Identifying this gap early prevents months of misaligned expectations.
Questions to ask:
How does the organization typically build software—waterfall phases or iterative sprints?
Does the full product scope need to be defined from the beginning, or is there flexibility to adjust scope as you learn?
What does “done” look like at each milestone? Is it working software or documentation deliverables?
How much room is there to adapt the process to accommodate early-stage product development?
Bridge the gap: Document where your approaches differ and discuss potential friction points as a team. Agree on hybrid practices that respect both methodologies.
3. Development standards, privacy, and security
Why this matters: Development standards and enterprise security practices can complicate seemingly simple features. If they’re discovered late in the process, they can pause development entirely. What seems like a simple feature might trigger internal requirements or external standards (HIPAA, SOC2, etc) that add weeks of work. Understanding what’s mandatory versus aspirational helps you plan realistically.
Questions to ask:
- What security frameworks or compliance standards apply to this project (SOC2, HIPAA, etc.)?
- Are there required architectural reviews before you can begin building, or code quality gates, security scans, or penetration tests before deploying production code?
- What’s considered “table stakes” that must be in place from day one versus nice-to-haves that can wait?
- Who reviews and approves security and compliance decisions?
Prioritize early: Work with stakeholders to create a clear list of mandatory requirements versus future enhancements. Build the foundation correctly, but also identify features that are likely to morph or change over time. It could be those features have a lighter pass from standards until they’re more concrete.
4. Code & review
Why this matters: Code review processes exist for good reasons like quality, knowledge sharing, and security. But rigid processes designed for mature products can slow early prototyping. Finding the balance between rigor and speed prevents bottlenecks while maintaining standards.
Questions to ask:
- Where will code be stored, and who has access?
- What does the review and approval process look like? How many reviewers? How long does review typically take?
- Is the process flexible enough to accommodate rapid iteration on early-stage software?
- Are there automated checks (linting, testing, security scans) that must pass before merge?
Find the flex points: Identify where the process can adapt for speed (like handing off reviews to your team) and where it’s non-negotiable (like security-critical changes). Document the agreed-upon approach.
5. Tools, infrastructure, & systems
Why this matters: “We’re ready to code but still waiting for access” is a surprisingly common problem. Infrastructure provisioning in enterprises often involves ticketing systems, approval chains, and processing times that could take weeks. Addressing this on day one (or even before the project starts) prevents the team from sitting idle while access requests wind through the system.
Questions to ask:
- What infrastructure and systems are already available (cloud accounts, databases, CI/CD pipelines)?
- What’s the process for provisioning new resources or access? Who approves these requests?
- Will your team manage infrastructure directly, or does it go through a central IT team?
- How long do these requests typically take? Are there known bottlenecks?
- What about deployment pipelines—are they established, or do they need to be built?
- Is there a process for requesting deployments, or can the team manage their own?
Add in buffers: Based on what you learn, add buffer time to your estimates to account for additional processing time. Identify areas where you might be able to establish more direct control to reduce ongoing friction. Start access requests as early as possible, ideally before the contract officially begins.
Building Product with Enterprise Clients
These five areas won’t eliminate every challenge you’ll face working with an enterprise client, but addressing them early dramatically reduces the surprises that derail projects. When you understand the organization’s communication paths, development culture, security requirements, review processes, and infrastructure constraints before they become blockers, you can design your approach to work with them instead of against them. As you work through these topics, you’ll develop a shared language and trust around addressing friction openly and collaboratively.
The best time to ask these questions is before the contract starts. The second-best time is in your first week. Either way, the investment in understanding how your client works pays dividends throughout the engagement.