Technical Research

Overview

Systematic technical research for staff-level software engineering decisions. Gather evidence, synthesize findings, and present actionable recommendations.

Research Workflow

1. Scope the Question

Before searching, clarify:

• •What decision does this research inform?
• •What constraints exist (language, framework, team expertise)?
• •What "good enough" looks like—avoid rabbit holes

2. Gather Evidence

Use multiple sources in parallel:

Web search — current state, recent changes, community sentiment

WebSearch: "[topic] 2026" or "[library] vs [alternative]"

Documentation — authoritative specs and APIs

Context7: resolve-library-id then query-docs
WebFetch: official docs, RFCs, specifications

Codebase — existing patterns and constraints

Grep/Glob: how similar problems are solved today

3. Evaluate Sources

Weight sources by reliability:

1. •Official documentation, specs, RFCs
2. •Maintainer statements, changelogs, release notes
3. •Reputable tech blogs, conference talks
4. •Community discussions (HN, Reddit, Discord)
5. •AI-generated content, outdated tutorials

Red flags: No date, no author, SEO-heavy content, contradicts official docs

4. Synthesize Findings

Structure output for decision-making:

## Summary
[1-2 sentence answer to the core question]

## Key Findings
- Finding 1 (source)
- Finding 2 (source)
- Finding 3 (source)

## Comparison (if applicable)
| Criterion | Option A | Option B |
|-----------|----------|----------|
| [Key factor] | ... | ... |

## Recommendation
[Clear recommendation with rationale]

## Open Questions
[What remains uncertain, what to monitor]

5. Cite Sources

Always include sources:

Sources:
- [Official Docs](url)
- [Relevant Article](url)

Research Patterns

Library/Framework Evaluation

Investigate:

1. •Maintenance — Last release, commit frequency, issue response time
2. •Adoption — npm downloads, GitHub stars, production users
3. •Documentation — Quality, examples, migration guides
4. •Bundle size — For frontend, check bundlephobia
5. •TypeScript — Native support or @types package quality
6. •Breaking changes — Major version history, upgrade difficulty

API/Service Comparison

Investigate:

1. •Pricing — Free tier limits, scaling costs
2. •Rate limits — Requests/second, daily quotas
3. •Latency — P50/P99, geographic distribution
4. •Reliability — SLA, status page history
5. •Auth — OAuth, API keys, complexity
6. •SDK quality — Official vs community, maintenance

Architectural Decisions

Investigate:

1. •Prior art — How do similar systems solve this?
2. •Trade-offs — What does each approach sacrifice?
3. •Reversibility — How hard to change later?
4. •Team fit — Existing expertise, learning curve
5. •Operational cost — Monitoring, debugging, scaling

Tool Usage

Parallel searches — Launch multiple WebSearch calls for different angles simultaneously

Context7 for libraries — Always resolve-library-id first, then query-docs for specific questions

WebFetch for docs — Fetch official documentation pages directly when you need authoritative details

Codebase search — Check how the codebase already handles similar problems before recommending external solutions

Output Quality

Research output should:

• •Answer the original question directly
• •Provide evidence, not assertions
• •Acknowledge uncertainty explicitly
• •Include actionable next steps
• •Cite all sources

Reference Material

For detailed research patterns and techniques, see:

• •references/patterns.md — Common research scenarios with examples