WhatsApp
Microsoft Azure
JavaScript
PostgreSQL
PythonWhere low-code fits
Low-code platforms let teams build applications with visual designers, pre-built connectors and a small amount of code. They are excellent for internal tools, approval workflows, data-entry apps and dashboards — the hundreds of small applications every organisation needs but rarely has developers to build.
Low-code is not a fit for everything. Customer-facing products, high-volume transaction systems and apps with complex logic usually benefit from conventional development. We help you decide where each approach belongs, and combine them where that gives the best result.
Problems we solve
- A backlog of small internal tools IT never has time to build
- Processes run on spreadsheets and email attachments
- Citizen-developed apps with no security review or ownership
- Power Apps or Retool projects that have grown beyond their creators
- Licences paid for but little value delivered
What’s included
Internal apps
Power Apps, Retool, Appsmith or similar for forms, dashboards and tools.
Workflow automation
Power Automate, Make or n8n flows for approvals and notifications.
Connectors & APIs
Custom connectors to systems the platform does not support out of the box.
Governance
Environments, data-loss-prevention policies and app ownership rules.
Rescue & refactor
Stabilise and document low-code apps that have become business critical.
Migration to custom code
Move apps to full development when they outgrow the platform.
Low-code or custom code?
| Factor | Low-code | Custom code |
|---|---|---|
| Speed to first version | Days to weeks | Weeks to months |
| Users | Internal, moderate numbers | Any, including customers |
| Complex logic & performance | Limited | Unlimited |
| Licensing | Per user or per app | Hosting costs |
| Vendor dependency | High | Low |
Governance that enables, not blocks
The fastest way to create risk with low-code is to let every department build without guardrails. The fastest way to kill its value is to ban it. We set up a middle path: separate development and production environments, data-loss-prevention policies that control which connectors can be combined, naming and ownership standards, and a lightweight review before apps go live. Business teams build quickly while IT keeps visibility.
Comparing popular low-code platforms
| Platform | Strengths | Typical fit |
|---|---|---|
| Microsoft Power Platform | Deep Microsoft 365, Teams and Dataverse integration | Organisations standardised on Microsoft |
| Salesforce (Flow, Lightning) | Automation on top of CRM data | Sales and service processes in Salesforce |
| OutSystems / Mendix | Enterprise-grade apps with more developer control | Larger internal application portfolios |
| Retool / Appsmith | Fast internal tools over databases and APIs | Admin panels and operations dashboards |
| Airtable / Glide / Softr | Very quick for simple data apps | Small teams, prototypes, lightweight tools |
Licensing models differ widely — per user, per app, per run — so model costs for your expected number of users and automations before committing.
Avoiding low-code pitfalls
- Apps built by one person with no documentation or backup owner
- Business-critical data stored in platform tables with no export plan
- Per-user licence costs that grow faster than expected as adoption spreads
- Complex logic forced into visual flows that become hard to read and test
- No separation between development, test and production environments
- Connectors to sensitive systems created without IT review
A light governance model — environments, naming conventions, data policies and an inventory of apps — solves most of these. When an app outgrows the platform, a clean data model makes it much easier to move to custom code later.
Where professional developers add value
Low-code does not remove the need for engineering; it changes where engineering effort goes. Professional developers are most valuable building reusable connectors to internal systems, writing custom components the platform lacks, designing data models that will scale, setting up environments and deployment pipelines, and reviewing citizen-built apps before they become business-critical. This fusion-team model lets business users move fast on the parts they understand best, while developers keep the foundations secure and maintainable.
A typical low-code engagement
-
Assess1–2 weeks
Review the process, data sources, licences you already hold and any existing apps built by business users.
-
Design the data model
Decide where data lives — Dataverse, SharePoint lists, SQL or an existing system — before building screens. This is the decision hardest to change later.
-
Build in increments2–6 weeks
Deliver a working app to a small group quickly, then extend it based on use.
-
Harden1–2 weeks
Error handling, permissions, environment strategy and automated deployment between development, test and production.
-
Hand over
Documentation and training so a business owner or citizen developer can make routine changes safely.
Timelines are typical for departmental apps; apps that replace a core business system deserve a longer discovery and a proper architecture review.
Licensing and cost traps
Low-code platforms are often licensed per user, per app or by capacity, and the cheapest licence tier rarely covers premium connectors, larger databases or external users. Before committing, we model the licence cost for your expected users and features over three years, alongside the build cost.
- Premium connectors (for example to SQL or third-party APIs) can move every user onto a higher licence tier
- External users such as customers or suppliers are usually priced differently from employees
- Storage and automation run limits can be exceeded as usage grows
- Some features require add-ons or capacity purchases rather than user licences
The licensing rules of each platform change regularly, so we confirm current pricing with the vendor or your licensing partner before you commit.
Application lifecycle management for low-code
- Separate development, test and production environments
- Solutions or packages that move between environments through a pipeline, not manual copying
- Source control for app definitions where the platform supports it
- Naming conventions and documentation for flows, connectors and data tables
- A process for retiring apps that are no longer used
- Monitoring of failed automations with alerts to an owner
Without these basics, low-code estates become as hard to maintain as the spreadsheets they replaced.
Signs an app has outgrown low-code
- Performance problems with large data volumes or complex calculations
- Licence costs for external or high user counts exceeding what custom hosting would cost
- Workarounds piling up to achieve user experiences the platform does not support
- A need for offline mobile use, complex integrations or fine-grained security the platform handles poorly
When that happens, we migrate the app to custom code in stages while users keep working. See custom software development and business process automation.
Integrating low-code apps with core systems
Low-code apps are most valuable when they work with your real data instead of copies. We connect them to ERP, CRM and databases through supported connectors or a small custom API, with service accounts and permissions scoped to what each app needs. Where a connector does not exist, a lightweight API layer keeps the integration secure and reusable by other apps.
We also document which apps depend on which data sources, so a change to a core system does not silently break the apps people rely on.
Integration choices are documented alongside each app so future changes are planned, not discovered.
Related services
Low-code often complements business process automation and intranets. For apps that need more, see web application development.
This page is part of Enterprise Application Development Services — see the full overview for related services, approach and pricing.