Building systems.
Growing people.
Understanding business.

Business workflows

The manufacturing variant adds bills of quantities (BOQ), production management, and quality control. The trading variant shares the rest of the platform without those manufacturing-specific functions. The products connect everyday operations with production planning, inventory, orders, procurement, commerce integrations, and payment reconciliation.

• Enquiry-to-cash workflows: leads, follow-ups, quotations, customer orders, procurement, dispatch, invoices, and payments.
• Inventory and purchasing: batch stock, purchase prices, freight costs, supplier quotations, and material traceability.
• Finance and Indian tax workflows: invoice-specific payment matching, aging, GST, ITC reconciliation, RCM, TDS, and TCS.
• Role-specific workspaces, audit trails, attendance-linked payroll, and integrations including IndiaMART, WhatsApp, APIs, and webhooks.

Architecture and cost decisions

V1 was developed before our AI-assisted development workflow: the Express.js backend and React frontend were written by engineers. Firestore’s flexible schema supported the data model. I deliberately placed much of the computation in the browser, while retaining data consistency and authorization responsibilities on the service side.

That division allowed the service to run as cloud functions, using client computing resources to reduce backend work and keep operating costs lower as the product scaled. The approach came from designing for the economics of an MSME product, alongside its functional requirements.

Adoption and next version

Businesses use the product today. One tenant has approximately 50 employees running their day-to-day activities on the application. The 13-person Intoin team maintains this product alongside the company’s other software; it is not a dedicated 13-person ERP team.

V2 is currently under design with an AI-first and mobile-first direction. Those capabilities describe the next version’s design goals rather than features already delivered in V1.

Privacy as an architectural constraint

Transaction processing happens on the device to reduce the risk of exposing personally identifiable financial information. Only category-level totals are stored in the cloud. The application uses Firestore and Firebase Authentication without a separate custom backend service.

Extensible SMS interpretation

The transaction pipeline has two layers: heuristic scoring identifies relevant messages, then parsing extracts transaction information. The design accommodates SMS formats from multiple banks and allows additional formats to be added without rebuilding the entire processing approach.

Agent and employee collaboration

The Python backend runs the agent. A React/TypeScript frontend lets tenants configure their business and asset information. A Flutter phone application lets tenant employees answer the agent’s questions, supply missing information, and take over a customer conversation.

The agent works from dealership knowledge, responds in the lead’s language, helps book showroom visits, and hands leads to staff. Sarvam AI models support Indian-language conversations, especially Hinglish.

• The product website describes onboarding from model details, prices, offers, showroom information, and reviewed brochure PDFs.
• Its sales workflow includes Google Calendar visit/test-ride bookings, lead briefs for staff, and Hot/Warm/Cold lead classification with reasons.
• Unknown answers can be escalated to people, with staff assignment and conversation takeover connecting the agent to the dealership’s sales process.

Delivery stage

The proof of concept is deployed and being used by three dealerships. Moving to production V1 is the next step; the POC’s adoption is distinct from a completed V1 launch.

Five perspectives on a website

Google ADK orchestrates five specialist agents alongside PageSpeed information. The product presents UX, SEO, conversion, technical architecture, and competitive benchmarking perspectives, combining them into recommendations a business can act on.

• UX: navigation, cognitive load, accessibility, contrast, and mobile usability.
• SEO: metadata, heading structure, semantic HTML, and discoverability.
• Conversion: copy, calls to action, clarity, and trust signals.
• Technical performance: website performance evidence and implementation concerns.
• Benchmarking: comparison with relevant website and industry patterns.

Access, deployment, and commercial delivery

The TypeScript backend and React frontend are deployed on GCP using services including Firestore and Cloud Storage. The architecture does not require user authentication: stored data is accessible to the backend service account, with results shared with users for a limited time. Razorpay processes payments.

The public offering includes a free homepage check and a paid deeper audit with multi-page analysis, device-specific review, code suggestions, and a PDF roadmap. The product has generated revenue from approximately 164 paid audits.

Provider-independent agent architecture

The Python service is a reusable Voice AI agent. It supports OpenAI Realtime, Gemini Live, and Grok realtime models, as well as speech-to-text and text-to-speech models from ElevenLabs, OpenAI, and Gemini. Provider-specific implementation sits behind interfaces; communication, prompts, tools, MCP integration, and lifecycle behavior are shared.

Callers can configure the model and transport independently. Each provider or channel needs its own adapter, while the shared implementation handles the relevant lifecycle events uniformly. The same architecture also supports text and WhatsApp conversations. Tenant-information MCP servers connect business context natively to the agent.

Channels and real-time operation

Voice transports include Twilio SIP, WebSocket connections through Twilio and FreJun, and browser WebSockets for demonstrations and testing. Twilio serves the US market; FreJun serves the Indian market.

The design coordinates asynchronous work, concurrency, resource management, failures, and long-running calls with the state shown to users. Server-sent events (SSE) refresh the client application. A dedicated call-handling module uses Redis and BullMQ for missed or failed calls according to tenant settings. Incoming-call workflows can continue through SMS or WhatsApp.

Application services and product surfaces

Two TypeScript application backends surround the Python agent. The receptionist service manages business data, appointments, multi-user access, and reports, with a React frontend. The campaign service manages business information, campaign goals, assets, contacts, scheduling through BullMQ and Redis, and external integrations through Zapier, with a Next.js frontend.

