According to the State of Internal Tools 2022, respondent developers spend around a third of their time building internal software. Previously, there was only one real option if you weren’t looking to buy a pre-made SaaS product: code from scratch. Now, with the advent of low-code platforms or advanced developer tools, there is a spectrum of ways to create internal apps. Don’t be overwhelmed, however - this should make the choice even easier. In this article, we’ll break these options down for you, including examples of software, and the pros and cons of using each.
When should you custom-build your internal tools?
Before we break down the three different types of internal tool development, let's talk about whether custom development is needed at all.
Here is a summary of when we think it’s best to build:
- You have outgrown your SaaS products’ functionality, or you know you will quickly outgrow them.
- You have tested an MVP, and you know the tool will bring value to your company.
- If you have a technical team or at least some technical know-how and this tool is a priority, a custom tool will be a good investment for the long term.
- This tool may become a part of your core product, and you want to maintain IP.
- You need more agency and control over your code and product, and over your product cost.
We cover Build vs Buy, as well as the pros and cons of each in more detail in our Build vs. Buy 101 guide!
Deciding how to build your internal tool
There are currently three main options for building your internal tools: custom coding (the traditional way), low/no-code apps, and developer tools. Let’s dig into these in more detail.
Traditional Custom Code
Traditional coding is the most complex of the building types out there. You will need an experienced engineer, and usually a bucketload of time and money to get your tool to the finish line. Nevertheless, the pro here (and it’s a big pro) is complete customization, agency and portability over your tool. This is the option where it’s possible to get exactly what you need - if you can code it. Your options for building might include using ReactJS, Python, JavaScript, and other programming languages.
Pros of traditional custom coding:
- Full and total customization. You hold all the keys and the possibilities are near endless.
- Complete agency and control over the cost of your product. You aren’t at the mercy of another company’s monthly subscription costs (but you are at the mercy of your own computing costs!).
- Reduced dependencies. You don’t have to worry about your internal tool provider going down or breaking out of your control. You’re the only one in charge.
- No lock-in. You have total ownership and access to your code, which remains completely portable into whichever system you are using.
- Reduced monthly cost. Once your app is built, you will only need to pay for occasional maintenance and updates, which, if you are using a tool for the long term and have engineers in-house, can turn out cheaper than a SaaS model.
Cons of traditional custom coding:
- High setup cost - needs heavy engineering time. The biggest con of traditional development is that you need an engineer who can make it for you, and they are often expensive. It’s important to consider the cost of their hours in the build, even if they are internal engineers.
- Time. It takes much, much (much) longer to develop an app from scratch using traditional code than any of the other methods we mention in this article - and this is not an insignificant consideration. If it takes 6 months to build from scratch, and many hours of core engineering time, you should be looking at using this app for the foreseeable future, at least several years, and not to soon deprecate it. This limits the amount of apps you might want to build.
- Maintenance. You will need someone to fully maintain the app for as long as it’s in use. If the app is in use for an extended period you run the risk of the language it’s written in becoming outdated, or losing a developer who is familiar with the application.
- Scale. If your company grows fast and needs change, you will need to scale the app yourself, which may include complex maintenance and provisioning.
When do we recommend traditional custom code?
We think it’s a good idea to custom code if your app or tool is mission-critical to your operations and needs a high level of portability. Nevertheless, this might only equate to the top 5% or less of your apps. There are plenty of other suitable solutions for building the remaining 95%, which are likely to use less time and money. Let’s dig into those other options!
Low/no-code platforms
On the other side of the custom-build spectrum would be ‘no-code’ and ‘low-code’ platforms. No-code options are typically targeted to non-technical people, and low-code is usually tailored towards those with a little technical knowledge or some limited coding skills, what we call ‘citizen developers’. The former might include simple automation systems like Zapier, Make, and Notion, and the latter would be things like Webflow, Outsystems, and Bubble, which do focus on enabling non-technical users but often require a steep learning curve to use them.
Options for low/no-code platforms: Make, Bubble, Notion, Zapier and Airtable
Pros of low/no-code platforms:
- Don’t need a technical background to start. This is a great perk for using these kinds of platforms. You don’t necessarily need to wait for an engineer to be free - your non-technical operations team could spend their time learning a platform’s (often intuitive) visual language themselves, without needing to go through a pitching and scoping process to get it made.
- The development process can be more intuitive. Unlike custom coding, apps built on such platforms are often straightforward for anyone with some technical knowledge to help build or debug, not just the builder or another developer.
- Low set-up costs. If you don’t need a developer to do it, nor to contract it out to a technical person, you can quickly create a cheap app in-house that might serve your needs. Nevertheless, beware that skimping on critical infrastructure, even at the beginning, can lead to bigger bills later on. It’s best to keep non-critical elements of your business tools on such apps.
- Quick-ish to build. If you are just looking for an MVP, very basic automation connecting apps like GSheets and your email, or a very basic CRUD, it will often be quick and cheap to put together on a low-code platform. Keep in mind, the more complex your application, the longer it may take to learn the low-code platform in order to build what you’re looking for (and sometimes it might not be feasible at all).
Cons of low/no-code platforms:
- Limited customization. With almost every platform that abstracts code, you’ll eventually hit a wall. These kinds of tools can be useful for simple CRUD apps or BI reporting, but if these apps will need additional, more complex features, you are likely to quickly run out of customization options. Styling is often limited and, since they often market to non-technical users, it’s not usually possible to build on top of it using code.
- Low buy-on from actual developers. Since these products are generally marketed towards non-technical audiences, developers often become frustrated at the platforms’ limitations and the inability to use their own code. This means that if you start your MVP on such a platform, your engineers may be unlikely to want to scale the app in the same place.
- Proprietary languages to learn. You will usually need to learn their own languages and structures for building. With some platforms the learning curve can be steep even for a developer due to the unique layout of their system and proprietary approach to the abstraction of code.
- Can be unreliable and hard to debug. Since you are reliant on another company’s platform, you are often subject to their downtime and bugs, with little control for fixing them, something to avoid for critical operations!
- Hard to scale. While these platforms may help in getting things up and running, there is a reason why enterprise companies don’t build their tech stack on a low-code database. As systems become more complex, having complete ownership and having things built for scale become more important.
- They can get expensive in the long-term. Such platforms are often based on a subscription model to access your app or data. While this may be cheaper than a developer, if you are only going to use a platform for one, or even just 2 or 3 apps, the subscription fee may not be worth it, especially if you are SME.
- Security varies between products. As your company scales, the need for security protocol grows alongside it. When using a low-code to no-code tool, you are limited to the security abilities of the low-code platform. You generally won’t be able to manage permissioning through your company’s protocol, and will have to manage through the low-code/no-code tools permissioning suite.
When do we recommend low-code/no-code tools?
We recommend no-/low-code when the emphasis is on enabling a team that isn’t technical and is looking for a simple app, such as a basic CRUD app or simple BI reporting. The apps built on low-code/no-code platforms should not be those that could take down the business if they break, and shouldn’t be overly complex.
Developer tools
We’re going to be frank here: we think that developer tools are a complete gamechanger. Many people lump them into the same category of low/no-code apps, but there is a key difference: while developer environments also abstract code to some extent, the goal is to expedite developer time for developers, not for non-technical people.
This means things like simplifying repetitive and lengthy code like UI components into a drag-and-drop interface, creating a GUI to control permissioning, and creating single connections and authentications to resources that can be used across apps. These kinds of tools, to varying degrees, allow much more customization than low/no-code tools, and you can typically build on top of them using traditional code. You can also usually incorporate other libraries to help you code even faster.
Pros of developer tools:
- Expedited development. These tools are designed to optimize all the repetitive tasks in coding, and simplify what can be simplified, in order to let developers focus on all the more complex customization. This results in a much faster time-to-market. With faster development time, apps no longer need to be built only for the long term, and can also be built to be deprecated much sooner.
- Maintenance. When it comes to API and resource connections, components, and updating dependencies, developer tools will take care of a lot of this for you. This is particularly great for those important, frequently used - but not necessarily critical - apps and automations, as it won’t require an engineer to keep an eye on those dependencies.
- Built for developers. Since these tools are built for developers, they know what makes developers tick. These platforms are continuing to evolve more technical, developer-friendly features and focus heavily on their experience. This means they typically have a high developer buy-on and are less likely to unsettle your engineering team.
- Almost as customizable as traditional code, and less of a hassle. These tools achieve nearly the same customization level as traditional coding, since many different elements of the app will be editable using code, making them inherently hackable. Nevertheless, you already have the starter blocks for building and don’t need to waste time building those, and this will get you off to a racing start.
- Developer fundamentals built-in. Since developer tools are looking to replace custom coding, they have most of the fundamentals already included. Such as: source control to match your company’s protocol, audit, and usage logs, and many also offer on-prem solutions to keep your app security compliant.
- Many offer the ability to host your entire infrastructure, with CRON jobs and automations too. You could build your entire internal app system on a single platform, with easy interlinking between them, and without needing to reconnect resources and configure databases each time. Platforms like Retool also offer mobile development too, opening up even more possibilities.
- Still approachable for less technical users - while developer tools may have developers at the forefront often they are accompanied by a drag-and-drop interface - something that a less technical user could manage if need be. Some functionality is non-technical, e.g. permissions, styling.
- Can be specifically built for your database. Software like Django Admin and Ruby on Rails can be a great option if you work on Django or Ruby as they are designed well to complement that code.
Cons of developer tools:
- Reduced portability. Most apps built on these platforms will not be portable, which creates issues if you are looking to migrate quickly.
- You are reliant on their code. You have less control over your code, and no control over their downtime, so you need to make sure the platform is reputable and reliable enough for your most critical apps.
- Service costs. Platforms will most likely have a monthly subscription cost to access your apps. While this hosting does involve a level of maintenance, costs can add up if you are only looking to build a single app, or you have lots of users.
- Some newer platforms have limited functionality. This is dependent on the nature of the app, and it’s difficult to know exactly at what point you will hit that wall. It’s a good idea to speak to an expert developer or sales agent from that platform to make sure you won’t have a nasty surprise midway into a project.
When do we recommend developer tools?
We recommend developer tools when teams have someone with a substantial amount of technical skills, and are looking to build for scale in an expedited way. The apps built on developer tools can run the full gambit - from near-mission-critical, to apps that are to be deprecated in a matter of months. Developer tools have the customizability of traditional code, with the approachability of low-code building platforms.
So, in summary:
The options for building your internal infrastructure are evolving quickly to allow teams to choose the building method that suits their companies’ needs best. Hopefully this article has provided some clear pros and cons for each option to help you scope out your development plan. If you want to read more, head to our Internal Tools 101 guide for help on how to choose the best apps to develop, and then how to best plan and develop those apps.
