Before we wrap up, let's cover a few practical things that are useful to know as your teams build and deploy Apps. These aren't restrictions to worry about so much as helpful context to keep in the back of your mind.
File limits. Each App supports up to 256 files, and each file has a size limit of 128kb. For most Apps, this is plenty of room, but it's good to be aware of as your Apps grow more complex.
Endpoint response times. Endpoints have a timeout of around 30 seconds, so it's best to keep them responsive. That said, this doesn't mean your App can't support longer-running tasks. Rather than building one endpoint that tries to do everything in a single call, shape the work into three separate endpoints instead:
A submit job endpoint that kicks off the task.
A poll task endpoint your App can check periodically to see if the task is done.
A fetch result endpoint that retrieves the final output once it's ready.
This build design lets your App support work that takes minutes (or longer) to complete, without ever breaking the timeout on any single endpoint. For example, an App that generates a large report could submit the report request, poll every few seconds to check its status, and then fetch the finished report once it's ready, all while staying responsive throughout.
Endpoints and flow counts. Endpoints don't count as flows. This is a licensing-related detail worth keeping in mind as your team scales up the number of Apps and endpoints it builds.
Building efficiently. As covered earlier in this path, keeping your build conversations small and focused (and starting a new conversation for each significant change) helps keep the builder accurate and your work organized.
These considerations help ensure your Apps stay reliable and performant as your teams put them to use.