20 QUESTIONS
Data, security and the technical detail.
Where your data actually sits, who has access to it, and what happens to the conversations an AI agent has with your customers. Plus hosting, backups, and what breaks if a provider goes down.
All 20 questions
In your own accounts wherever practical: your own database instance, your own AI provider account, your own hosting. The goal is that you control your own data, not that it lives locked inside a system only I can access.
Since accounts and infrastructure run under your own ownership wherever practical, your data stays exactly where it was. Nothing is deleted or held hostage because the working relationship ends.
No. AI processing goes through providers' standard business APIs, not consumer chat products, and standard API usage is not used by those providers to train their models.
Standard secure development practices are followed: parameterized queries to prevent injection, authenticated and session-protected admin access, and secrets kept out of source code. Specific compliance certifications can be discussed if your industry requires them.
PostgreSQL, a mature, widely used relational database, rather than something exotic or unproven. For projects needing a backend, this is the default.
It is written in standard, current technologies like Next.js, TypeScript, and React, documented at handover, so any competent developer can pick it up later. Nothing is deliberately obfuscated to create lock-in.
For projects with real infrastructure, backup strategy is discussed as part of the technical scope, especially for anything holding data that would be costly to lose.
It gets addressed directly and promptly. If you are on an ongoing support arrangement, this is covered under that. If not, it is treated as urgent, priority work regardless.
Sensitive data, like passwords and session tokens, is never stored in plain text. Encryption and hashing are applied appropriately based on what the data actually is and how it is used.
If the tool has an API, integration is generally possible and gets scoped like any other technical requirement.
This is a real dependency worth being upfront about. Because the underlying architecture is not deeply locked to one specific provider's proprietary format, switching providers is usually possible, though it does involve real engineering work, not a one-click swap.
Yes, projects go through verification, functional checks, and manual testing appropriate to the scope before being considered done, not just a visual glance before handover.
Session-based authentication with signed tokens is standard, and for higher-security needs, additional measures can be discussed and built in.
AI features like a chatbot typically run as a separate, asynchronous process from the core site, so they do not block or slow down normal page loading.
Yes, data migration from an existing platform or spreadsheet into a new system is a common part of a rebuild or automation project, and gets scoped based on how clean the existing data actually is.
A combination of type-checked code, linting, and manual verification before anything ships, rather than pushing straight from a local machine to a live site with no checks.
Modern managed hosting platforms used for these builds are designed for production traffic and include automatic scaling and uptime handling well beyond what a self-managed server typically offers.
Yes, monitoring and alerting can be set up so a failure surfaces as a notification rather than being discovered when a customer complains.
TypeScript and JavaScript across the stack, with Next.js and React on the frontend and Node on the backend, plus the relevant automation platforms like n8n for workflow-specific work.
If your project includes a backend with an API, yes, and it can be documented so your own developers, current or future, can build against it.