Low-code, an in-house developer or a software firm: who should build your app?

The honest answer depends on what breaks if it fails

If the software supports one team, handles a simple workflow and an outage would cost an hour rather than a customer, building it yourself with a low-code tool or a capable employee is often the right call. If it runs a core process, connects several systems, holds sensitive data or must keep working when its builder leaves, you need the design, testing and support a professional team brings. The question is not whether your people can build an app; it is whether the business can depend on it.

I have no interest in talking anyone into a project they do not need. Some of the best decisions I have seen were companies choosing a low-code form over a custom system. Some of the most expensive cleanups I have seen started the same way. This guide explains how to tell the difference before you commit.

Where low-code tools earn their keep

Low-code platforms let people who are not professional programmers assemble working applications from building blocks. Microsoft describes Power Apps, one of the best-known examples, as a way to build custom business apps that connect to your data and to create feature-rich apps without writing code, while also giving professional developers ways to extend them. For the right job, that is a genuine advantage.

In my experience low-code tools work best when the process is contained within one department, the data already lives in a platform the tool connects to, the number of users is modest and the people who built it will be around to adjust it. Approval forms, simple trackers, inspection checklists and request queues are classic examples.

Low-code is also a useful way to learn. Building a quick version of a tool forces your team to decide how the process should work, which fields matter and who approves what. Even if you later replace it with a professionally built system, that first version becomes an excellent requirements document, because it shows what people actually used and what they ignored.

• Replacing a paper or email approval with a simple form and workflow.
• A departmental tracker that today lives in a shared spreadsheet.
• A mobile checklist for field staff that feeds a list or table.
• A prototype to test an idea before investing in a full build.

Where homegrown apps run into trouble

The trouble rarely shows up at launch. It shows up a year or two later, when the app has quietly become essential and its limits start to bite. The pattern is the same one I described in my guide on replacing the spreadsheet that runs your company: a tool that one person understands, carrying more of the business than anyone intended.

Watch for these signs. Each one is manageable alone; together they mean the app needs professional attention.

• Only the person who built it can change it, and they are busy with their real job.
• Nobody tests changes before they go live, so fixes sometimes break other things.
• Permissions are loose, so people can see or edit records they should not.
• It now connects to accounting, inventory or customer systems through fragile workarounds.
• Performance drops as more users and records are added.
• Licensing costs have grown as more people need to use it; Microsoft notes that a license is needed to run apps built with Power Apps.

Hiring one developer: what you are really taking on

Hiring a full-time developer feels like the middle path: more capable than a low-code tool, more control than an outside firm. Sometimes it is exactly right, particularly when you have a steady stream of smaller changes to existing systems. But a business application needs more than one skill set. Someone has to gather requirements, design the data model and screens, write the code, test it, secure it, deploy it, host it and support users. Very few individuals are strong at all of those.

There is also the continuity problem. A single developer is a single point of failure. If they leave, take a long vacation or simply get overloaded, work stops, and the knowledge of how the system works may leave with them. Recruiting is its own challenge: evaluating a developer's skills is hard if nobody in the company writes code, and a wrong hire can cost months before it becomes obvious. If you do hire, plan from the start for documentation, code kept in a shared repository the company owns, and a way to bring in outside help for testing and peak workloads.

Signs it is time to bring in a team

You do not need a software firm for every app. You do need one when the stakes rise beyond what an individual or a low-code platform can safely carry. If two or more of these describe your situation, it is worth a conversation with a professional team before building further.

When you reach that point, choosing the team carefully matters as much as the decision itself. My list of questions to ask a software firm before you sign is a good place to start.

• The application runs a process customers or revenue depend on.
• It must integrate with several other systems, including older ones.
• It stores personal, health or financial information.
• More than one department needs it, with different access rules.
• It has to scale to many more users, locations or transactions.
• An outage of a day would cause real harm.

A hybrid approach that often works best

The choice is not always either-or. A common and sensible arrangement is for a professional team to build and support the core system, the part that handles critical data, integrations and security, while internal staff use low-code tools for the smaller departmental needs around the edges. Done well, the core system exposes clean data and safe connections that the low-code apps can use, so the edges do not create new silos.

Another option is to keep development in-house and buy the pieces your team lacks. At Aezion we offer quality engineering on its own, including QA outsourcing and on-demand testing, for companies that write their own code but want independent testing before release. Application modernization and application support are core services for us too, and both start from a system that already exists rather than a blank page. If you already have an older system your staff built and nobody wants to touch, my guide on whether to modernize or rebuild a legacy application walks through the options.

Keep your infrastructure partner in the picture as well. Licenses, user accounts, devices and network security usually sit with a managed IT provider such as Anthony Omini at Cross River Tech, and any app your team builds has to fit inside those rules.

If you build it yourselves, protect the business

If your team does build the app, a few habits make the difference between a useful tool and a future liability. None of them require a software firm. They do require someone to take them seriously from the first day, not after the app has become critical.

These steps also make it far easier and cheaper to hand the app to a professional team later if it outgrows what your people can support.

• Write down what the app does, who uses it and where its data comes from.
• Keep the app and its data in company-owned accounts, never personal ones.
• Have at least two people who know how to change it.
• Test changes in a copy before applying them to the live version.
• Set permissions deliberately and review them when people change roles.
• Back up the data and confirm you can restore it.

Comparing the real cost of each route

Low-code looks cheapest at the start, a developer looks cheapest in salary terms, and a firm looks most expensive on the proposal. The comparison changes once you count everything: licensing as users grow, the time internal staff spend building and fixing instead of doing their own jobs, the cost of an outage or a data mistake, and the cost of rebuilding later if the first version cannot scale.

A fair comparison puts all three routes over the same multi-year period and includes support, hosting, testing and the risk of key-person loss. When we do this exercise with clients, sometimes the answer is low-code, sometimes it is an internal hire with outside testing, and sometimes it is a professional build. The point is to decide with the full picture rather than the first number. Whichever route you choose, write down why, so the decision can be revisited when the business changes.

How we help teams that started on their own

A good share of the conversations I have begin with an app someone inside the company built. It worked, the business grew around it, and now it is straining. We start by understanding what it does well, because those strengths are worth keeping, and then look at where it is fragile. Sometimes the right move is to stabilize it and add testing; sometimes it is to rebuild the core properly and leave the simple pieces in low-code.

If that sounds like your situation, bring a short description of the app, who uses it, what it connects to and what has gone wrong recently. Dallas-area teams can meet us in Frisco, and many clients start with a remote working session. Either way, you will leave with a clear view of whether you need us at all.

Questions people ask me