DEV Community: John Parkinson

How to Create an AI Chatbot from Scratch: A Step-by-Step Guide

John Parkinson — Tue, 29 Sep 2026 11:40:28 +0000

Most LLM-based chatbots follow the same pattern: a large language model (LLM) connected to a backend and grounded in company data. Once that pattern is clear, creating an AI chatbot from scratch is a matter of seven manageable steps.

This AI chatbot development guide explains how to create an AI chatbot stage by stage. It also works as an AI chatbot development tutorial for developers building their first production bot.

What Is an AI Chatbot and How Does It Work?

An AI chatbot is an application that holds a conversation with users in natural language. Each request travels through the following components:

User → Chat Interface → Backend → LLM → Knowledge/Tools → Response

First, the user types a message into the chat interface, which forwards it to the backend. The backend then attaches the system prompt and relevant documents before sending the full request to the LLM.

When the model needs information it cannot produce on its own, such as a current order status, it returns a tool call. The backend runs that tool and passes the result back, and only then does the final response reach the user.

How to Create an AI Chatbot from Scratch

The AI chatbot development process follows seven stages. Each stage produces a component that the next one relies on, so following them in order saves rework later.

1. Define the Chatbot's Purpose and Use Case

A reliable chatbot starts with one narrow job, such as order tracking or IT helpdesk requests. That focus matters because the use case defines everything downstream, from the data sources the bot needs to the way success is measured. Resolution rate and escalation rate work well as starting metrics.

For teams researching how to create an AI chatbot for business, this is also the moment to set the budget. Every additional use case adds integrations and test scenarios, so the cost grows with the scope.

2. Choose an AI Model and Development Approach

Developers can choose between two main model options. Hosted APIs, such as OpenAI's GPT models or Anthropic's Claude, offer the fastest start because there is no infrastructure to manage and pricing follows usage. Open-weight models like Meta's Llama or Mistral, on the other hand, run on private servers. That keeps sensitive data in-house but requires GPU capacity.

The development method depends on how much control the project needs. Frameworks such as LangChain or LlamaIndex give developers full control over custom code. Visual tools like n8n or Make suit smaller teams, because they allow simple workflows with little programming.

3. Build the Backend and Connect the LLM

The backend connects every other component. In a typical setup, it is a small API service, for example in Python with FastAPI, that passes messages between the interface and the model.

It also holds the system prompt, which defines the bot's role and sets clear limits on what it may discuss. In addition, it streams tokens back to the interface as they are generated, so users see the reply appear word by word.

Security starts at this layer as well, which is why API keys belong in environment variables or a secrets manager and never in client-side code.

4. Add a Knowledge Base

An LLM on its own has no access to a specific company's products or internal policies. To provide that knowledge, developers use retrieval-augmented generation (RAG), which adds relevant company content to each request.

The process starts with preparation. Company documents are split into smaller chunks, and an embedding model then indexes each chunk in a vector database such as pgvector or Pinecone.

Later, whenever a user asks a question, the backend searches that database for the most relevant chunks and adds them to the prompt. As a result, the model works from verified company content, which sharply reduces invented answers.

For the same reason, RAG appears among the core technologies of commercial AI chatbot development services, alongside hybrid AI and rule-based logic.

5. Add Memory and External Tools

Without memory, a chatbot treats every message as the start of a new conversation, so memory works on two levels.

Short-term memory passes recent messages back to the model with each new request. The n8n guide on AI chatbots, for example, describes a window buffer that stores the previous 5 to 20 interactions.

Long-term memory, by contrast, stores details such as user preferences in a database and loads them at the start of each session.

Tools, meanwhile, give the chatbot the ability to act. Through function calling, the model requests a named function, and the backend executes it on the model's behalf.

In customer support, this usually means connecting to CRM platforms and helpdesk software, which hold the customer and ticket data the bot depends on.

6. Create the Chat Interface

The chat interface is the only part users see, and it is typically a web widget or a messaging integration such as Slack.

Streaming output makes the conversation feel fast, and a visible handoff button reassures users that a person is available. Accessibility basics such as keyboard navigation apply as in any other web component.

7. Test, Deploy, and Improve

Testing starts before launch with a fixed set of real user questions and expected answers, which developers rerun after every prompt or model change.

