Engineering teams tend to prioritize customer-facing features over internal tools. As a result, the state of internal tools in most companies–especially fast-growing startups–lags far behind where it would be in an ideal world.
But there's a solution: why not just let the support or ops team build their own tools? There's tons of no-code vendors out there that promise exactly this. However, unless approached correctly, this won't work.
Before diving in, I want to clarify that the primary reason these initiatives fail is not due to a skill gap–many SaaS support teams are more than capable of building good tooling. Rather, the problems are related to organizational structure and the nature of the day-to-day work of the people on these teams.
Below are a few reasons why support and ops teams are often unsuccessful in using no-code platforms to build their own internal tools, as well as situations in which this type of initiative can succeed.
Lack of write access to production systems
Internal tools for support or ops teams almost always require write access to production systems. If you want a button that can extend a user's free trial, execute a GDPR deletion request, update a user's email address, issue a refund, change their user role, etc–these all require writes to a production database.
If API endpoints corresponding to that functionality haven't already been built out, then most no-code platforms instead allow people to just run raw database queries. There are several reasons why it's inadvisable for a third-party system managed by non-engineers to run raw write queries against a database. Even if someone on support has the technical skills to write queries, they may not be as familiar with the data model as a backend engineer, and fail to realize that a certain business operation actually requires multiple queries. Running raw queries instead of relying on models might violate certain constraints and lead to unwanted side effects.
And often, database queries aren't sufficient for many operations. A "deactivate user" command might also need to generate an archive of all the user's historical app data and provide a download link–not something a simple SQL query would be able to accomplish.
Some of the most successful low-code / no-code platforms, like Zapier, work well because they focus on use cases that don't require writing to production systems. They instead focus on stitching together third-party APIs (e.g. "send a Slack message every time a new lead comes into Salesforce") where the risk of providing write access to non-developers is far lower. However, most support and operational workflows need to touch first-party production data and can't get by just via third-party API calls.
Not integrated with core development process
If you decide to give write access to a third-party no-code platform, you open up a whole new set of issues. It's difficult or impossible to integrate these tools with your company's normal deployment and testing processes. This means that everything might be working smoothly, but one day a routine data model change could cause a previously-functional tool to start having unexpected effects.
It's also tough to keep third-party no-code platforms in line with compliance-related policies and procedures. If your company has SOC 2, ISO 27001, or other similar certifications, there are a number of requirements you have to meet around how you conduct code reviews, deployment, testing, QA, etc. Many no-code platforms aren't built in a way that makes it easy to stay in line with these practices–you can configure Github to enforce that all code changes are reviewed, but can you configure your no-code platform the same way?
Lack of "maker time"
Building things–whether in code, or through no-code/low-code platforms–requires "maker time." Someone has to be able to sit down for a long stretch of time uninterrupted to make real progress. This is unfortunately at odds with the typical day-to-day of the types of teams that leverage these tools. Someone on customer support, solutions, success, or operations typically has their schedule dictated for them by customers.
In larger companies, support organizations might have people on the team dedicated to internal tools. But at a smaller company, asking someone who's already answering tickets all day to also work on internal tools is likely to fail.
This isn't an issue of skill–many SaaS support teams have strong technical skills and are perfectly capable of leveraging these platforms to build tooling. Some companies even have solutions teams who can write high-quality production code, and have career paths for people on those teams to transition to engineering and vice-versa. The issue is more that the nature of support work is interrupt-heavy.
Some companies try to get around this by creating a rotation–for example, one person on the team will be taken out of customer-facing responsibilities for a day at a time, and during that day, they can work on projects like this one. Rotations also typically don't provide enough maker time for a project as wide in scope as building internal tools. Imagine having to build a non-trivial piece of software by working a day at a time every two weeks.
When it works
When support or ops is expected to build their own tools, the reasons above are why these projects tend to fail. However, there are a few situations where it can work out:
- There are people dedicated to internal tooling: If the support team has one or more people on it whose primary responsibility for an extended period of time is internal tooling, then it can work. Many SaaS support teams have folks with good engineering skills, and if they're given the appropriate time, then a no-code or low-code platform can be an accelerant. At companies like Dropbox, the support team has headcount and budget to hire their own engineering team to work through their internal tooling roadmap.
- There's strong collaboration between eng and support: if the eng team has bandwidth to build out some of the key internal tooling API endpoints, then it's possible for a no-code or low-code platform to fill in the gaps.
- You only need read-only dashboards: if you only need dashboards that read data, a lot of the above concerns go away. Many support teams have built their own dashboards for looking up customers, seeing account metadata, reviewing billing history, etc. If the support team spends most of their time looking at account state, diagnosing issues, and answering questions, rather than executing write operations on behalf of customers, then this kind of read-only dashboard can be sufficient.
Overall, if your support team needs to be able to write production data frequently–deleting users, transferring money, fulfilling GDPR requests, importing data, changing account state–then the engineering team will have to be involved in collaborating with support or ops to build out these tools (or they'll have to own internal tooling themselves). We built Airplane with this in mind–it's aimed at developers with the goal of minimizing the time they spend on tooling and maximizing their flexibility, rather than trying to remove developers entirely from the equation.
What No-Code is good for
This article isn't meant to be an attack on low-code or no-code platforms. There are tons of legitimate use cases for them–successful companies like Bordr have been built almost entirely using these tools.
However, these platforms aren't magical, and I wanted to highlight some of their limitations in an enterprise environment. Building tools using these platforms is a lot more similar to normal software development than it is different. Removing code from the equation might bridge one gap between eng and non-eng, but it doesn't solve all the other issues that make it hard to build high-quality tools.
