Build a client portal with AI that you can actually hand over

A client portal can sound like a large project. The first useful version may be much smaller: a client signs in, sees the agreed next step, and leaves feedback on one deliverable.

For a freelancer, the opportunity is to build a clear workflow and a responsible handoff. The obligation is to understand and verify what you deliver.

Agree the job before writing code

Choose a specific buyer and process. For this fictional example, a consultant wants clients to see a project status, review a link, and leave feedback. Billing, file uploads, team chat, and automated reminders are outside the first scope.

Write acceptance criteria in ordinary language. The client can return later and see saved feedback. One client cannot access another client's project. Failed saves show a useful error. The owner knows how to remove access.

Give the agent enough context

Choose ChatGPT Work or Codex based on the environment and connected tools you can use. Select Astra with Extra High reasoning for the demanding planning work if your account offers it. A model setting does not authorize access to a client's accounts.

Build a small client portal for the workflow below. Use a client-owned private GitHub repository if repository creation is supported and I have the client's permission; otherwise prepare the project and identify the exact remaining setup step. Prepare Railway hosting and Supabase authentication and saved records. Use fictional data. Include setup instructions, a dependency lockfile, migrations, and environment-variable names without values. Define acceptance criteria and explain the access model before implementation.

Agree ownership with the client. The repository, hosting, database, and domain should not become accidental dependencies on a freelancer's personal accounts.

Build one complete route

Ask the agent to implement sign-in, the project screen, feedback submission, and the return visit together. Review loading, empty, and failure states. Check that the user receives confirmation only after the record is stored.

Keep privileges narrow. The browser should never receive a Supabase secret or service-role key. Test the intended record ownership rules with separate accounts, including direct requests to another client's project.

Deploy with an inspectable record

Connect the correct GitHub repository and branch to Railway. Supply the application's required variables through platform settings. Record the deployed commit, the environment, and the generated URL before adding a custom domain.

A passing build establishes that the application built. It does not establish that the real sign-in and feedback journey works. Test that journey through the deployed URL, including the auth redirect after a domain change.

Price the handoff as part of the work

A useful handoff includes account ownership, setup instructions, maintenance responsibilities, recurring cost categories, known limitations, and a rollback plan. Agree what support is included and how later changes will be estimated.

Show any portfolio version as a demonstration until it is real client work you have permission to share. AI-assisted production does not justify invented results or presenting an untested portal as production-ready.

Make the next sale from proof

Keep a short record of what you built, what you checked, and what remains outside scope. A clear demonstration and honest limitations can make the offer easier to evaluate than a promise to build anything.

Explore Railway through our referral link. Start with one workflow you can verify, explain, and support. That is the foundation of a service you can responsibly sell.

Continue with How to hire an AI freelancer on Upwork: start with one paid pilot.

Sources

• OpenAI: Models and reasoning settings
• Railway: GitHub autodeploys
• Supabase: API keys
• Supabase: Row Level Security