Technical Discovery Phase

Technical discovery is a 1-2 week phase where a senior developer investigates technical risks before the team commits to a build estimate. It costs money and feels like overhead. It saves far more money by surfacing problems early.

What Technical Discovery Is

Technical discovery is not architecture design (though it informs it). It's investigation work where a senior developer asks: "Can we actually do what we're saying we'll do? What will be hard? What can be straightforward?"

The output isn't a 50-page specification. It's a 5-10 page document that covers:

• High-level architecture proposal
• Technology recommendations (frontend framework, backend, database, infrastructure)
• Integration analysis (which third-party systems need to work together, feasibility assessment)
• Identified technical risks and mitigation strategies
• Revised effort estimates based on what was discovered
• Implementation recommendations and decision records

What Technical Discovery Accomplishes

Surfaces show-stoppers early. A required API turns out not to support what you need. A legacy system you need to integrate with has no API and requires screen scraping. A performance requirement that seemed reasonable turns out to demand a completely different architecture. Better to learn this in week 1 than week 6.

Improves estimates. Estimates made during discovery are based on actual investigation, not assumptions. They're typically more accurate.

Identifies technology choices. Should you use PostgreSQL or MongoDB? REST or GraphQL? The senior developer researches and recommends.

Builds confidence. When a senior developer says "I've investigated this and here's how we'll do it," it's different from a guess. The team trusts the estimate more because it's informed.

Uncovers integration complexity. Most projects involve integrations. Discovery explores: Does the API exist? What does it support? What rate limits? How do we authenticate? Discovering these details early prevents surprises.

Who Should Do Technical Discovery

A senior developer or architect. Not a junior developer learning on the job. The person doing discovery needs the experience to recognize risks and propose solutions. They need to know enough about technology to ask good questions.

Discovery usually takes 1-2 weeks of senior developer time. That's $2k-$5k in cost. For a $300k project, this is negligible. For a $30k project, you might skip it. For anything above $100k, you should do it.

What Gets Investigated

Third-party integrations. "We need to integrate with Salesforce." The developer tests: Can we authenticate? What API endpoints do we need? What rate limits exist? Is the data model compatible? Do we need middleware or can we call Salesforce directly?

Legacy system integration. "We need to read data from the 20-year-old mainframe system." The developer investigates: What systems exist? Are there APIs? If not, can we use screen scraping? What's the data quality? How often does it update?

Performance requirements. "The dashboard needs to load in under 1 second for 100,000 records." The developer researches: Is this achievable with a standard database query, or do we need caching, indexing, or materialized views? What about as data grows to 1M records?

Regulatory or compliance requirements. "This needs to be HIPAA-compliant." The developer evaluates: What infrastructure do we need? How do we handle data encryption, audit logs, access control? What vendor constraints exist?

Technology feasibility. "We want real-time sync of data." The developer investigates: WebSockets? Server-sent events? Polling? Which is practical for our use case?

Common Discoveries

The legacy API doesn't support what you need. You assumed you could sync customer data from the CRM. It turns out the API only supports reading one customer at a time, and rate-limited to 10 requests/minute. Syncing 10,000 customers would take 1000 minutes (16 hours). Now you need a different approach (webhook hooks, batch export, screen scraping).

Integration is harder than expected. Integrating with a payment processor seemed straightforward. Discovery reveals: non-standard authentication, incomplete webhook documentation, test environment is separate from production, requires a separate approval process to access certain features. Timeline for integration: 2 weeks instead of 3 days.

Data model won't work. You planned to store data in MongoDB with a flexible schema. During discovery, the developer realizes that the relationships between data types are too complex for a document database. You need PostgreSQL with proper relational modeling.

Performance requirement demands caching. Your estimate assumes a standard database query. Discovery reveals: at scale, you need Redis caching and custom indexing. More complexity, more time.

Compliance requirements are more demanding than expected. You thought "encrypt data at rest" was the requirement. Discovery reveals: you need encryption at rest AND in transit, plus field-level encryption for sensitive data, plus audit logging of all access, plus the ability to purge a user's data in 24 hours. This is significantly more work.

When to Skip Technical Discovery

Simple projects with no integrations. If you're building a straightforward CRUD application with no complex integrations or performance requirements, discovery is less critical.

The team has built something very similar. If your team has built 10 similar projects, they know the technology landscape. Discovery is lower value.

The technology choices are obvious. If everyone agrees "we're using React, Node, PostgreSQL, and AWS," and those are proven for your use case, discovery is less urgent.

You're using no-code platforms. No-code platforms have known limitations. If you're using Bubble or Glide, you already know the boundaries. Technical discovery is less relevant.

The Discovery Output

A good discovery document includes:

Executive summary. One page saying: we investigated X, we recommend Y, here's the key risk.

Technology recommendations: Frontend, backend, database, infrastructure. Each with brief rationale.

Architecture diagram: Simple diagram showing how components connect.

Integration assessment: For each integration, feasibility, complexity, timeline.

Identified risks: What could go wrong? How will you mitigate?

Revised estimates: Here's what we thought before discovery. Here's what we know now.

Next steps: What needs to happen before development starts?

This is not a 200-page tome. It's 5-10 pages that inform the team and stakeholders.

Discovery and Estimation

Initial estimate (before discovery): "We think 4 months, $300k."

After discovery: "We investigated integrations and performance. The real estimate is 5 months, $350k. Here's why."

Discovery often reveals that initial estimates were optimistic. But that's good—you'd rather know the real estimate before committing than discover it mid-project.

Red Flags (When to Definitely Do Discovery)

Do technical discovery if:

• You need to integrate with multiple external systems
• You have strict performance requirements
• You have security or compliance requirements (HIPAA, PCI, etc.)
• You're building a new type of product (first SaaS product, first mobile app, etc.)
• The team hasn't built something similar before
• The project is over $200k
• You're uncertain about whether a technology choice will work

When any of these are true, the cost of discovery is trivial compared to the cost of discovering problems during development.