AI Receptionist Dashboard
One month to build the dashboard foundation, backend, database, auth, and marketing site for an AI receptionist product — with the AI layer being built separately and not yet integrated.
Businesses running customer support around the clock need staff availability that doesn't scale economically. The product's proposition was an AI receptionist capable of handling support interactions 24/7 without a human in the loop — reducing the cost and coverage constraints of traditional support operations.
The product needed a dashboard for businesses to configure, monitor, and manage their AI receptionist. That dashboard needed a backend, a database, authentication, and a public-facing marketing site — all before the AI layer was ready to be integrated.
02 / DecisionsBuilding the frontend without designs
No design files existed at the start of the engagement. The dashboard UI was built from product intuition and observation of similar SaaS products — what information a business operator would need, how configuration panels typically behave, what a monitoring interface should surface. The constraint made scope decisions sharper: build what is unambiguously needed, leave extensibility for what isn't clear yet.
Designing the database without the AI integration
The AI layer was being built in a separate repository by the CEO in parallel. The two would eventually need to integrate — but during this engagement, the shape of that integration was not fully defined. Database design decisions had to be made without knowing exactly what data the AI layer would produce or consume.
The approach was to design for the known surface — business accounts, configuration, auth, conversation records at the structural level — and keep the schema extensible at the boundaries where the AI integration would eventually connect. Avoiding premature coupling to an unspecified integration while still building something the integration could attach to cleanly.
Scoping a one-month engagement
A one-month timeline for a full product foundation requires active scope decisions. The marketing site was an immediate business need — it went in. The AI integration was not ready — it stayed out. The dashboard was built as a working product, not a prototype: real auth, real data models, deployable serverless backend. The handoff had to leave something another developer could continue building on without needing to understand decisions that weren't documented.
The primary constraint was building a coherent data model for a product whose core feature — the AI — was being developed in parallel and couldn't be fully specced against. Every schema decision at the AI boundary carried uncertainty. Too tight a coupling and the integration would require migrations. Too loose and the handoff would leave the next developer with a gap they'd have to bridge.
The other constraint was timeline. One month is enough to build a foundation if scope is managed tightly. It is not enough to revisit architectural decisions. Getting the core data model and backend structure right in the first pass mattered more than usual.
04 / OutcomeA working dashboard with authentication, a serverless backend, a database foundation, and a marketing site — handed off within the month. The product is live. The AI integration that was in parallel development during this engagement has since been completed by the team that continued after this engagement ended.