IN FOCUS
FOUNDER FILE · Taylor SloaneHELPDOCS · Building since 2016THE WORK · Code, customers & a carefully measured coffee

People / Founders / Taylor Sloane

Taylor Sloane and the art of closing the chat window

The HelpDocs co-founder likes getting the details right, down to the dissolved solids in a cup of coffee. Building a software company has also taught them when to stop, listen, and change the recipe.

Advertisement

Taylor Sloane was trying to build a feature in a hotel lobby when the messages kept arriving. Answer one, return to the work, answer another. The company sold software that helped people find answers for themselves. Its co-founder was having trouble finding an uninterrupted stretch of time. Eventually, Taylor did something that sounds perilous for someone running a customer-support business: they switched off live chat.

Customers could still ask for help. They would use a contact form, with suggested articles along the way, and receive an email reply. Taylor expected complaints. The complaints failed to appear. Resolution times, they reported in January 2020, remained much the same, sometimes improving. The little chat window had been making a rather large demand.

That decision is a useful way into Taylor's story. The HelpDocs co-founder and CEO likes making things work. Over time, that has also meant reconsidering things that appeared to be working perfectly.

The coffee has a specification

Start with the coffee. In 2016, Taylor described buying beans only from sellers who could identify the farmer. Water temperature, brewing method and the proportion of coffee to water all received attention. So did total dissolved solids. Most people ordering a flat white are hoping to avoid a laboratory practical.

Taylor offered this as an example of how thoroughly they could get into something. Software development, customer support and sales could all absorb them. The detail matters because it makes the later business decisions less mysterious. Here is someone drawn to adjustments, to the small difference between a thing that functions and a thing that feels right.

HelpDocs gave that inclination somewhere to go. A searchable help page may look unassuming. To someone who cares about how software behaves, it contains plenty to argue with.

A small idea, allowed out of hiding

Earlier in their career, Taylor had tried keeping a startup secret. They later blamed that secrecy for helping starve it of attention and customers. The experience changed how they thought about ideas. A notebook full of them was less useful than a conversation with someone who might need one.

There is a pleasing tension here. Taylor could worry about whether the product was good enough while also recognising the danger of keeping it to themselves. The work needed privacy sometimes; the business needed an audience. Those requirements could pull in opposite directions.

HelpDocs emerged from frustration with support at another startup. Taylor and their co-founder wanted a standalone knowledge base that was straightforward to maintain and customise. Taylor initially doubted whether that modest proposition could support a whole company.

By October 2016, the experiment had paying customers. Taylor described building the first version in roughly two weeks and acquiring two customers through an advertising campaign costing less than $100. Encouraging friends had helped with feedback. Strangers willing to pay provided a different sort of encouragement.

The early HelpDocs dashboard, showing a list of help articles and categories
From the workbench / 2016 Before the polish, a place to put the answers. Taylor's early HelpDocs dashboard.

The engineer answers the ticket

Taylor's preferred work was product development. In an early account of running HelpDocs, they described the temptation to hand other responsibilities to someone else once revenue made that possible. Support, though, kept the engineer close to the consequences of their decisions.

They could fix a bug while talking to the person who had reported it. They could write the precise styling code a customer needed. That shortened the distance between the person encountering a problem and the person able to change the software.

It also complicated the usual picture of technical work. A support conversation might look like an interruption to development. Taylor's account suggests it could be part of development: the point where an assumption met an actual person, complete with a browser, a deadline and a reasonable expectation that the button should work.

In April 2017, Taylor described HelpDocs operating from a shed in the UK with a team of two. When a provider problem blocked signups, the team contacted affected users within minutes. They also offered custom templates, despite the possibility that the service cost more time than it earned.

The accompanying advice was wonderfully practical. Give a clear answer about feature requests. A definite refusal could be more useful than a cheerful promise that would never produce anything. Courtesy, in this telling, included telling someone where they stood.

Customers redraw the boundary

Listening had consequences for the product itself. Taylor initially resisted adding internal documentation. HelpDocs was for customer-facing answers; other tools already handled information inside a company. Customers kept asking anyway. Some had begun adapting the product for that purpose themselves.

