FAQ

General Questions

Why did you transition from development to technical writing?

After 15+ years of building systems, I discovered I loved the challenge of explaining complex technical concepts more than building the systems themselves.

The turning point was realizing that excellent documentation has massive leverage—one well-written guide helps thousands of developers, versus code that serves one specific use case.

Plus: Documentation engineering lets me use both skill sets—I still build (docs infrastructure, CI/CD, tooling) and write.

What makes you different from other technical writers?

Most technical writers: Understand documentation conventions, can interview engineers, write clearly.

Me: All of the above, plus:

• I can read your codebase and understand it without extensive hand-holding
• I can build and maintain the entire docs infrastructure (not just write content)
• I can debug your CI/CD pipeline when docs deployment breaks
• I've worked directly with cryptographers, protocol engineers, and senior architects
• I understand business context, not just technical accuracy

In practice: I move faster, ask better questions, and deliver more than just words on a page.

Can you work with [specific technology]?

If it's in my wheelhouse (Web3, SaaS, APIs, developer tools): Yes, immediately effective.

If it's adjacent (new programming language, similar domain): Yes, 1-2 weeks to get fluent.

If it's completely new: Probably yes, but expect 2-4 weeks ramp-up while I build domain context.

Honest assessment: I learn fast, especially for technically complex domains. But I won't pretend instant expertise in areas I don't know.

Work Arrangements

Are you available for full-time/permanent roles?

Yes, but with preferences:

First choice: Remote contract work (high day rate, contained scope, flexibility)

Also open to:

• Permanent roles if the fit is exceptional
• Part-time permanent (20-30 hours/week)
• Long-term contracts (6+ months)

Not interested in:

• On-site requirements (unless occasional)
• Middle East or low-cost labor markets
• Agencies that want to resell my services

What's your rate?

For contracts: Let's discuss scope first. My rate depends on:

• Project complexity
• Timeline/urgency
• Contract length
• Technical domain

For permanent roles: Competitive salary expectations based on experience and location.

→ Email me to discuss your specific situation

What's your availability?

Current status: Available immediately for new projects

Work hours: Flexible, UK/European timezones preferred but can accommodate US East Coast

Capacity:

• Full-time contract: 1 client
• Part-time contracts: 2-3 clients simultaneously
• Permanent: Full focus on one company

Do you work with startups or only established companies?

Both. Each has advantages:

Startups (< 50 people):

• ✅ High impact, shape documentation from scratch
• ✅ My versatility (DevOps, infrastructure, writing) = huge value
• ✅ Fast-moving, less process overhead
• ⚠️ Need to be comfortable with ambiguity

Established companies:

• ✅ Resources and process in place
• ✅ Prestige and brand recognition
• ✅ Clear scope and objectives
• ⚠️ May move slower due to process

Sweet spot: Series A-C companies with product-market fit, needing to scale documentation.

Technical Questions

What documentation tools do you use?

Primary platforms:

• Docusaurus (most projects)
• Nextra (Next.js-based, like this site)
• GitBook (collaborative environments)

Can work with: Pretty much anything. Tools are means to an end.

Philosophy: I recommend what fits your needs, not what I prefer. Sometimes that's custom-built.

Can you build documentation infrastructure, not just write?

Yes. This is a key differentiator.

I can:

• Set up Docusaurus/Nextra/GitBook from scratch
• Build custom documentation sites (React/Next.js)
• Configure CI/CD for automated deployments
• Implement docs-as-code workflows
• Set up linting, validation, and quality checks
• Integrate search (Algolia, custom)
• Configure analytics and feedback systems

Example: At Starknet, I didn't just write docs—I built the entire documentation infrastructure and deployment pipeline.

Do you do API documentation?

Yes. API docs are a specialty.

Can document:

• REST APIs
• GraphQL APIs
• WebSocket/real-time APIs
• RPC APIs (like StarkNet's JSON-RPC)
• SDK/library documentation
• Smart contract ABIs

Approach:

• Work from OpenAPI/Swagger specs when available
• Read the code directly when specs don't exist
• Test all endpoints myself before documenting
• Write clear examples that actually work

Can you handle highly technical content?

Yes. This is where my development background shines.

Examples of technical depth I've handled:

• Zero-knowledge proof systems (zkSTARKs)
• Smart contract security patterns
• Cryptographic primitives
• Distributed systems architecture
• Payment system integration
• Complex API authentication flows

How I do it:

• Read the code myself
• Test the actual implementation
• Work directly with engineers without needing translation layers
• Ask intelligent questions that uncover gaps

Process Questions

What's your typical process?

How do you handle subject matter experts who are too busy?

Reality: Engineers are always busy. I don't expect them to write docs for me.

My approach:

1. Do my homework first - Read the code, test the product, understand the basics
2. Ask specific questions - Not "explain this to me" but "I think X works like Y, is that correct?"
3. Use their time efficiently - 30-minute focused sessions > 2-hour rambling meetings
4. Show work in progress - Give them something to react to rather than starting from blank page
5. Build trust - Demonstrate I understand the technology, earn their engagement

How do you measure documentation success?

Quantitative metrics:

• Docs page views and engagement
• Time to first success (developers shipping quickly)
• Support ticket reduction
• Search analytics (what people look for)
• Feedback scores

Qualitative signals:

• Developer testimonials
• Community engagement
• Reduced engineering interruptions
• Sales using docs as asset

Philosophy: Good documentation helps developers succeed. If they're succeeding, docs are working.

Logistics

Where are you based?

Location: UK-based (legal/tax purposes) Work style: Fully remote

Timezone flexibility:

• UK/European hours (primary)
• Can accommodate US East Coast
• Async communication works great

What's your notice period?

For contracts: Typically 2-4 weeks, negotiable based on urgency

For permanent roles: Standard notice periods apply

Current status: Available to start immediately for the right project

Do you sign NDAs?

Yes. Happy to sign reasonable NDAs to protect confidential information.

Won't sign: Non-compete agreements that prevent me from working in entire industries.

Still Have Questions?

Questions I Ask You

Before we work together, I'll want to understand:

1. What's the technical complexity? (helps me assess fit and timeline)
2. Who's the audience? (developers? different skill levels?)
3. What's the current state? (greenfield? existing docs that need improvement?)
4. What does success look like? (metrics, goals, timeline)
5. How does the team work? (remote? async? meeting culture?)

Why these questions matter: Good documentation requires context. I want to understand your needs so I can deliver real value, not just words on pages.