Build a Business Communication Tool

Build the Final Application

You have now worked with text prompts, system instructions, structured JSON, images, PDF documents, server-side security, response validation, and application planning.

This final lesson combines those concepts into one working business communication prototype.

What the Final Prototype Uses

• The project name and purpose from Lesson 9
• The intended user from the saved project plan
• The system instruction from the project plan
• A controlled text-input form
• The existing secure PHP Gemini endpoint
• AI-gency's existing Gemini key and credit system
• Input-length validation
• CSRF protection
• Loading and error states
• A generated result panel
• Model and token information
• A copy-result button

Your Saved Plan Becomes the Blueprint

Lesson 10 looks for the same browser-storage key created by Lesson 9:

gemini-builder-final-project-plan-v1

When a saved plan is available, the prototype uses its application name, audience, purpose, input limits, system instruction, expected output, safeguards, and testing information.

How the Final Application Works

The prototype follows this complete application flow:

Lesson 9 Project Plan
        ↓
Lesson 10 Loads the Configuration
        ↓
User Enters a Business Message
        ↓
JavaScript Validates the Input
        ↓
PHP Validates the Request Again
        ↓
AI-gency Loads the Private Gemini Key
        ↓
Gemini Processes the Message
        ↓
PHP Extracts the Visible Response
        ↓
JavaScript Displays the Result

Why Validation Happens Twice

JavaScript checks the input first so the user receives immediate feedback.

PHP checks it again because browser-side validation can be removed, changed, or bypassed.

The Browser Request

The final prototype sends:

{
    "prompt": "The user's current business message",

    "system_instruction": "The planned application behavior",

    "response_mode": "text",

    "csrf_token": "The current session security token"
}

It does not send:

• The Gemini API key
• AI-gency's protected key configuration
• Server paths
• Private PHP information
• Raw connection diagnostics

What Belongs in the Browser?

• The visible form
• The user's current input
• Character counting
• Sample-message buttons
• Loading indicators
• The generated result
• Copy functionality

What Belongs on the Server?

• The private Gemini API key
• Session validation
• CSRF validation
• Input-size enforcement
• Request-rate protection
• The Gemini API connection
• Response extraction
• Safe error handling
• Usage and credit controls

Prototype Configuration Versus Production Configuration

Lesson 10 loads the system instruction from Lesson 9 browser storage to demonstrate how planning becomes application behavior.

A production version would move that approved instruction into a protected PHP configuration file:

<?php

$systemInstruction = '
You are a professional business communication assistant.

Preserve the original meaning.

Do not invent information.

Return only the rewritten message.
';

The user-facing browser would then submit only the message and approved visible options.

Why the Final Application Reuses Existing Code

Lessons 4 through 6 already proved that the PHP endpoint can:

• Load the Gemini key securely
• Validate the session token
• Reject invalid input
• Apply a system instruction
• Send the Gemini request
• Extract generated text
• Return usage information
• Report safe errors

Reusing that endpoint avoids creating several slightly different copies of the same connection logic.

Plans Using Image, PDF, or Structured JSON

This guided final project is intentionally a text-based business communication application.

A Lesson 9 plan may have selected a different configuration:

• Lesson 6 contains the structured JSON pattern.
• Lesson 7 contains the image-upload pattern.
• Lesson 8 contains the PDF-upload pattern.

Those features can be substituted into the same application structure without changing the central planning principles.

Test the Final Application

Run at least the following tests:

1. Submit the default message containing missing capitalization and punctuation.
2. Submit the price-and-deadline example and confirm that the facts remain unchanged.
3. Submit the incomplete-message example and check whether Gemini avoids inventing the missing information.
4. Clear the text area and attempt to submit an empty request.
5. Submit two requests too quickly and confirm that rate protection responds appropriately.
6. Copy one successful result.
7. Compare the result with the system instruction shown in the developer blueprint.

Signs That the Prototype Works

• The Lesson 9 plan loads
• The application name and purpose update
• The input limit is enforced
• The browser does not receive the API key
• The loading state appears during processing
• The output appears inside the result panel
• Errors appear without exposing private information
• The token counts update
• The result can be copied

What Would Come Next in a Real Product?

After the core application is tested, possible additions include:

• Server-stored application settings
• Approved tone controls
• Saved templates
• User generation history
• Database storage
• Additional output formats
• Administrative usage limits
• Subscription or credit controls
• Email or CRM integrations

Those should be added only after the core application produces dependable results.

Final Practical Exercise

1. Confirm that your Lesson 9 plan loaded.
2. Open the developer blueprint.
3. Review the system instruction.
4. Run the default message.
5. Run the price-and-deadline test.
6. Run the missing-information test.
7. Submit one original business message.
8. Copy a successful result.
9. Review the completed verification checklist.
10. Mark this lesson complete.

Final Course Summary

Gemini supplies the language and analysis capability, but the application determines how that capability is used.

A dependable application requires more than a good prompt. It needs a controlled interface, secure server connection, defined behavior, validated input, processed output, failure handling, usage controls, and a clear purpose.

You now understand the complete path from an application idea to a working Gemini-powered prototype.