How I Work
After 15+ years building newsroom tools under deadline pressure, I've developed strong opinions about what works.
Principles
Prototypes over presentations
I don't make slide decks about what I'm going to build. I build something small and real within the first week. You can click it, break it, react to it.
Editorial intent first
Before any code: what's the story? What should the reader feel? What action should they take? The visualization serves the journalism, not the other way around.
Stress-test before launch
If it's going live on election night, we simulate election night. Load testing, failure scenarios, fallback plans. The boring stuff that prevents disasters.
Documentation as delivery
You get working code, not a dependency on me. Every project includes documentation your team can actually use after I'm gone.
What I Don't Do
Questions I'll Ask You
Before we write any code, we need clear answers to these:
- 1. What happens if this visualization is wrong?
- 2. Who's the least technical person who needs to understand this?
- 3. What's the one thing this absolutely must communicate?
- 4. How does this hold up when the data is ugly or incomplete?
- 5. What does success look like in six months, not just at launch?
Typical Timeline
Timelines compress or expand based on scope. Election night systems need more stress testing. Investigative pieces need more data wrangling. We figure this out in the discovery call.
If this resonates, let's talk. If it doesn't, we're probably not a fit—and that's fine.