In January 2017, internal docs arrived, with private drafts, sharing and permissions. The interesting part is Taylor's willingness to describe their original reluctance. Users had demonstrated a need that the founder's initial definition of the product did not quite accommodate.

A month later, Taylor introduced multilingual documentation. Requests had been frequent, but they said trying the existing alternatives helped them understand the difficulty. The result let teams work from a master language, add translations and track what remained unfinished. Paying attention had become a sequence of interface decisions.

One acquisition. One product.

In July 2017, HelpDocs bought Helpman, a competing knowledge-base service. Taylor had spoken with its founder and noticed how closely the two roadmaps resembled each other. Both businesses were spending effort on similar problems.

The decision came with a limit. Helpman's customers would migrate to HelpDocs. The small team would concentrate on one product rather than maintain two. Taylor's announcement was occupied with the practicalities of moving customer data and changing DNS settings, the plumbing through which an acquisition becomes real.

Pricing required another boundary. In August, Taylor explained why HelpDocs was resisting freemium. Their calculations suggested they would need 110 freemium users to generate the revenue of one existing customer. Supporting those extra people would create work the bootstrapped team could not afford.

That was a calculation about this particular business. Taylor also acknowledged that competitors could suit certain customers better, and described recommending them when appropriate. A business could have a price, a purpose and a limit to whom it should sell.

“Pricing's really hard”

Taylor Sloane, 2017

The month that became six

Technical judgement remained harder to contain. As larger customers arrived, HelpDocs' original Angular frontend struggled. Taylor chose React for a replacement and expected the rewrite to take around a month. It took six.

The costly choice was attempting the replacement all at once. While the new version remained unfinished, customers used the old one. Fixes and features could require work in both. Taylor's subsequent recommendation was to change parts gradually, leaving room to adjust while the business continued operating.

This is where the coffee enthusiast encounters a less cooperative material. A cup can be remade. A live software product has customers using it while its maker is trying to improve it. Their needs continue arriving throughout the renovation.

By July 2018, Taylor was explaining another substantial piece of engineering: a rebuilt text editor. The aim was predictable behaviour across browsers and more control over how changes affected content. The technical effort mattered because writers should be able to press a key without wondering what it might destroy.

A dislike of lessons that turn into adverts

Taylor brought a similar concern about expectations to writing. They objected to promotional material presented as education. There was room for a sales pitch, they argued, provided readers understood what they were getting.

The argument also became personal. Taylor described growing up with educational advantages in the UK and completing a master's degree in electrical engineering. They believed access to education should be more widely available. Their impatience with self-congratulatory business writing had something more substantial behind it than a preference for brisk prose.

The humour remained. Taylor could interrupt a complaint about marketing with a deliberate plug for HelpDocs. The joke worked because the transaction was visible. Readers were allowed to notice the salesperson in the room.

Permission to leave the desk

The later decision to close live chat belongs beside another view Taylor shared in 2024: a team should be judged by the quality of delivered work. With unlimited time off, they said, the challenge could be persuading people to take it. Managers needed to set an example by doing so themselves.

That position puts a useful responsibility on the founder. A written policy is only part of the arrangement. People also watch what their manager does. A company that permits time away has to make leaving the desk feel ordinary.

Taylor is based in Lisbon, and their public biography describes travel in search of hotels, coffee and vegan food. There is room in the picture for a person who enjoys the places remote work makes possible, alongside the person who likes disappearing into code.

An editor that leaves the writer in charge

In 2026, Taylor shared HelpDocs' Improve with AI feature. It reviews an article and offers feedback that the writer can assess. Taylor mentioned that the team had tried it on their own explanation of the feature. The result was a score of 72. Selling an editorial tool evidently does not secure immunity from its opinions.

River Sloane, Taylor's co-founder, described the design goal as specific, visible suggestions with the writer retaining control. The connection to the earlier work is easy to see: make the next action understandable, and let the person using the software decide what to do.

Taylor's career at HelpDocs contains plenty of building. Its more revealing moments involve revising a decision: letting an idea out, making room for internal docs, changing how a rewrite happens, closing a chat window. The person measuring dissolved solids in coffee has had to leave room for evidence that changes the recipe.

Keep reading, keep watching