Saying No to Custom Code: Our Journey Creating Support Scope

As a technical founder it's easy to fall into code and spend time coming up with solutions to problems. But sometimes those problems aren't yours to fix. When that's the case you have to draw and line and work out what you're willing to spend your time on and what you're not.

Jake and I learned this the hard way. When we first started HelpDocs we'd always be working on creating custom templates, JavaScript, and CSS for customers. At the time it made a lotta sense. We needed to grow revenue and show the power of our platform.

But as we grew we knew this wouldn't scale. Creating code that works 99% of the time is tough and takes a lot of tweaking. Something as simple as appending an element to another can take 30 minutes. Even for an experienced developer.

Alice in Coderland

When we started creating HelpDocs we wanted it to be a plug and play platform. You'd enter your slug and we'd take care of the rest. A lot of that mentality is in the platform. The majority of customers don't add any code and are pretty happy with the templates outta the box.

But when we started to get feedback from customers early on they wanted a way to tweak their templates. A different color for links, or a different font for articles. They wanted to match their brand.

So we decided to introduce custom CSS and JavaScript. And people loved it. It was fantastic to see customers make their knowledge bases their own. And that's when the rabbit hole swallowed us up.

To make sure everyone was having the best experience with HelpDocs we started spending more time creating custom code. 5 lines turned into 50 and 50 lines turned into 500. We knew this wouldn't scale but we couldn't say no. In hindsight we didn't want to say no.

And then we introduced custom templates. The problems ballooned 🎈

Instead of creating smallish snippets for customers we were creating whole templates for nothing. I can't decide whether it helped or hindered our growth but I know for sure it made for a lotta hours in front of the screen.

And it was our own doing. We set the worst expectations—none at all. We'd get requests back for tweaks and we'd drop everything and work on that for hours at a time.

Don't get me wrong. These tweaks made us create features and templates we'd never even planned. But no doubt we were sinking time.

After 6 months being too helpful we knew it was exhausting and the situation was unsustainable.

Learning to Say No

As the platform started to grow we had little choice but to start saying no to custom code. We had to concentrate on creating features our whole user base could use rather than one.

We pulled back and started managing expectations by rejecting revisions.

"I'm happy to do it this one time" became the norm and to our surprise people took it well. Instead of getting angry our customers generally respected our boundaries. And they were thankful for the help.

Like every other company our time became even more limited as we grew. Even doing one revision became too much for two people. Our customer base was shifting from humble startups to large corporations who demanded more of our time.

We wanted to please everyone but we had to make a decision—where should we draw the line now?

We took a leap and decided we'd push companies to use their own resources to create custom code. As much as we loved helping create unique knowledge base templates it took too long.

It was painful to tell the first customer their own developers would need to help them out. But I'm so glad we did.

Making It Official

For years we carried on telling customers we couldn't help them with their custom code. We added it to our Custom CSS and JavaScript knowledge base articles.

The requests kept (and still do) coming in and we kept replying with the same answer. "This is something your developers will need to work on".

But no matter how hard we tried the boundary still seemed murky. Sometimes we'd help with little snippets and sometimes we wouldn't. If it seemed like a small job we'd tweak a little and end up spending hours trying to fix a problem that wasn't ours to fix.

We wanted our customers to be happy but we were making ourselves miserable in the process.

That's when we decided to make it official. We needed to create a support scope article. Something that'd make it clear what we could do and what we couldn't.

Creating Support Scope

There aren't many resources out there on how exactly you create a support scope article. Hosting companies usually fit into three buckets:

1. Don't make it clear until after you've got in touch (like we did)
2. Make it very clear upfront in a kinda rude way
3. Let their communities answer questions for them

We wanted to create a clear but friendly article customers could refer to. It needed a list of Dos and Don'ts. We didn't want a community we needed to moderate with such a small team.

To start with we looked around some of our favorite hosting companies that allow for extensive customization. Webflow and DigitalOcean have great examples of making things clear.

We created a list of the different areas of the product and got organized:

• The dashboard/admin app
• Knowledge base hosting
• Native integrations
• API

We knew these were the things we were responsible for. Making sure people can manage and view their content is the main thing we offer. Basically if we built it we needed to support it.

Then we went through areas of the product that weren't ours but could be support worthy:

• Custom domains
• Single sign on
• Organization and structure of a knowledge base
• SEO optimization
• Third-party integrations
• Custom CSS, JavaScript, HTML templates

This was a little trickier. We were again in murky waters. Should we help optimize their knowledge base? Isn't that the thing we were hoping to avoid?

We decided to help troubleshoot issues. Features like custom domains and single sign on aren't our responsibility but they do make the product much more seamless. They take a lot less time to work out too.

For knowledge base organization and SEO optimization we decided this was an education problem. We'd rather focus our time on pushing out resources everyone could learn from than help customers one-on-one.

HelpDocs Support Scope

Here’s what the HelpDocs team can help you with ✨🦄

supportJarratt Isted

And as for third party integrations and custom code. Well we made a stand not to help with those. That would cut down time spent going down rabbit holes 🐰

An Ongoing Struggle

I'd love to say we say no to custom code 100% of the time but that's not true. I'd say it's at about 95%.

We still take tickets about code issues on a case-by-case basis. What I do know for sure is our support scope article has helped us a lot. We now have a place to refer customers where the expectations are clear. But the waters are still murky for sure.

Sometimes we limit the amount of time so we know roughly how we'd approach the problem but avoid spending hours on a solution.

As corny as it sounds I also know that helping out customers as much as we can is in our DNA as a company. It's sometimes not as simple as a yes or no.

We're slowly creating more resources for customers to help themselves. After all that's what we're all about. Our article about finding CSS selectors is our most popular ever and our guide on how to clear your browser cache is our second.

So I think the answer is creating more resources everyone can learn from.

Let's just say we're working on it!