Security testing belongs in the same routine, and prompt injection needs particular attention. The Open Worldwide Application Security Project (OWASP) ranks it as LLM01 in its 2025 Top 10 for LLM Applications.

After deployment, the focus moves to real traffic. Once the bot is live, logs of failed and escalated conversations show where the knowledge base or prompts fall short.

Best Practices for AI Chatbot Development

The practices below apply across every stage of AI chatbot development. Together, they form a practical checklist for building a bot and running it in production:

Start with one clear use case: A single task keeps the test set small and the success metric measurable.
Keep prompts focused: Short system prompts with explicit limits give more consistent output across conversations.
Use reliable and up-to-date knowledge: Outdated documents in the vector database produce outdated responses, so each source needs an owner and a review date.
Give the chatbot access only to necessary tools: OWASP lists excessive agency as LLM06:2025, so read-only access limits the damage from a manipulated prompt.
Provide fallback responses: A defined reply for unknown questions keeps the bot from inventing an answer.
Allow human escalation where needed: A handoff that carries the full transcript spares the agent from asking the same questions again.
Monitor conversations after deployment: A weekly review of low-rated and escalated chats shows which topics need new content.
Protect user data and API credentials: Personal data is masked before logging, and API keys are rotated on a fixed schedule.

Applied together, these practices keep the chatbot within its intended scope and make problems visible early.

Final Thoughts

The order of the seven steps matters when creating an AI chatbot, because each layer builds on the one before it.

A clear use case narrows the model choice, and the model choice in turn affects the backend and the knowledge base.

To create an AI chatbot for business use, the knowledge base and the escalation design need the most review time. Both directly affect what customers receive.

How to Develop a Smart Vending Machine Software from Scratch: A Step-by-Step Guide

John Parkinson — Tue, 15 Sep 2026 10:55:07 +0000

A smart vending machine carries two codebases. One is firmware in the vending machine controller, or VMC, and the other is a cloud platform that collects what the VMC reports. The steps below follow the order a working build takes: requirements, architecture, firmware, payments, telemetry, dashboard, and AI.

What Is Smart Vending Machine Software?

Smart vending machine software is the stack that controls machine hardware, processes cashless payments, and reports audit and health data to a server. On top of that, it gives operators remote control over a fleet from one interface.

Older vending machine software programs ran entirely as firmware on the VMC with no network connection. A connected system splits that work across a device layer and a cloud layer, and both sides hold state when the link drops.

Most builds contain the same components, and each one owns a distinct part of the transaction:

Machine control firmware. Runs the vend state machine, operates coils or locks, and reports success or failure for every selection.
Payment processing. Handles authorization, capture, and reversal through an MDB cashless device or a mobile app session.
Inventory management. Tracks stock against par levels, decrements on each successful vend, and reconciles counts after every restock.
IoT connectivity. Publishes telemetry to the cloud and queues messages locally while the machine is offline.
Cloud backend. Stores transactions, machine state, and planogram data, then exposes APIs to the dashboard and the app.
Operator dashboard. Shows fleet status, sales, and service tickets under role-based access.
Analytics and alerts. Converts raw telemetry into low-stock warnings, temperature excursions, and revenue reports.
AI features. Forecast demand, recognize products, and flag faults before a machine stops selling.

These components ship in stages, which is why treating them as one release delays the first working machine. Until firmware and the payment path run correctly on a single unit, the cloud services have nothing reliable to report.

How to Develop Smart Vending Machine Software

The build runs from the machine outward, because every layer depends on stable behavior in the one below it. A dashboard built on unreliable vend reporting therefore produces numbers no operator trusts, and the seven steps below follow that chain.

1. Define Requirements and Use Cases

Requirements start with the hardware and the business model, because both constrain every later decision. The following points therefore belong in writing before any architecture work begins:

Machine type. Spiral snack units, refrigerated cases, and locker systems each need a different dispensing model.
Product range and selection count. The number of coils sets how much planogram handling the firmware needs.
Payment methods. What the cashless device accepts at the machine, and what a mobile app adds on top.
Inventory accuracy. Coil counters against par levels, or sensor-based tracking through weight cells and RFID.
Customer interface. A keypad, a touchscreen, or a phone session, each with its own UI budget.
Remote management needs. Whether operators change prices, issue refunds, and push firmware without a site visit.
Fleet size. The machine count at launch and the target within two years, since backend cost scales with it.

