From Prototype to Product

This was the point where the assistant stopped being a local experiment and started becoming a real system. Until now, everything had lived safely on my laptop – quick to build, easy to test, but ultimately isolated. The goal here was to give it a home: a managed, governed, and observable environment where it could run on its own, with the same discipline expected of any enterprise service.

I deployed the backend and Postgres database to Render Cloud, using a fully automated CI/CD pipeline that builds, tests, and deploys on every push to main. Secrets are handled securely, migrations apply automatically, and health checks verify every deployment. The result is repeatability – what once took hours and manual configuration now happens in minutes, the kind of velocity that makes controlled experimentation possible without losing reliability.

When the first HTTPS request to /api/health returned {“status”:”ok”}, it marked more than uptime – it proved the architecture could scale from a free Render tier today to a full enterprise environment tomorrow without changing its structure.

Of course, moving into production meant dealing with reality. Render’s managed Postgres enforced SSL connections, which immediately broke the async engine. Rather than patching it locally, I rewrote the session logic to detect when SSL is required and apply secure defaults automatically. I also refactored the Alembic migration flow to separate synchronous and asynchronous contexts – fixing the long-running MissingGreenlet issue that had shadowed earlier builds.

Now the platform runs the same way everywhere – local, CI, and cloud – predictable, observable, and ready to grow.

Strength and Awareness

Once the assistant was standing on its own two feet, I wanted to know how strong it really was. I ran the first full load test with Locust, simulating 100 concurrent users over two minutes, hammering /api/bookings, /api/sentiment, and /api/health. It handled over 8,000 requests with zero failures. Median latency sat at about a second, p95 just over two. On Render’s starter tier, that’s impressive – not because it’s fast, but because it’s consistent. Enterprises value predictability more than raw speed.

Those results are stored and versioned alongside the code. Each future release will build on that baseline, giving me a clear, data-driven way to track scalability instead of relying on instinct or anecdote. It’s a small but crucial part of building confidence in performance over time.

I also gave the system a way to see itself. A lightweight analytics middleware now records anonymous usage events – route, timestamp, and a salted session hash – but only once consent is granted. It’s the equivalent of giving the assistant a dashboard instead of a diary: aware of patterns but incapable of remembering individuals. Everything older than 90 days is automatically deleted by a scheduled job.

This isn’t analytics for vanity metrics; it’s operational insight for product decisions. Knowing which endpoints are used and when helps prioritise work and forecast load, while maintaining privacy by design. Governance isn’t a constraint here – it’s part of how the product earns trust.

Governance, Trust, and What Comes Next

The final focus of this phase was maturity – not just running code, but a governed, auditable service. I drafted a transparent Privacy Notice, updated the relevant architectural decision records, and documented every operational process: what’s logged, what’s not, and how retention is enforced.

These artefacts might not excite users, but they matter to customers, auditors, and future partners. Governance is part of the product story. It’s what turns “an AI that works” into “an AI you can trust.”

By the end of this phase, the assistant could:

• Run independently on Render Cloud with managed Postgres and persistent storage.
• Apply migrations and SSL configuration automatically.
• Pass every async and integration test in CI.
• Handle sustained load with zero failures.
• Record anonymised analytics with 90-day retention.
• Produce clear governance artefacts and privacy documentation.

It’s not yet visible on the blog – that’s next. The upcoming phase will publish the frontend as a static site, expose the embed widget, and preload an “About the Project” dataset so visitors can chat with it directly.

This stage wasn’t about visual polish or user flow; it was about stability, observability, and trust. The assistant now runs as a small, self-managing service – with the right safeguards, the right data discipline, and the right metrics to grow with confidence.

What comes next is visibility. The foundation is solid; the next step is letting people talk to it.