No-code and low-code platforms work when the application is internal, the data set is modest, the logic is standard and the business can live with the vendor's hosting and roadmap. They stop working when the app becomes a core product, handles large or sensitive data, or needs integrations and security the platform was not designed for.
What no-code and low-code actually mean
No-code platforms let non-developers build applications entirely through a visual interface, while low-code platforms combine visual building with the option to add code where needed. OWASP describes both as platforms that create software "through a graphical user interface instead of traditional hand-coded computer programming". In practice the line is blurry: Bubble and Webflow lean towards no-code, Retool and Microsoft Power Apps sit closer to low-code because developers can write queries, scripts and custom components inside them.
The distinction matters less than the trade it represents. You gain speed and lower the skill barrier; you give up some control over performance, hosting, security configuration and the ability to move the application elsewhere.
Where no-code platforms deliver value
No-code platforms deliver the most value in three scenarios: internal tools, prototypes and content-driven websites. In each case the application serves a limited audience, the logic is mostly standard, and the cost of the platform's limits is low.
- Internal tools. Dashboards, admin panels, approval workflows and data-entry forms used by staff. The users are known, the volume is predictable and downtime is an inconvenience rather than lost revenue.
- Prototypes and MVPs. Validating a business idea with real users before committing to custom development. A prototype that proves demand is worth more than a well-architected product nobody wants.
- Content-driven websites. Marketing sites, blogs and landing pages, where visual builders such as Webflow let marketing teams publish without a developer. Our Webflow vs WordPress comparison covers that choice in detail.
The business case is strongest when the application serves internal users and does not depend on complex integrations. Development is typically much faster than a custom build because the platform supplies hosting, authentication, a database and UI components out of the box.
Where no-code platforms run into limits
No-code platforms consistently struggle with complex business logic, large data sets, custom authentication and deep third-party integrations. The common pattern is that the platform handles most requirements easily, and the remaining few become either impossible or more expensive than custom development would have been. Businesses that discover this after launch face a costly rebuild.
Data volume
Data limits are concrete, not theoretical. In Power Apps, if a formula cannot be delegated to the data source, Microsoft's documentation explains that Power Apps "gets the first 500 records from the data source and then runs the actions in the query", with a configurable ceiling of 2,000. The same page warns that a filter over a million-record source may simply not find record 501. An app that works perfectly in testing with a few hundred rows can return incomplete results once real data accumulates.
Usage and throughput
Platform usage is also metered. Microsoft sets Microsoft Learn, Power Platform request limits per licence per 24 hours, for example 40,000 requests for a Power Apps per user licence and 6,000 for a Power Apps per app licence. Automations that poll frequently or process large batches can reach these limits, at which point the fix is more licences or add-on capacity, not better code.
Security configuration
Security in no-code apps depends heavily on how the builder configures connections and permissions. The OWASP Low-Code/No-Code Top 10 exists because, in OWASP's words, there is "a clear and immediate need to create awareness around security and privacy risks" in these applications. In our experience the weak points are usually configuration choices rather than platform bugs: an app connected to a database with the builder's own admin credentials, or data connections shared more widely than intended.
| No-code works well for | No-code underperforms on |
|---|---|
| Internal tools: dashboards, admin panels, approval workflows | Complex, rule-heavy business logic |
| MVPs and prototypes that validate an idea before custom development | Large data sets (for example, Power Apps non-delegable queries cap at 500–2,000 records, per Microsoft Learn) |
| Content-driven websites: marketing sites, blogs, landing pages | Custom authentication and fine-grained access control |
| Applications for internal users without complex integrations | Deep, high-volume third-party integrations |
How vendor lock-in works in practice
Every no-code platform creates vendor dependency, because your application logic, data structures and interface live inside the platform's proprietary system. If the vendor changes pricing, deprecates features or suffers an outage, your application is affected and you have limited options.
The degree of lock-in varies by platform, and it is worth checking before you build. Bubble's support article is explicit: "We do not support on-premise self-hosting or code exports at this time." Leaving Bubble therefore means rebuilding the application logic elsewhere. Other platforms offer more control: Retool documents self-hosted deployments, described as single-tenant instances "deployed on its own dedicated infrastructure", aimed at organisations that need full control.
| Question to ask the vendor | Why it matters | Example from vendor documentation |
|---|---|---|
| Can we export the application as code? | Determines whether leaving means migrating or rebuilding | Bubble: no code export; JSON export only for another Bubble app (Bubble Support) |
| Can we self-host? | Control over infrastructure, network access and data location | Retool offers Retool-managed and self-managed self-hosted options (Retool self-hosted docs) |
| Where is our data stored? | Data residency and regulatory obligations | Power Platform apps are deployed in the region that hosts the environment (Microsoft Learn, Power Platform regions) |
| What are the data and usage limits? | Hidden ceilings that appear only at scale | Power Apps delegation limit of 500–2,000 records; 40,000 daily requests per Power Apps per user licence (Microsoft Learn, Power Platform request limits) |
| Can we export our data in a usable format? | Your data should outlive any one platform | Confirm the export format and whether relationships between records are preserved |
For mission-critical applications, weigh this risk against the speed advantage. The practical mitigation is to keep no-code for non-critical applications and use custom development for core business systems.
Data protection considerations in Singapore
Using a no-code platform does not remove your obligations under Singapore's Personal Data Protection Act 2012; choosing a platform is part of how you meet them. The Act's Part 6 covers protection of personal data (section 24) and transfer of personal data outside Singapore (section 26), and Part 6A sets out data breach notification duties.
For a no-code project that handles customer or employee data, that translates into practical checks: know which country the platform stores data in, confirm the vendor's security controls and certifications, restrict who can share apps and connections, and make sure you can retrieve and delete records when required. Microsoft, for example, lets administrators see the region of each Power Platform environment and notes that environments are bound to that geographic location, according to its regions documentation.
Why the hybrid approach works best
The most effective strategy for growing businesses is hybrid: no-code for internal tools, content management and rapid prototyping, custom development for customer-facing products, core business logic and data-intensive applications. This captures the speed of no-code where it matters and keeps control and scalability where they are critical.
A common sequence is to prototype in a no-code tool, validate demand with real users, then rebuild the proven core as a custom web application while internal back-office tools stay on the platform. Planning for that rebuild from the start, by keeping data in a portable database and documenting business rules outside the platform, makes the transition far cheaper.
A decision framework for Singapore SMEs
Ask four questions before choosing a no-code platform. If the answer to any of them is yes, look closely at custom development or a low-code platform with self-hosting.
- Will the data outgrow the platform's limits? Check documented limits such as Power Apps delegation, row counts and request allocations against your expected volume in two to three years, not today.
- Does the application handle sensitive customer or financial data? If yes, review the platform's security certifications, hosting region and access controls against your PDPA obligations.
- Would losing the platform stop the business? If yes, confirm code or data export and self-hosting options before building.
- Is this a core business differentiator? If yes, custom development preserves your competitive advantage and IP ownership.
If you are unsure whether an idea should be built on a platform or from scratch, a short validation phase is cheaper than a rebuild. Namtech Pte Ltd, a Singapore AI transformation consultancy, offers a Strategic Technology Validation package (SGD 12,000, 4–8 weeks) to test feasibility and architecture before committing.
Use no-code where speed matters most, and custom code where control, data scale and long-term ownership are critical.