Coast, a New York-based fintech company, improves the employee expense experience for small to medium businesses that own and operate their own vehicle fleets. By helping companies put fuel, fleet, and employee expenses all on one card, they make fuel theft and overspending a thing of the past.

Anton Maximov is the Head of Engineering at Coast, where he hires and manages the team, ensuring the company's engineering velocity. "As an early-stage startup, we need to keep building and shipping," he says. Since Coast is in a highly regulated industry and handles people's money, its security, resilience, availability, and compliance teams are all critical to its success—and fall under Anton's engineering management.

The value of writing things down

Coast isn't a remote-first company—the team spends four days on average in the office every week. Their belief in working together in person goes hand-in-hand with their company's value of rigor: "We treat our commitment to rigor as a competitive advantage because we know we're in an industry where we can't play fast and loose—it helps us make sure we're compliant," Anton explains.

In order to put their value of rigor into practice, the team emphasizes writing things down. "As the saying goes, I don't know what I think until I write it down," Anton says. "We value the ability to articulate what you're thinking and believe in writing as a tool to both think and communicate ideas."

Various aspects of engineering involve writing, all of which help the team operate with consistency, including decision records, design docs, and operational aspects of their jobs, like run books, postmortems, and coding guides. The team sees writing as setting the foundation for growth because it creates institutional memory that is necessary for scaling.

"We believe in writing things down—even though we're all in the office—because we're ambitious and know we will grow, and documentation will help our future team operate better."

From opaque documentation to needing a better system for knowledge sharing

While the team has always believed in written documentation, their needs for where to put it have changed as the company has scaled. The first five members of the team started using Google Docs and Google Drive, but it got out of hand because there was no cross-linking, discoverability, or easy way to create structure. "It only provided opaque documents, which are good for collaboration but not great for surfacing the body of knowledge," Anton says. As a result, engineers often complained about documentation not existing or being hard to find. In their meetings, they often struggled to find the relevant documents for discussion, which frustrated everyone.

They realized they needed a more structured wiki to create content, crosslink it, make it discoverable, and offer search so that everyone could find the information they were looking for.

Engineering their own solution and discovering the importance of search

Being engineers, the team decided to manage their documentation as code in GitHub. They adopted a static document generation tool. This fit with their engineering mindset—because they were making commits and pull requests—but there was too much of a barrier to entry to create documentation easily, and searching was difficult. Ultimately, there was too much friction to this in-house solution, and people developed unhealthy workarounds for creating and searching for documentation.

"Organizing information by putting it into buckets or having a taxonomy isn't enough for people to find and access documentation—they need to be able to search for information," Anton explains. When searching in Slab, you search not just the titles of Slab posts, but also its metadata.

"We needed a search function that would leverage metadata to give our team the information they need without reliance on how that information is organized."

Finally, while aesthetics might not seem like the most important aspect of documentation, Anton has realized over decades of documentation that writing is fundamentally part of a creative process—and it matters how documentation looks for those creating and consuming it. Coast's in-house solution provided minimal formatting, which made it difficult to read. Anton wanted an effortless solution to create content that looks good.

Making it easy to transfer Markdown documents to their new knowledge base

The team then looked into Confluence. It was surprising to them that Confluence doesn't have official support for importing markdown files. This puts them at a difficult spot where they would need to either invest additional engineering resource in building an importer, or recreate each page manually.

A friend mentioned to Anton that they were using Slab, so he decided to try it out—and that's when he saw the Markdown import feature. He used it to import all of their Markdown pages, moving the team's existing documentation into Slab over the course of a few hours. "With Slab I was able to transport my hierarchy of documents in Markdown, and the structure was already 95% of the way there — it was so easy," he says.

Slab's Markdown import feature and seamless SSO integration with Google Workspace enabled a fast onboarding experience for Anton and his team. "There was just so little friction, it was polished, and it imported all the things we needed," Anton says. "I was happy to pay for Slab because it saved me two days of engineering time simply trying to convert our documentation—that's about $2,000."

Creating an established place for documentation

Coast's engineering team uses Slab to document information and decisions for future reference. For example, when big architecture or vendor decisions are made, a Slab post gets written, then pushed on Slack, via email, and in meetings. For postmortems, such as following an outage, the team holds a meeting, documents their learnings in a Slab post, and circulates it with the rest of the organization.

Slab also houses the team's run books for how to do deployments, including documentation around setting up and configuring things. It's where they document all of their release notes, which are written multiple times per week to accompany each release. "I want to be in a place where it's in the DNA of our company that anything we build, we have documentation around it," Anton says. "Slab gives us a place to put that documentation." As the team grows, every new person can access documentation to understand decisions that were made or how to run processes at Coast.

The value of virality and how simplicity drives it

Once Coast Engineers started using Slab, the tool went viral because documentation was shared with non-engineers, who would log in to Slab and start using it to create content, too. Because Slab makes creating, editing, and searching for content simple, other teams expanded their use of it.

"By addressing most of its use cases with simple formatting and editing options, Slab removes the cognitive load associated with formatting things in a certain way. That minimalism allows us to move really fast because all we care about is our content and sharing our thoughts."

For example, one way Slab makes things simple is by including the topic name and post title in its URLs, so you can see what the link you're clicking is about. It also keeps white spaces compact and makes writing and shortcuts quick and simple. "Slab's simplicity drives its virality at Coast, removing the barrier to creating documentation," says Anton.

Providing a better developer experience

Since adopting Slab, Anton has noticed much less frustration in his team about documenting knowledge. He has seen improved scores on questions about engineering frustrations on the team's qualitative developer experience survey, a good indicator of the team's mental health.

Slab helps Anton deliver a better developer experience overall because meeting notes, postmortems, and technical documentation are written down and easy to find, and it's easy for others to create similar documentation.

In a competitive market for engineers, tools that improve the developer experience are critical to the retention, productivity, and overall wellness of engineers and the org. By giving developers a thinking tool—Slab—they become more engaged and productive and can focus their attention on delivering rigorous, high-quality products instead of searching for documentation.

Maintaining a curated, evergreen body of knowledge

"I want documentation to be an experience that's natural to the organization, as opposed to being the one cracking the whip and asking people to write things down," Anton explains. He believes this differentiation is critical to the long-term success of Coast. By making documentation a more joyous, lightweight experience, Anton helps his team think and, perhaps more importantly, communicate, their ideas.

What's more, using Slab also helps preserve institutional memory for the growing company—providing context, processes, and other critical information for new members of the scaling team. "Having a curated, evergreen body of knowledge is important, and Slab allows me to maintain that with little effort," Anton says.