Build Economics Baseline (Onboarding)

Build Economics Baseline (Onboarding)

1. 01

   Log the conventional-build estimate before opening any visual builder

   Capture hours by role, blended rate, and expected calendar weeks for the same scope. Without a counterfactual, any later claim of faster delivery is an opinion rather than a measured delta.

2. 02

   Time the assembly of one representative screen in two platforms from the roster

   Pick a screen with a data table, a form, and a permission rule. Build it in something like Noloco for a portal pattern and WeWeb for a custom front end, then record elapsed hours per builder.

3. 03

   Write down the platform ceiling you expect to hit within 12 months

   Name the specific limit in advance: row counts, workflow run caps, API call quotas, or mobile parity. A ceiling discovered in month nine becomes a re-platforming invoice the client did not budget for.

4. 04

   Map every data source the app will read and who owns each one

   List the client systems, the sync direction, and the field-level owner. Data preparation failures, not model or builder choice, account for most failed AI and app projects, so settle ownership before the first record moves.

5. 05

   Confirm the client's ownership and export position in writing

   Ask what happens to the schema, the data, and the automations if the retainer ends. Platforms differ sharply here, and a white-label arrangement on one tool does not transfer to another.

6. 06

   Set a stage label for the build and match the deliverable to it

   A proof of concept, a prototype, a pilot, and an MVP answer four different questions. Mislabeling the stage is how agency scopes drift into budget overruns before the first demo.

7. 07

   Record a pre-build time baseline across at least three client accounts

   Track current weekly hours on the tasks the app will absorb, using a time tool the team already runs. A baseline captured after launch cannot attribute savings to the build.