Separate product work from repeated infrastructure
List the features that make your product useful, then list the infrastructure it needs to operate. A research workflow may be distinctive; session handling, customer-owned records, and subscription access usually are not. This inventory gives you a better evaluation tool than counting the number of features on a starter's homepage.
Building from scratch gives you direct control over those choices, but also responsibility for integrating and maintaining them. A starter changes the starting point. You still need to understand its code and verify the assumptions it makes about your product, team, and deployment.
Evaluate the code you will inherit
Run the setup instructions and follow one record from the interface to persistence. Check whether authorization lives at the server boundary, whether configuration is validated, and whether provider credentials stay outside client bundles. Read a negative test, not just the demo screen.
Look for places where the example product has become inseparable from the infrastructure. If removing a demo feature requires changing authentication or billing behavior, future product work may be harder than the initial setup suggests. In supastack, consuming products keep their domain logic outside Starter Core and connect through configuration and contracts.
Make the tradeoff explicit
Choose a starter when its existing boundaries match your needs and you can explain the flow you will depend on. Choose a custom foundation when the product's constraints would force repeated changes to the starter's assumptions. Either choice can be reasonable; the important question is which maintenance burden your team can carry.
Reserve time to replace sample content, configure integrations, review data ownership, and test deployment. A repository that compiles is a starting point for production acceptance. Before launching, verify the real sign-in path, billing lifecycle, and recovery behavior in the environment your customers will use.