Hardware settles several of these questions on its own. Your smart vending machine manufacturer lists the controller interfaces, sensors, and payment terminals available, and that sheet sets how much driver work remains.

2. Design the Software Architecture

The standard data path runs from the machine to the operator in five hops:

Machine → Sensors/Controller → Internet/IoT → Cloud Backend → Management Dashboard

The VMC holds the authoritative state of the machine, since it is the only component that knows whether a product physically moved. An IoT module publishes its sensor readings upstream over MQTT or HTTPS, after which the backend stores each event.

Intermittent connectivity belongs in the design from day one, so firmware needs a local queue that replays transactions once the link returns. Every event also needs an idempotency key written at the machine, because replays otherwise create duplicate sales records.

3. Build the Machine Control Layer

The control layer turns a customer selection into a dispensed product and a recorded transaction. Most machines expose it through MDB/ICP, the NAMA and EVA standard whose version 4.2 defines a 9600 baud master-slave bus.

Within that structure, firmware at this layer handles:

Product selection. Maps keypad or screen input to a coil and pulls the price from the planogram.
Motor and spiral control. Controls the dispensing motor, with current monitoring that exposes a stall.
Dispense confirmation. Reads a drop sensor or a weight change before the sale counts as complete.
Door and lock control. Governs refrigerated and grab-and-go units where the customer opens the cabinet.
Sensor readings. Collects temperature, door state, and coil occupancy on a fixed cycle.
Error detection. Writes persistent fault codes per coil, so a failing motor shows up as a pattern.
Transaction status. Reports the outcome to the cashless device and to the cloud queue.

All of that works best as an explicit state machine with a timeout on every state. Without those timeouts, a vend that stalls between approval and dispense costs an operator both product and customer trust.

4. Integrate Cashless Payments

Credit card vending machine software rarely touches card data directly. The reader encrypts it under a point-to-point encryption scheme, and the processor returns a token that keeps account numbers out of your backend.

Payment coverage also accounts for most of the revenue at the machine. Cashless transactions made up 71% of US vending sales in 2024, and 77% of those were contactless, according to Cantaloupe's 2025 Micropayment Trends Report. The integration accordingly covers:

Credit and debit cards. Chip and PIN or swipe transactions handled entirely by the terminal.
NFC and contactless. Taps from cards, phones, and watches through the contactless EMV kernel.
Mobile wallets. Apple Pay and Google Pay sessions running across the same reader.
QR payments. A code on the machine that opens a purchase session inside the operator's app.
Payment authorization. A hold placed on the amount before the coil turns.
Transaction confirmation. Capture that follows the vend success message from the VMC.

MDB runs cashless payments as a session, where the terminal authorizes an amount and capture follows only on a confirmed dispense. Failed vends consequently need an automatic reversal path, since a manual refund at an unattended machine costs a service call.

Security rules at this layer are external and non-negotiable. PCI DSS v4.0.1 is the active version, and its 51 future-dated requirements from v4.0 took effect on 31 March 2025.

5. Add Inventory and IoT Monitoring

Vending machine inventory software exists to remove restocking visits made without stock data. Every successful vend decrements a coil counter, and every restock refills that coil to par, the minimum quantity NAMA's glossary sets per spiral.

Against that baseline, the telemetry stream typically carries:

Stock levels. Counts per coil, measured against the par level set in the planogram.
Sales events. Timestamp, price, and payment method for each completed transaction.
Temperature. Readings at fixed intervals for chilled and frozen units, stored as a continuous log.
Machine health. Motor faults, bill validator status, and door cycles since the last service visit.
Connectivity. Online state plus a last-seen timestamp for every machine in the fleet.
Low-stock alerts. Notifications triggered on days of supply, before a coil empties.

That data also has an established transport format worth reusing. EVA-DTS moves the DEX audit file the VMC generates, and its version 6.1.2 replaced 6.1.1 as the current release.

6. Build a Cloud Management Dashboard

Vending machine management software is where operators spend their working day, so the dashboard has to answer service questions on one screen. Within that screen, the data works best grouped by the decision it supports, since database tables rarely map to the questions a route manager asks.

On that principle, an operator dashboard usually shows:

