Six months into joining Payabli, I had already migrated us to a new documentation platform, integrated AI-powered chat, and started filling the gaps in our documentation. 24 months later, we’ve transformed from sparse, founder-run docs into hundreds of pages of content, over 200 documented API endpoints, six auto-generated SDKs, and multiple example applications.
This wasn’t about throwing bodies at the problem. For most of this journey, I worked solo. Even now, we’re just two people. The 10x improvement came from ruthless prioritization, smart tooling decisions, and building systems that scale without constant human intervention.
Here’s what actually worked.
Choose tools that let you innovate, not tools that need babysitting
The first major decision was migrating to a new documentation platform within three months of starting. The previous setup couldn’t support where we needed to go.
I wanted flexibility without being on call. At a previous job, I’d maintained self-hosted documentation, and it was miserable—I was spending time on package updates and infrastructure instead of actually improving docs. I knew I didn’t want that again, at least not until we had a much larger team.
We chose managed solutions that gave us room to innovate without the operational burden. This single decision freed up countless hours to focus on content, architecture, and automation instead of keeping the lights on.
The platform needed to support our vision and support custom components, sophisticated information architecture, and give us the ability to move fast. It delivered on all of those. The tradeoffs are some limitations on customization, but we’re also spared dealing with PagerDuty for a documentation site.
Build automation for everything you touch twice
When I found myself manually updating card components across dozens of pages (and making typos in links and titles) I knew it was time to automate. That’s when I started building our documentation CLI.
The CLI has become central to how my team operates. It eliminates entire categories of manual work and human error. It’s a living tool that we frequently add to and subtract from as our needs change.
Some examples:
Automatic component generation: All the card components in our docs are generated automatically based on frontmatter in our pages. Change a page title, and the cards that reference it update automatically. No more broken links or outdated references.
Diagram synchronization: We use sophisticated text-based diagramming, and our CLI includes automated checks that update the generated SVGs whenever the diagram source changes. We automated it so we no longer forget to update the images when the source changes.
Changelog automation: When I change our API definition, I run a command that writes the changelog entry and flags whether it’s a breaking change. This triggers the right SDK builds automatically.
These aren’t flashy features. They’re boring infrastructure that compounds over time. Every manual task you automate is time you get back for higher-leverage work, and mistakes you never make again. I want to use my brain on big problems, not little tasks.
Integrate AI where it actually helps
We integrated Inkeep early, and the chat bot has delivered an 80-100% deflection rate every month. Customers can ask questions like “build me a config for this service,” and the chat generates working configurations from our documentation.
But the real value isn’t just answering questions. I read every chat conversation and analyze how customers ask for help. This reveals gaps in our docs that I wouldn’t see otherwise. When I notice patterns, I update the documentation to address those questions proactively.
The AI chat has become a continuous feedback loop: customers ask questions, I identify documentation gaps and read customer feedback, I improve the docs, and future customers find answers faster. It’s transformed self-service for our customers and made our documentation measurably better.
Hire for potential and trajectory, not just experience
Eighteen months in, I hired Elijah, my first team member. I made a choice: I technically needed a writer to help take some of my workload, but instead I hired a junior developer who I could train to write.
I wanted someone who would grow into a developer relations role. I needed someone who could hit the ground running to build SDKs, create example applications, talk to developers, and understand their needs at a deep level. That meant I needed an extroverted developer first, writer second.
It was challenging. He was very junior, and I had to teach him about the payments industry and technical writing fundamentals. But, at the 90 day mark, he’d already shipped resources that would be difficult for a non-developer to create. The best part is that none of the resources he created required anything from other teams.
Elijah’s role here helps my team execute quickly on building enablement resources.
Treat information architecture as a competitive advantage
When I say I focused on information architecture (IA), I mean I obsess over navigation, our controlled vocabularies, content categories, URLs, keywords, and more. Prioritizing IA has been central to our ability to scale because good IA is scale.
Good IA means customers can find what they need quickly. It means new content fits logically into existing structures. It means the documentation grows in an organized way instead of becoming a sprawling mess.
This isn’t something you do once. It’s continuous work as your product evolves, as you add content, and as you learn how customers actually navigate your docs. We recently put a lot of work into reconfiguring the entire documentation site to use Fern’s new product switcher, because that feature made it easier to organize our own content by audience type.
Measure what matters, then read between the lines
Beyond the AI chat analytics, I use PostHog for product analytics on the documentation site. This shows us how people interact with different elements, which pages aren’t performing well technically (slow to load, component errors), and where people get stuck.
We track GitHub stars for our SDKs. We monitor standard web analytics for visits and engagement. But qualitative analysis like reading actual chat conversations, looking at heatmaps, or watching how people navigate, often reveals more than the numbers alone.
Metrics tell you what’s happening. Understanding why requires digging deeper.
Work with the team you have, not the team you wish you had
The biggest ongoing challenge is working with internal teams who are stretched thinner than we are. It’s hard to be proactive and reach out to teams who may not be able to prioritize reaching out to us.
This is still something we’re navigating. I’ve made looping us in on work frictionless (just add a label to a ticket and the Doc team appears). My team has adopted the QA team’s tools so we can self-service more information and test our docs. Our automation efforts helped because we could do more with less.
You can’t change how busy other teams are. You can only change how much you depend on them having spare time to help you.
Would I do anything differently?
No. I built our docs program the way Payabli needed it done, given our constraints, resources, and goals. Not every approach works in every context.
If you’re a solo documentarian or a small team trying to scale impact, here’s what mattered most for us at Payabli:
Pick your infrastructure carefully. Choose tools that let you focus on high-leverage work, not maintenance. We love our stack, and you should too.
Automate relentlessly. Every repeated manual task is technical debt. Build the tooling to eliminate it.
Hire for the gaps you can’t fill alone. Think about what skills will unlock the most value, not just what’s easiest.
Treat information architecture as ongoing work. It’s not a one-time project. It’s how you prevent your docs from collapsing under their own weight as you scale.
Build feedback loops. Use AI, analytics, and conversations to understand where your documentation is failing customers, then fix it.
We went from founder-run docs with missing pages and outdated content to hundreds of pages, 200+ documented endpoints, six SDKs, and multiple example applications. We did it with two people because we built systems that scale for Payabli.
That’s how you 10x a documentation team: not by 10x-ing headcount, but by 10x-ing leverage.
If you enjoyed these insights on how we’re leveling up our docs, why stop here?
Check out Payabli’s Developer Documentation to see it all in action — cleaner guides, smarter structure, and the little details that make a big difference for platforms and developers building with Payabli.
