Build Versus Platform Decision Gate (Onboarding)

Build Versus Platform Decision Gate (Onboarding)

1. 01

   Write the client's data model before opening any builder

   List every entity, its fields, and the relationships between them. A relational schema drawn on paper exposes join complexity that a spreadsheet-style base such as Airtable hides until the second or third revision.

2. 02

   Score each requirement against platform ceilings, not demo behavior

   Record row limits, API call quotas, and workflow execution caps for the shortlisted tools. Bubble, Glide, and Knack publish different ceilings, and the one that fails is usually the one nobody checked.

3. 03

   Separate what the client owns from what the agency operates

   Confirm who holds the account, the domain, and the export rights at contract end. White-label options exist in Noloco and Taskade, but ownership terms still need to be written into the retainer.

4. 04

   Price the conventional build alongside the platform build

   Estimate hours for both paths using the same scope document. A platform that saves two weeks of assembly but adds three weeks of workaround maintenance is not cheaper.

5. 05

   Flag every requirement that needs custom code or an external service

   Authentication edge cases, complex permissions, and high-volume reporting are the usual escape hatches. Note which platform handles them natively and which pushes the work back to the agency.

6. 06

   Set the migration exit before the first screen is built

   Document how data leaves the platform in a usable format and how long that export takes. Migration paths vary widely, and a client portal that cannot be moved becomes a permanent dependency.

7. 07

   Get written client sign-off on the platform choice and its limits

   State the known constraints in plain language, including what the app will not do. This single document prevents most mid-delivery scope disputes.