Machine status. Online or offline, together with the reason for the last disconnect.
Inventory. Current stock per machine and per coil, sorted by days of supply.
Sales. Volume by product, machine, and period.
Revenue. Totals with a payment-method breakdown for reconciliation.
Alerts. Open issues sorted by severity and age.
Transaction history. A searchable log for refund disputes and chargebacks.
Machine locations. A map view grouped by service route.
Restocking requirements. A pick list per vehicle, generated for pre-kitting before the driver loads.

Role-based access belongs in the same release, since a route driver needs stock and location data, whereas a finance user needs transaction records. Separating those roles later means reworking every API endpoint already shipped.

7. Add AI and Automation

Vending machine AI software becomes useful once several months of clean transaction data exist. Before that point, models trained on thin or inconsistent data produce forecasts that operators override, after which the feature goes unused for good.

Once that history is in place, proven applications include:

Demand forecasting. Sales velocity per coil, per location, and per weekday.
Product recommendations. Suggestions in the mobile app based on purchase history.
Predictive maintenance. Warnings built from motor current draw and door cycle counts.
Anomaly detection. Flags on transaction patterns that point to theft or a stuck sensor.
Dynamic pricing. Price changes are tied to stock levels and expiry dates.

Those techniques also cover open-door machines, where computer vision and weight sensing charge a customer for whatever they remove. Since that model depends on accurate item recognition, it performs best with distinct packaging and calibrated shelves.

Test and Secure the Software

Failure paths deserve testing first, because vending faults occur in the field with no staff present. For that work, a bench rig with a real VMC and a test terminal makes each of the following scenarios reproducible:

Payment failures. Declines and timeouts that land mid-authorization.
Incorrect dispensing. A double drop or an empty coil rotation.
Network interruptions. A dropped connection during an open session.
Empty coils. A selection the counter already shows as sold out.
Sensor failures. Readings outside the physical range of the sensor.
Duplicate transactions. Repeated records created by a replayed offline queue.
Incorrect inventory data. Counts left wrong after a partial restock.

Each of these needs a defined recovery action, and that action then has to reach the operator's alert feed. Without that feed, silent recovery looks clean in testing and hides recurring hardware faults until a machine stops selling.

Security review runs afterwards as a separate pass with its own checklist:

Encrypted communications. TLS everywhere, with certificate pinning on the device.
Secure payment processing. A tokenizing terminal that keeps card data outside your systems.
Authentication. Verification on every API call, using short-lived device credentials.
Role-based access. Separate permission sets for operator, technician, and finance accounts.
Secure remote updates. Signed OTA packages the device verifies before installation.

Firmware updates deserve particular attention, so an A/B partition scheme with automatic rollback protects the fleet. A failed update on a remote machine otherwise means a service visit and lost sales.

Deploy, Monitor, and Improve

Deployment follows a fixed sequence, and each stage has its own exit condition:

Prototype → Test machine → Pilot deployment → Collect data → Optimize → Scale to fleet

The prototype proves the vend cycle on a bench, after which the test machine runs the full stack under supervision. A pilot of 3 to 5 machines in customer locations then exposes connectivity and restocking problems that bench testing never reaches.

Data from that pilot sets the baseline, where vend success rate, payment decline rate, and stock-out hours per machine are the numbers worth watching. Firmware afterwards rolls to the fleet in waves, with the first wave small enough to reverse in an afternoon.

What Does a Smart Vending Software MVP Need?

An MVP needs enough scope to sell products reliably and to tell an operator what happened. The rest can wait for the second release without costing a single sale.

In practice, the minimum viable build covers:

Machine control. A complete vend state machine with timeouts and fault codes.
Cashless payments. One processor, one MDB cashless device, and a working reversal path.
Inventory. Coil counters with par levels and restock reconciliation.
Cloud backend. Storage for transactions and machine state, plus an API for the dashboard.
Operator dashboard. Status, sales, and stock in one view.
Alerts. Notifications for offline machines, faults, and low stock.

Loyalty programs, dynamic pricing, and demand forecasting all depend on transaction history, so they belong in later releases by definition. Until then, a limited first deployment keeps the feedback loop short, and the roadmap follows real sales data.

Final Thoughts

Smart vending machine software depends on discipline at the lowest layer, because accurate vend reporting is what makes inventory and forecasts usable. Hardware selection therefore belongs at the front of the project. Controller interfaces and the cashless device on the bus set the limits of what the software can do.