Case Studies
Featured Projects
Starknet Foundation (2022-2023)
Sole Owner: Ethereum Layer 2 Documentation
Challenge: Document a bleeding-edge zero-knowledge proof system during mainnet launch with limited precedent and extreme technical complexity.
The Situation
- Company: Starknet Foundation (Ethereum Layer 2 scaling solution)
- Role: Technical Writer (sole documentation owner)
- Timeline: 12 months leading up to mainnet launch
- Scope: All developer-facing documentation
Technical Complexity
What I had to understand and explain:
- STARK proof systems (zero-knowledge cryptography)
- Cairo programming language (new, minimal existing docs)
- Validity rollups vs. other Layer 2 approaches
- Account abstraction
- State compression and data availability
- Cairo VM architecture
The challenge: Most of this technology had no comparable documentation to reference. I was working directly with cryptographers and protocol engineers to understand bleeding-edge research and translate it for developers.
What I Built
Complete documentation suite:
- Getting Started guides - Onboarding developers from zero to deployed smart contract
- Cairo language documentation - Syntax, patterns, best practices
- Architecture guides - How Starknet works under the hood
- API reference - Complete RPC API documentation
- Smart contract patterns - Security, optimization, common patterns
- Integration guides - Wallets, indexers, development tools
- Migration guides - Helping projects move from Ethereum
Cross-functional Collaboration
Daily interaction with:
- Cryptographers (explaining zkSTARK primitives)
- Core protocol engineers (Cairo VM, sequencer)
- DevRel team (developer pain points)
- Marketing (messaging, launch coordination)
My unique contribution: I could hold technical conversations with cryptographers without needing everything pre-digested. This meant I could move fast and ask better questions.
Infrastructure Built
- Docusaurus-based documentation site
- CI/CD pipeline for automated deployments
- Contribution guidelines for open-source contributors
- Documentation review process
- Analytics and feedback systems
Impact
Results:
- Launched comprehensive docs aligned with mainnet release
- Enabled hundreds of developers to build on Starknet
- Reduced support burden through self-service documentation
- Established documentation standards still in use today
What I Learned
- Ambiguity is normal in cutting-edge tech - You have to be comfortable documenting things that are still being finalized
- Ask better questions - Understanding the "why" behind technical decisions makes for better docs
- Speed matters - In fast-moving environments, good documentation shipped today beats perfect documentation next month
- Developer empathy - Testing your own docs by building sample apps reveals gaps
Success Patterns
What makes these projects successful:
- Technical depth - I can understand complex systems without extensive hand-holding
- Fast execution - Ship good documentation quickly, iterate based on feedback
- Infrastructure thinking - Build systems that scale beyond just writing content
- Cross-functional collaboration - Work effectively with engineering, product, and business teams
- Developer empathy - Test my own documentation by building with the product
Anti-patterns I Avoid
What doesn't work:
- ❌ Waiting for perfect information before shipping
- ❌ Documentation that's technically accurate but unusable
- ❌ Siloed documentation that doesn't integrate with product
- ❌ Ignoring developer feedback
- ❌ Building docs in isolation from engineering teams