You will finish and deploy a small app that calls a model API from a server, with the key kept server-side.
An app on your laptop helps nobody else. Priya's summariser ran perfectly on her machine for a week, and her team leads still could not use it, because it lived on her laptop. This project closes that gap. You finish the features in your spec, put the app on the internet with the key kept safe, protect your budget, and watch two real people use it.
Allow about 90 minutes, more if this is your first deployment. You need your spec from lesson 6.2, your committed code from lesson 6.3 and your bug log from lesson 6.4.
Here is the brief. Deploy a small app that does the job in your spec. It calls a model API from a server, with the key set as a secret on the hosting service and never in the code or the browser. It has basic limits that stop one user from running up your bill. Two people other than you have used it, and you have written down where they got stuck and what you changed.
Look at your spec and list what is left to build. Build those features using the habits from this module: one at a time, run after each, commit after each.
Then stop. This is the moment when the list of later features from lesson 6.1, Pick a project small enough to finish, starts to look tempting. Leave it alone. Each extra feature delays the moment real people use the app, and their reactions will reorder that list anyway.
Choose a hosting service that supports your stack. Many have free tiers suitable for a small app, and your coding assistant can tell you which ones fit the framework you used. Most connect to your code repository and deploy automatically whenever you push a commit.
Push your code to a private repository on a code hosting service, then connect it to the hosting service. Before you push, check one last time that your env file is not in the repository.
Then set the key. Every hosting service has a settings page for environment variables or secrets. Add the API key there, with exactly the name your code reads, such as MODEL_API_KEY. The code does not change between your laptop and the server. Only the value it is given changes, as lesson 1.2 described.
Open the deployed app and test it. Then open the browser's developer tools, look through the page sources and the network tab, and confirm the key appears nowhere. You will do this check more thoroughly in lesson 8.4, but do it now too.
A public link can be shared further than you meant. Add two limits on the server, where users cannot get around them.
First, a maximum input length. Priya's server rejects any request over 50 feedback items or 20,000 characters in total, with a clear message. Choose limits from what a normal use looks like, with room to spare.
Second, a limit on requests per user. Without accounts, you can limit by IP address, for example a few requests per minute and a set number per day. Many hosting services and frameworks have rate limiting built in or available as a small addition. Ask your assistant what fits your stack. When the limit is hit, show a message saying when the user can try again.
Keep the monthly spending limit on your provider account from lesson 1.1. The limits in your code stop ordinary overuse. The provider limit is the last line if everything else fails.
Pick two people who match the user in your spec. Send them the link and one sentence about what it does. Do not explain more than that. Then watch them use it, in person or on a screen share, and say nothing unless they are completely stuck.
Write down every moment they hesitate, misread something or do something you did not expect. Priya's first tester pasted a whole email thread, greetings and signatures included, and got rows for "Hi team" and "Best regards". Her second tester did not notice the results table had appeared below the fold and pressed submit three times.
Pick the three biggest problems and fix them. Priya added a line under the text box saying "One piece of feedback per line", made the page scroll to the results, and disabled the button while a request was running.
A link to a working app on the internet. The code in a git repository, with the key stored only as a secret on the hosting service. Input length and per-user limits on the server, both tested by trying to exceed them. And a short note with three things your testers struggled with and what you changed for each.
That note is the start of version two.
Deploy your app, share the link with two testers, and write down three things they struggled with and what you changed.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).