The Canvas Tech Debt Audit: 20 Things to Check Before Adding Features

Technical debt in Canvas (Airdev's Bubble framework) apps doesn't look like technical debt in code apps. There's no eslint config screaming at you, no test suite turning red, no GitHub PR ratio to track. The debt accumulates quietly, in places that the editor doesn't surface, until one day you realise you can't ship features anymore.

This article gives you 20 concrete checks we run when auditing Canvas apps for AppSavvy clients. Run it quarterly. Definitely run it before committing to a major feature push.

How to use this list

Score each item as clean, needs attention, or debt. Total up the debt items - more than five and you should fix some before any major new features. More than ten and you should fix most before any major new features.

Time-box the audit at 4-6 hours. You're not fixing things in this pass - just inventorying.

Data model debt (5 items)

1. Duplicate Data Types

Look for Data Types that overlap meaningfully. Common patterns: "Order" and "Purchase", "User Profile" and "Settings", "Customer" and "Account". Often these were created at different times for what turned out to be the same concept.

Status check: if two Data Types have substantial field overlap and similar semantic meaning, mark as debt.

2. Unused fields

Open a few large Data Types and identify fields that nothing reads. The data field inspector + Bubble's text search across workflows is the quickest way to find them.

Status check: more than 15% unused fields = debt. 5-15% = needs attention.

3. Soft-deletes via boolean field

Data Types with a "Deleted?" yes/no field. The cost: every search needs to filter on it, every workflow needs to be careful not to include them, and the data accumulates indefinitely.

Status check: if you have soft-delete booleans and they're not always being filtered, this is debt.

4. Denormalised data that's drifted

Fields stored in two places that should always match (e.g. user_name on a Booking and name on the User). Pick a few records and check whether the values match.

Status check: any drift found = debt.

5. Orphaned records

Records referencing other records that no longer exist. The data API doesn't enforce referential integrity, so this builds up.

Status check: run a sample query for each foreign reference field and count NULLs / broken references. More than 1% orphans = needs attention.

Workflow debt (5 items)

6. The "everything fix-it" workflow

Almost every Bubble app has one. A workflow that started as a simple thing and grew into a 30-action monster handling unrelated cases via conditional steps.

Status check: if you have a workflow with >15 actions and >3 distinct purposes, debt.

7. Recursive workflows that have been running for weeks

Look at the scheduled workflows queue. Anything that's been recursing for more than 24 hours is probably stuck or processing stale data.

Status check: long-running recursive workflows = needs attention at minimum.

8. Race conditions in workflow logic

Multiple workflows that update the same record under similar triggers. Without explicit ordering, the order of operations is whatever Bubble decides.

Status check: if more than 2 workflows can be triggered concurrently on the same record, mark as debt unless you've explicitly designed for it.

9. Custom code escape hatches

JavaScript actions, HTML/CSS overrides, the API connector with raw payloads. Each one is fine in isolation - in aggregate they're an unmaintainable layer.

Status check: more than 10 distinct custom-code escape hatches = debt.

10. Workflows that send email outside the standard pattern

If your app has 3+ different ways of sending email (Bubble's built-in plus a couple of plugins plus the API connector to a service), that's debt accumulating.

Status check: more than one active email-sending pathway = needs attention.

Page and UI debt (4 items)

11. Near-duplicate pages

Admin views, user views, and "v2" pages that duplicate functionality. Check for pairs that should probably be one page with conditional logic.

Status check: more than 3 near-duplicates = debt.

12. Reusable elements used only once

Defeats the purpose of being "reusable". Either inline them or make them actually reusable.

Status check: more than 5 single-use "reusables" = needs attention.

13. Custom states doing business logic

Custom states are meant for UI state. When they're holding business-domain data, that data lives nowhere durable.

Status check: any custom state holding data your business cares about = debt.

14. Conditional formatting doing authorisation

UI hiding fields based on user role isn't authorisation - the data is still in the page. If the only thing stopping a user from seeing a field is "this dropdown is hidden", that's a privacy issue, not just debt.

Status check: any role-based UI hiding without backing privacy rules = debt (and potentially security).

Plugin and integration debt (3 items)

15. Abandoned plugins

Plugins that haven't been updated in 12+ months, or whose publisher has gone silent. Bubble has been around long enough that this is increasingly common.

Status check: any abandoned plugin in critical workflows = debt.

16. Plugins doing things that should be server-side

Authentication, payment processing, sensitive data handling - these belong on a server you control, not a Bubble plugin.

Status check: any critical security/payment work in a community plugin = debt at minimum.

17. Integrations using deprecated APIs

API connectors calling versions of third-party APIs that the vendor has marked as deprecated. The vendor will turn these off eventually.

Status check: any deprecated-API integration = needs attention, escalating to debt within 6 months of deprecation date.

Privacy and security debt (3 items)

18. "Everyone else" privacy rules with full access

Data Types that have an "Everyone else" rule allowing access. Whether that's intentional should be a deliberate, documented choice.

Status check: any "Everyone else" rule allowing more than display name lookup = debt unless documented.

19. Privacy rules referencing deleted Users

If a privacy rule's condition references something that no longer exists, the rule can fail open. Test with a sample deleted-user record.

Status check: any test that shows a fail-open = debt (and potential security).

20. No documented authorisation model

You should be able to describe, in a paragraph, how authorisation works in your app. Roles, what they can do, where access is enforced. If you can't, neither can the next engineer.

Status check: no documented authorisation model = debt.

What to do with the results

Once you've scored all 20:

• 0-3 debt items: healthy app. Continue normal feature work.
• 4-7 debt items: schedule a 2-3 week refactor sprint before any major feature push. Tackle the highest-impact debt first.
• 8-12 debt items: the app is carrying meaningful structural debt. Either invest in a major refactor (8-12 weeks of work) or honestly consider whether migration off Canvas is the right move.
• 13+ debt items: the app is in maintenance-only mode unless you address the debt. New features will compound the problems and slow down even more.

How often to run this

We recommend running this quarterly for any active Canvas app. The audit takes a working day; the debt grows continuously, and untracked debt is the most expensive kind.

It's also worth running before:

• Any major feature push (so you fix the relevant debt before it compounds)
• Any team change (so the new person doesn't inherit a hidden disaster)
• Any funding event or M&A diligence (so the score isn't a surprise to anyone)

What to do next

If you'd like an external review of your specific Canvas app, request a free Bubble app audit - we'll send a written report covering security, performance, maintainability (including the items above), and migration risk.

If the audit suggests structural problems that need an experienced ex-Airdev hand, book a 30-minute discovery call.

Read next: Canvas v5 to v6: upgrade, rebuild, or migrate and Quarterly maintenance checklist for Canvas apps.