Platform Fit Triage Before Scoping a Client Build (Onboarding)

Platform Fit Triage Before Scoping a Client Build (Onboarding)

1. 01

   Write the client's requirement as a data model before opening any builder

   List every entity, its fields, and the relationships between them. If the model needs more than three levels of nesting or cross-entity rollups the client cannot describe in plain language, flag the build for a conventional stack review.

2. 02

   Score integration depth against the systems the client already pays for

   Confirm read and write access to the client's CRM, billing, and support tools. A portal that can only read from HubSpot but must push status updates back is a different build than one that stays read-only.

3. 03

   Test the platform's ceiling on the single hardest screen, not the easiest one

   Rebuild the most complex view the client described, such as a permissions-filtered dashboard or a multi-step approval form, inside a trial workspace. Bubble, WeWeb, and UI Bakery all publish different limits on custom logic and component reuse, so the ceiling test is the only reliable comparison.

4. 04

   Confirm who owns the workspace, the domain, and the data export path

   Ask whether the client gets an admin seat on their own tenant or sits inside the agency's account. Noloco and Taskade both support white-label and resale arrangements, and the ownership answer changes what happens at contract end.

5. 05

   Price the build against a conventional estimate using the same scope document

   Put hours and dollars on both paths before recommending either. A portal that takes 40 hours in a visual builder but 30 hours in a framework the team already knows is not a win.

6. 06

   Check accessibility and performance requirements against platform defaults

   Regulated or public-sector clients often carry WCAG obligations that visual builders do not meet out of the box. Load-test the prototype with realistic record counts, since list views that feel instant at 200 rows can stall at 20,000.

7. 07

   Document the migration path in writing before the client signs

   State what a future move to custom code would cost in hours and what data would need re-mapping. Buzzy's semantic-definition approach and AINIRO's open-source core represent two different exit stories, and the client should know which one they are buying.

8. 08

   Set a go/no-go review date 30 days into the build

   Schedule the checkpoint before work starts so scope creep gets caught while the retainer still has room to absorb it.