Start with what the app does.
Bring the current tool or describe the job it needs to do. We look at who uses it, what information it handles, which models it calls and where it runs now.
A prototype, an existing app or a new build can each need a different arrangement. The app build itself can be scoped through Flying Penguin Software.
Host the parts it actually needs.
The setup may include a web interface, server-side application, database, document storage and background jobs. We choose those parts for the workload and name them in the proposal. You can see which accounts hold the application and information, and who pays each supplier.
Keep model access on the server.
Provider credentials belong in controlled server-side storage. We review the app’s existing access, who can change it and what happens if a key needs replacing. An app that exposes a provider key to visitors needs that issue resolved before launch.
Check usage and failure behaviour.
We agree request limits, usage visibility and what should happen when the model is unavailable or a budget threshold is reached. A warning and a rule that blocks new requests are different controls. The checks should cover the behaviour promised for your setup.
Plan the running work.
Updates, monitoring, backups, recovery checks and support arrangements go into the service scope. We also agree how app changes are released and how to move the service later. Hosting and management are quoted for the application; model usage is identified separately.