The campaign backend also serves the Flutter B2C Goal Manager application. Sharing infrastructure and clear interfaces lets product surfaces evolve without duplicating the agent implementation. A dual-mode service layer enabled frontend development to progress alongside backend work.

Multi-tenancy, deployment, and build-versus-buy

PostgreSQL stores tenant data with row-level security guards. Firestore stores dynamic information such as transcripts and call analysis, with Firebase Authentication. REST APIs use bearer tokens. Backend services run on GCP Cloud Run, frontends use Firebase Hosting, and Redis/BullMQ are deployed on GCP.

I directed vendor and build-versus-buy decisions: existing business-search data instead of building a proprietary index, backend ownership of conversational logic, and Stripe for subscriptions. The business data model accommodates multiple verticals, including veterinary clinics and appointment-driven businesses. Schema-driven onboarding can populate a business profile from its website.

Hiring and building independent ownership

I hired a separate five-person team, targeting engineers with roughly one to three years of experience and strong theoretical foundations, including people without prior experience in the chosen technologies. I trained them to use AI coding tools effectively and supported their work through mentorship, code review, and performance management.

Strict module interfaces divided the architecture into areas that engineers could understand and own independently. This approach supported cost-effective hiring and delivery while making day-to-day ownership manageable for the team. Handover was part of the engagement, which ended in September 2026.

AI-assisted delivery with explicit guardrails

I designed the development agents and process using my experience with Microsoft engineering standards. The workflow begins with understanding the problem and agreeing on the implementation, then uses AI-assisted execution, test-driven development, code review, and security review.

AGENTS.md instructions were integrated into the Claude development workflow through CLAUDE.md. Review-agent approval was required before opening a pull request. Human review was mandatory, and agents could not merge to the main branch. End-to-end automation, error-handling standards, and CI-based mobile releases supported delivery.

The review process added execution time, but in my experience still delivered faster than manual coding. AI assistance was paired with verification and human judgment; it was not treated as a substitute for them.

Measured engineering results

• Load testing handled up to 50 concurrent live, end-to-end calls through Twilio with multiple AI models. This is a test result, not a claim about ongoing production traffic.
• The optimized tested call cost was approximately US $0.05–$0.06 per minute, including all costs. It describes the tested setup, not a universal price for every provider or configuration.
• Reported branch coverage was 93% for unit tests and 81% for end-to-end tests, measured using Node and pytest test infrastructure.
• The engagement progressed from POC to production V1 and concluded with ownership handed over to the team. I do not have access to subsequent production usage data.

What the product enables

The public product site positions the receptionist for businesses including veterinary and medical practices, real estate, hotels, dealerships, and home services. It describes multilingual conversations, reminders, summaries, analytics, and connections to business systems. These explain the product context; the engagement and test results above describe my delivery scope.

• Business onboarding and context configuration across SME verticals.
• Incoming customer conversations, appointment/calendar management, and existing phone-system integrations.
• Searchable call history, transcripts, call analysis, reports, and multi-user access.
• Subscription billing and SMS/WhatsApp continuation for non-voice interactions.

What the product enables

• Business information, campaign goals, asset information, contact lists, and call scripts.
• Scheduled outbound campaigns with configurable AI models and tenant-aware calling behavior.
• Live progress, call outcomes, dashboards, and reporting.
• External workflow integrations through Zapier.

What the product enables

• A typed request becomes an AI-assisted phone call to a discovered business or one of the user’s contacts.
• Real-time queued, in-progress, and completed states keep the user informed.
• Call recordings and summaries report what happened and what was learned.
• Secure sign-in, notifications, and subscription plans support the end-to-end mobile experience.

Engineering and customer support

BITS had a large installed base and substantial customer feedback. Alongside feature development, I worked on root-cause investigations and customer support, including fixes for older Windows releases. Implementation details behind the throughput improvement remain confidential.

Peer feedback describes me as a go-to engineer for BITS, able to investigate issues promptly, help colleagues, keep QA involved, and communicate breaking changes. The work required reasoning about concurrency, failure behavior, compatibility, and the verification cost of changing a long-lived system service.

Standards and cross-functional ownership

Microsoft describes DAL as a CIM/WS-MAN management abstraction with task-oriented operations for heterogeneous hardware, including power, boot, firmware, inventory, and management-controller logs. This gives operators a consistent management surface across underlying device protocols.

The work included published protocols that we implemented and protocols published by Microsoft based on DAL. Existing peer feedback names IPMI, RMCP+, SOL, and WinDBC implementation, alongside Applied CIM expertise, standard schema implementation, and profile management.

Alex Bass’s feedback describes my contributions across architect, developer, tester, and program-manager responsibilities during the project lifecycle. This was technical and cross-functional ownership within an individual-contributor role.

System behavior and design responsibilities

Quota management addressed resource consumption by remote work. RunAs delegation addressed executing delegated tasks with the appropriate access. My responsibility combined system design with implementation, compatibility considerations, and collaboration around testing.

Microsoft documentation describes the product’s resource limits and remote-management behavior; those references establish product context, while the contribution above describes the work I personally owned.

Adoption and use

The tool visualized code churn alongside coverage and supported bug triage, codebase stabilization, and release-readiness assessment. Its adoption scope is my organization, rather than the entire Windows division. It was internal software; there is no public artifact or adoption report.