What Is Prompt Engineering? A Plain-English Guide
TL;DR
Prompt engineering is the skill of writing clear, specific instructions that get an AI to produce what you want. It works because AI responds to what you write, not what you mean. The core techniques — give a role, be specific, add context, specify the format — are learnable by anyone.
What Is Prompt Engineering? A Plain-English Guide
Prompt engineering is the skill of writing clear, well-structured instructions that get an AI model to give you the result you actually want. In plain terms: it is the difference between typing "write something about our product" and getting vague fluff, versus giving the AI the right context and direction and getting something genuinely useful. The same AI model can produce a poor answer or an excellent one depending entirely on how you ask, and prompt engineering is the craft of asking well.
Here is why this matters more than it sounds. AI models like ChatGPT and Claude are extremely capable, but they are not mind readers. They respond to what you actually wrote, not what you meant. Most disappointing AI results are not the model failing; they are unclear instructions. Prompt engineering fixes that, and the good news is that it is a learnable skill, not a technical one. You do not need to code to be good at it.
This guide explains what prompt engineering is, why it works, the core techniques anyone can use, and where it goes next, no technical background required.
The quick answer: prompt engineering in one minute
If you remember nothing else, remember this.
Prompt engineering is writing instructions that get an AI to produce what you want. A "prompt" is simply what you type to the AI, your question, instruction, or request. Engineering it means crafting that input deliberately, with clear context and direction, instead of typing the first thing that comes to mind.
It works because AI responds to specifics. The more clearly you tell it who it should act as, what you want, in what format, and with what context, the better its answer. Vague in, vague out; specific in, useful out.
And it is learnable by anyone. The core techniques are about clear thinking and clear communication, not code. If you can write a clear brief for a colleague, you can learn to write a good prompt.
What prompt engineering actually is
Let us define it properly, without the jargon.
A prompt is the text you give an AI model, the question you ask, the instruction you write, the task you set. Prompt engineering is the practice of designing that text deliberately so the AI gives you the best possible result. It ranges from simple everyday improvements, adding context to a request, to advanced techniques used by professionals building AI products.
The key insight is that an AI model does not have a fixed "quality." Its output quality depends heavily on the prompt. Give a capable model a vague prompt and you get a vague answer; give the same model a clear, well-structured prompt and you get a sharp, useful one. The model did not change, your instruction did. Prompt engineering is simply learning to write the instruction that unlocks the good answer, and understanding how AI models work makes it click, since they predict a response based on your input, so a better input steers a better prediction.
Why prompt engineering works
You do not need the technical details, but the reason it works is worth understanding, because it makes the techniques obvious.
An AI model generates its response based entirely on the text you give it plus the patterns it learned in training. It has no idea what is in your head, only what is on the screen. So everything it needs to give a good answer, the context, the goal, the format, the tone, has to be in your prompt. When people get bad results, it is usually because they left out something the AI needed, assumed it knew context it did not have, or were vague where they should have been specific.
This is why prompt engineering works: by putting the right information and direction into the prompt, you give the model what it needs to produce what you want. You are not tricking the AI. You are communicating clearly with something that can only respond to what you actually say. Every technique below is just a specific way of being clearer.
The core techniques anyone can use
You do not need to be technical to write much better prompts. These few techniques do most of the work.
Give it a role. Telling the AI who to be focuses its answer. "You are an experienced financial advisor" produces a different, more targeted response than no role at all. A clear role anchors the tone and expertise.
Be specific about what you want. Vague requests get vague answers. Instead of "write about marketing," try "write three subject lines for an email to small-business owners about our accounting tool." The more specific the ask, the more useful the result.
Give context. The AI only knows what you tell it. Include the relevant background, who it is for, what you are trying to achieve, any constraints. Context is the single biggest lever most people ignore.
Specify the format. Tell it how you want the answer: a bulleted list, a short paragraph, a table, a specific length. If you do not specify, you get whatever the model defaults to, which may not be what you need.
Show an example. If you want something in a particular style or structure, show one example of it. Models learn powerfully from examples, and one good example often beats a paragraph of description.
Ask it to think step by step. For anything involving reasoning or multiple steps, telling the AI to work through it step by step noticeably improves the quality and accuracy of the answer.
Iterate. Your first prompt rarely gets the perfect result. Treat it as a conversation: see what you get, then refine your instruction. Prompt engineering is often less about the perfect first prompt and more about improving quickly.
Simple prompt versus engineered prompt
The difference is easiest to see with an example.
A weak prompt: "Write a product description for my candle." The AI has nothing to work with, so it produces something generic that could describe any candle.
An engineered prompt: "You are a copywriter for a premium home brand. Write a 60-word product description for a hand-poured lavender soy candle aimed at people who want to relax after work. Warm, calming tone. Focus on the scent and the feeling, not the ingredients." Now the AI has a role, a length, an audience, a tone, and a focus, and it produces something genuinely usable.
Same model, completely different result. That gap, from generic to genuinely useful, is what prompt engineering delivers, and it comes entirely from putting the right direction into the prompt.
Where prompt engineering goes next
Everyday prompt engineering, the techniques above, is a skill anyone can use to get more out of AI tools. But it also has a professional, technical end.
When businesses build AI products, prompt engineering becomes a core engineering discipline. The instructions that guide an AI feature, a support assistant, a content tool, an AI agent, are carefully engineered, tested, and refined, because in a product the prompt has to work reliably across thousands of different inputs, not just once. This is especially true for AI agents, software that acts on its own, where the prompt is effectively the operating manual that governs the agent's behavior, and writing a good prompt for an AI agent is its own deeper skill.
So prompt engineering spans a wide range: from a small-business owner writing a better request to ChatGPT, to an engineering team crafting the prompts inside a production AI system. The core principle is the same at both ends, clear, specific, well-structured instructions get better results, but the stakes and the rigor grow as the AI does more.
Ready to get more out of AI?
Prompt engineering is one of the highest-return skills for anyone using AI, because it costs nothing to learn and dramatically improves what you get out of every AI tool. Start with the basics, give a role, be specific, add context, specify the format, and you will immediately see better results. As your needs grow, so can your prompts.
When prompt engineering becomes part of a real product, an AI feature or agent that has to work reliably at scale, the Craxinno team builds and engineers those systems properly. See recent AI work in the Craxinno portfolio, explore our AI development service, or email sales@craxinno.com.
Frequently Asked Questions
What is prompt engineering in simple terms?+
Prompt engineering is the skill of writing clear, well-structured instructions that get an AI model to give you the result you want. A "prompt" is what you type to the AI, your question or request, and engineering it means crafting that input deliberately, with the right context and direction, instead of typing the first thing that comes to mind. The same model gives better answers to better-written prompts.
Why does prompt engineering matter?+
Because AI models respond to what you actually write, not what you mean. They are capable but not mind readers, so most disappointing AI results come from unclear instructions rather than model limitations. Prompt engineering fixes that by putting the context, goal, and direction the AI needs into the prompt, which turns vague, generic answers into sharp, useful ones from the exact same model.
Do I need to be technical to learn prompt engineering?+
No. The core techniques are about clear thinking and clear communication, not coding. If you can write a clear brief for a colleague, you can learn to write a good prompt. Techniques like giving the AI a role, being specific, adding context, and specifying the format are usable by anyone. Prompt engineering only becomes technical at the professional level of building AI products.
What are the basic prompt engineering techniques?+
The most useful techniques anyone can use are: give the AI a role ("you are an experienced copywriter"), be specific about what you want, provide relevant context, specify the format you want the answer in, show an example of the style or structure, ask it to think step by step for complex tasks, and iterate by refining your prompt based on the results. These few techniques do most of the work.
What is the difference between prompt engineering and prompting an AI agent?+
Everyday prompt engineering is writing better instructions to get good results from an AI tool. Prompting an AI agent is a more advanced, specific application: because an agent acts on its own across multiple steps and tools, its prompt functions as an operating manual that must define roles, boundaries, and tool usage, and work reliably across many situations. It is prompt engineering applied to autonomous software, with higher stakes and more rigor.
Building something with AI?
We ship production AI — agents, RAG pipelines and LLM integrations that survive real users, not demos.
Start a projectKeep ReadingMore case studies like this
Engineering retros, product launches, and brand systems from our studio — updated monthly.
All case studiesTechnology Used
.svg){kind=logo}
Node.js
TypeScript.svg){kind=logo}
ClaudeTags & Keywords
Continue with Blogs.
View all blogs
OpenAI APIHow to Build a Chatbot with the OpenAI API: Step-by-Step Python Tutorial
How to Build a Chatbot with the OpenAI API: Step-by-Step Python Tutorial Quick answer: To build a chatbot with the OpenAI API, install the openai Python SDK, save your API key in an environment variable, and send each user message to client.responses.create() with your system prompt in instructions . Pass the previous reply's ID back as previous_response_id so the bot remembers the conversation, then stream the output to a web page through a small backend. That's the whole idea. The rest of this tutorial turns it into code you can run in about 20 minutes. One warning first. Search "OpenAI chatbot tutorial" and a good share of the top results still call openai.ChatCompletion.create() . That function was removed when the Python SDK hit version 1.0 back in November 2023, and the SDK is on version 3.29 as of October 2026. Copy that code today and you get an error before your bot says hello. Everything below is written against the current Responses API and tested on openai 3.29.0. What you'll build A support assistant called Ava for a made-up coffee subscription brand, Brewly. By the end you'll have: A terminal chatbot that streams replies word by word and remembers earlier messages. A FastAPI backend that keeps your API key off the browser. A plain HTML chat page that talks to that backend. A clear idea of what each conversation costs you. Python 3.9 or newer and an OpenAI account with billing enabled are all you need. No frameworks like LangChain. You'll understand every line, which matters the first time something breaks in production. Responses API vs Chat Completions vs Assistants: which one? OpenAI has three APIs that can power a chatbot, and older tutorials mix them up. API Status (Oct 2026) Who manages conversation history Use it for Responses API Recommended for all new projects You, or OpenAI via previous_response_id / Conversations New chatbots and agents Chat Completions Still supported You (resend the messages array) Existing apps you don't want to migrate yet Assistants API Listed under legacy APIs OpenAI (threads) Nothing new OpenAI's own migration guide says Responses is "recommended for all new projects," and reports 40–80% better cache utilization than Chat Completions in internal tests. Better cache hits mean lower bills on long chats, which is reason enough for a chatbot. So this tutorial uses the Responses API throughout. Step 1: Set up the project and your API key Create a folder, a virtual environment and install four packages: 1 2 3 4 mkdir openai - chatbot && cd openai - chatbot python - m venv . venv source . venv / bin / activate # Windows : . venv\Scripts\activate pip install openai python - dotenv fastapi uvicorn Generate a key at platform.openai.com → API keys , then create a .env file in the project folder: 1 2 OPENAI_API_KEY = sk - proj - your - key - here OPENAI_MODEL = gpt - 6 - luna Add .env to .gitignore right now, before your first commit. Leaked keys get scraped from public GitHub repos within minutes, and the bill lands on your account. What goes wrong here: if you see OpenAIError: Missing credentials. Please pass an api_key... , the SDK can't find the variable. Check that load_dotenv() runs before OpenAI() is created and that you started Python from the folder containing .env . Step 2: Send your first request Create hello.py : 1 2 3 4 5 6 7 8 9 from dotenv import load_dotenv from openai import OpenAI load_dotenv ( ) client = OpenAI ( ) # reads OPENAI_API_KEY from the environment response = client . responses . create ( model = "gpt-6-luna" , input = "Explain what an API key is in one sentence." , ) print ( response . output_text ) Run python hello.py . If a sentence comes back, your account, key and billing all work. response.output_text is a convenience property that joins all the text the model produced. The full response.output list also holds reasoning items and tool calls, which you'll need later for memory. Which model should a chatbot use? These are the current text models and their prices per 1 million tokens, from OpenAI's models page: Model Input Output Good for gpt-6-luna $0.10 $0.50 FAQ and support bots, high volume, fastest replies gpt-6.1-sol $2 $10 Bots that need to reason over policies, data or code gpt-6-astra $10 $50 Hard, high-value queries where accuracy beats cost Our take: start every chatbot on Luna. Most customer-facing questions ("where's my order?", "can I change my plan?") don't need a frontier model, and Luna costs 1/20th of Sol. Upgrade only the conversations that need it. Because the model name lives in .env , switching is a one-line change. Step 3: Give the bot a personality and rules with a system prompt Without instructions, the model answers anything about anything. A support bot needs a job description. In the Responses API, that goes in the instructions parameter: 1 2 3 4 5 6 7 8 9 10 11 SYSTEM_PROMPT = """You are Ava, the support assistant for Brewly, an online coffee subscription. - Only answer questions about orders, subscriptions, shipping and coffee. - Keep replies under 80 words unless the user asks for more detail. - If you are not sure, say so and point the user to help@brewly.example. - Never invent order numbers, prices or delivery dates.""" response = client . responses . create ( model = "gpt-6-luna" , instructions = SYSTEM_PROMPT , input = "Can I pause my subscription for a month?" , ) print ( response . output_text ) A few things we've learned writing system prompts for client bots: Rules beat adjectives. "Keep replies under 80 words" works. "Be concise" gets interpreted loosely. Tell it what to do when it doesn't know. The fallback line (email support) is what stops a bot from making up a refund policy. Ban the specific lies. Order numbers and delivery dates are what support bots most love to invent, so the prompt names them. If you want to go deeper on wording, our guide to prompt engineering covers structure and testing. Step 4: Add conversation memory (three ways) Ask the bot from Step 3 "Can I pause my plan?", then follow up with "What about two months?" It has no idea what you mean. Every API call starts with a blank slate, because the model is stateless. You have three ways to fix that. Approach How it works Where history lives Best for A. Manual history Append every message and reply to a list, send the whole list each time Your app Full control, store=False for sensitive data B. previous_response_id Pass the last reply's ID; OpenAI fills in the earlier turns OpenAI (responses kept 30 days by default) Terminal bots, short sessions C. Conversations API Create a conversation object once, attach every response to it OpenAI (no 30-day expiry) Web apps where users come back later One thing none of the three changes: you pay for the history every turn. OpenAI's docs say it directly: with previous_response_id , "all previous input tokens for responses in the chain are billed as input tokens." Server-side memory saves you code, not tokens. Option A: manual history (stateless) 1 2 3 4 5 6 7 8 9 10 11 history = [ ] def ask ( user_text ) : history . append ( { "role" : "user" , "content" : user_text } ) response = client . responses . create ( model = "gpt-6-luna" , instructions = SYSTEM_PROMPT , input = history , store = False , # nothing kept on OpenAI's side ) history . extend ( response . output ) # keep ALL output items, not just the text return response . output_text Note history.extend(response.output) . OpenAI's conversation-state guide says to keep every output item so reasoning items stay intact. Appending only output_text as a string works on simple models and quietly degrades answers on reasoning ones. Option B: previous_response_id (the terminal chatbot) This is the full, runnable terminal bot. Save it as chat.py : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 import os from dotenv import load_dotenv from openai import OpenAI load_dotenv ( ) client = OpenAI ( ) MODEL = os . getenv ( "OPENAI_MODEL" , "gpt-6-luna" ) SYSTEM_PROMPT = """You are Ava, the support assistant for Brewly, an online coffee subscription. - Only answer questions about orders, subscriptions, shipping and coffee. - Keep replies under 80 words unless the user asks for more detail. - If you are not sure, say so and point the user to help@brewly.example. - Never invent order numbers, prices or delivery dates.""" def main ( ) : previous_id = None print ( "Ava is ready. Type 'quit' to exit.\n" ) while True : user_text = input ( "You: " ) . strip ( ) if user_text . lower ( ) in { "quit" , "exit" } : break if not user_text : continue stream = client . responses . create ( model = MODEL , instructions = SYSTEM_PROMPT , # resend every turn input = user_text , previous_response_id = previous_id , reasoning = { "effort" : "low" } , stream = True , ) print ( "Ava: " , end = "" , flush = True ) for event in stream : if event . type == "response.output_text.delta" : print ( event . delta , end = "" , flush = True ) elif event . type == "response.completed" : previous_id = event . response . id print ( "\n" ) if __name__ == "__main__" : main ( ) Run python chat.py , ask about pausing, then ask "what about two months?" Ava now knows what "that" refers to. See the comment # resend every turn ? That's the bug that catches almost everyone. The SDK documentation says that with previous_response_id , "the instructions from a previous response will not be carried over to the next response." Send instructions only on the first call and by turn three Ava has forgotten she's a coffee bot and will happily write you a cover letter. Option C: the Conversations API For a web app, a user might close the tab and come back tomorrow. A conversation object survives that, and unlike stored responses it isn't subject to the 30-day TTL: 1 2 3 4 5 6 7 conversation = client . conversations . create ( ) response = client . responses . create ( model = "gpt-6-luna" , instructions = SYSTEM_PROMPT , input = "Can I pause my plan?" , conversation = conversation . id , ) Save conversation.id against your user record and pass it back on every message. We'll use this in the web version. Step 5: Stream replies instead of waiting You already saw streaming in chat.py , but it deserves its own section because it changes how the bot feels more than any model upgrade. Without streaming, the user types a question and stares at nothing for two, three, four seconds while the whole answer generates. Then a wall of text appears. With streaming, the first words show up almost immediately and the reply types itself out. Same total time. Completely different experience. The mechanics are two lines: pass stream=True , then loop over events and print the ones of type response.output_text.delta . Other events you'll see include response.created , response.completed (which carries the final response object and its ID) and error . Step 6: Put the chatbot on a web page with FastAPI Here's where a lot of tutorials go wrong. They call the OpenAI API straight from browser JavaScript, which means shipping your API key to every visitor. Anyone who opens dev tools can copy it and run up your bill. The fix is a thin backend. The browser talks to your server; only your server talks to OpenAI. Create app.py : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 import os from dotenv import load_dotenv from fastapi import FastAPI from fastapi . responses import FileResponse , StreamingResponse from openai import OpenAI from pydantic import BaseModel , Field load_dotenv ( ) client = OpenAI ( timeout = 30 , max_retries = 3 ) MODEL = os . getenv ( "OPENAI_MODEL" , "gpt-6-luna" ) SYSTEM_PROMPT = """You are Ava, the support assistant for Brewly, an online coffee subscription. - Only answer questions about orders, subscriptions, shipping and coffee. - Keep replies under 80 words unless the user asks for more detail. - If you are not sure, say so and point the user to help@brewly.example. - Never invent order numbers, prices or delivery dates.""" app = FastAPI ( ) class ChatIn ( BaseModel ) : conversation_id : str message : str = Field ( min_length = 1 , max_length = 2000 ) @app . get ( "/" ) def home ( ) : return FileResponse ( "index.html" ) @app . post ( "/conversations" ) def new_conversation ( ) : conversation = client . conversations . create ( ) return { "conversation_id" : conversation . id } @app . post ( "/chat" ) def chat ( body : ChatIn ) : def generate ( ) : stream = client . responses . create ( model = MODEL , instructions = SYSTEM_PROMPT , input = body . message , conversation = body . conversation_id , reasoning = { "effort" : "low" } , max_output_tokens = 800 , stream = True , ) for event in stream : if event . type == "response.output_text.delta" : yield event . delta return StreamingResponse ( generate ( ) , media_type = "text/plain" ) Three small details doing real work here: max_length=2000 on the message stops someone pasting a novel into your bot and charging you for it. FastAPI rejects it with a 422 before OpenAI is ever called. max_output_tokens=800 caps the reply cost. Reasoning tokens count toward this limit, so don't set it too tight or replies get cut off. OpenAI(timeout=30, max_retries=3) raises the SDK's default of 2 automatic retries, which covers most brief rate-limit and network blips. Now the front end. Create index.html in the same folder: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 <! doctype html > < html lang = " en " > < head > < meta charset = " utf-8 " > < title > Brewly Assistant </ title > </ head > < body > < div id = " log " > </ div > < form id = " chat-form " > < input id = " msg " autocomplete = " off " placeholder = " Ask about your order... " > < button > Send </ button > </ form > < script > const log = document.getElementById("log"); let conversationId = null; function addLine(who, text) { const p = document.createElement("p"); p.textContent = `${who}: ${text}`; // textContent, never innerHTML log.appendChild(p); return p; } document.getElementById("chat-form").addEventListener("submit", async (e) => { e.preventDefault(); const input = document.getElementById("msg"); const text = input.value.trim(); if (!text) return; input.value = ""; if (!conversationId) { const res = await fetch("/conversations", { method: "POST" }); conversationId = (await res.json()).conversation_id; } addLine("You", text); const botLine = addLine("Ava", ""); const res = await fetch("/chat", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ conversation_id: conversationId, message: text }), }); const reader = res.body.getReader(); const decoder = new TextDecoder(); let reply = ""; while (true) { const { done, value } = await reader.read(); if (done) break; reply += decoder.decode(value, { stream: true }); botLine.textContent = `Ava: ${reply}`; } }); </ script > </ body > </ html > Start the server: 1 uvicorn app : app -- reload Open http://127.0.0.1:8000 and chat. That's a working, streaming, memory-aware chatbot in roughly 130 lines across two files. (The textContent comment isn't decoration. Model output rendered with innerHTML is an XSS hole: a user can talk the bot into returning a <script> tag. If you later want Markdown formatting, run it through a sanitizer such as DOMPurify first.) For a production widget with a launcher bubble, mobile layout and analytics, see our walkthrough on how to add AI chat to your website . How much does an OpenAI chatbot cost to run? Less than most people expect, if you pick the model deliberately. Take a typical support chat: a 300-token system prompt, 10 back-and-forth turns, user messages around 50 tokens and replies around 150. Because earlier turns are re-billed as input each time, the 10 turns add up to roughly 12,500 input tokens and 1,500 output tokens. Model Cost per 10-turn conversation Cost per 10,000 conversations gpt-6-luna ~$0.002 ~$20 gpt-6.1-sol ~$0.04 ~$400 gpt-6-astra ~$0.20 ~$2,000 These are estimates from list prices. They leave out reasoning tokens (billed as output) and cached-input discounts, which push in opposite directions. Measure your real numbers from response.usage after a week of traffic. The pattern that matters: cost grows with conversation length , not just count, because every turn re-sends the history. Two ways to keep long chats in check: Trim manual history. With Option A, keep the system prompt plus the last 10–20 items. Turn on server-side compaction. Pass context_management=[{"type": "compaction", "compact_threshold": 200000}] and OpenAI compresses older context once the conversation crosses that token count. Our full playbook on reducing LLM API costs covers caching, routing and batching in more depth. If you're budgeting a whole project rather than API calls, see what an AI chatbot costs to build in 2026 . Common mistakes (and the fix for each) AttributeError: module 'openai' has no attribute 'ChatCompletion' You copied pre-2023 code. Use client = OpenAI() and client.responses.create() . 400 Bad Request mentioning temperature GPT-6 models don't accept temperature , top_p or top_logprobs while reasoning is switched on. Remove them. Control tone through the system prompt instead. (On Luna you can set reasoning={"effort": "none"} if you really need sampling controls.) The bot forgets its role after a few messages You only sent instructions on the first call. With previous_response_id , resend them every turn. Replies stop mid-sentence max_output_tokens is too low. Reasoning tokens eat into it before visible text does. Raise the cap or lower the reasoning effort. RateLimitError (429) under load The SDK retries automatically, but sustained traffic needs a queue or per-user rate limit on your side. Check your usage tier in the OpenAI dashboard. Before you go live: a short production checklist The tutorial bot works. A public bot needs a bit more: Authenticate users and rate-limit per user. An open /chat endpoint is a free LLM for the whole internet. Send a safety_identifier . It's a stable per-user ID (OpenAI recommends hashing the email or username) that helps OpenAI detect abuse coming through your app without flagging your whole account. Decide on data retention. Responses are stored for 30 days by default. For health, finance or other sensitive data, use manual history with store=False . Log every conversation on your side. You can't improve a prompt you can't read. Review 20 real chats a week and you'll find the gaps fast. Write a test set. Twenty questions with expected answers, run after every prompt change, catches regressions before customers do. Give the bot real knowledge. A system prompt can't hold your entire help center. That's what retrieval is for. Where to go next: from chatbot to something useful Right now Ava is polite but knows nothing about Brewly's actual policies or orders. The next two upgrades fix that: Retrieval-augmented generation (RAG) lets the bot answer from your own documents. Upload them to a vector store and give the model the file_search tool, or build your own pipeline. Start with how RAG works , and if you're weighing it against training a custom model, read RAG vs fine-tuning . Function calling lets the bot do things: look up an order, pause a subscription, book a call. At that point it stops being a chatbot and starts being an agent. Here's the difference in practice: AI agents vs chatbots . Need a chatbot built for your business? This tutorial gets you a working prototype in an afternoon. Getting from prototype to a bot that knows your products, connects to your CRM or order system, and holds up under real traffic is where most of the work lives. That's the work our AI development team does: RAG chatbots, support agents and LLM integrations built in Python and FastAPI and shipped to production. Tell us what you're building and we'll tell you honestly whether you need us or this tutorial is enough.
StripeHow to Add Stripe Payments to a Next.js App
How to Add Stripe Payments to a Next.js App Adding Stripe payments to a Next.js app takes about 30 minutes with the modern approach, and it is simpler than most tutorials make it look. The trick is to use Stripe Checkout , Stripe’s own hosted payment page, rather than building your own card form. You create a checkout session on the server, redirect the user to Stripe to pay, and Stripe sends you back. You never handle raw card details, which makes it faster to build and far more secure. This guide walks through the whole thing, step by step, for the Next.js App Router. Here is the one principle that matters more than any line of code, and the thing beginners get wrong: never trust the browser to confirm a payment. A user can close the tab, lose connection, or tamper with the page after paying. The only reliable way to know a payment succeeded is a webhook, a message Stripe sends directly to your server. Getting the webhook right is what separates a real integration from one that silently loses orders, so this guide treats it as essential, not optional. This guide covers setup, the checkout flow, the all-important webhook, testing, and going live. The quick answer: the whole flow If you want the shape of it first, here is what you are building. Install Stripe and add your API keys to environment variables. Create a server route that makes a Stripe Checkout session and returns its URL. Add a button that calls that route and redirects the user to Stripe to pay. Create a webhook route that listens for Stripe’s confirmation and fulfills the order (this is the critical part). Test locally with the Stripe CLI, then add your live keys and production webhook to go live. The golden rule throughout: Stripe Checkout handles the payment UI and card security for you, and the webhook, not the browser, is the source of truth for whether a payment actually happened. Prerequisites Get these in place first. A Next.js app using the App Router (Next.js 13 or newer), and Node.js 18 or newer. A Stripe account (free to create), with access to your API keys in the Stripe Dashboard. You will use test keys while building. Basic familiarity with Next.js API routes (route handlers) and environment variables. Step 1: Install Stripe and set up your keys Install the Stripe packages: npm install stripe @stripe/stripe-js Then add your keys to a .env.local file in your project root (use your test keys while building): STRIPE_SECRET_KEY=sk_test_your_key NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_your_key STRIPE_WEBHOOK_SECRET=whsec_your_secret NEXT_PUBLIC_APP_URL= http://localhost:3000 Add .env.local to your .gitignore so your secret keys never reach your repository. The secret key must stay on the server only; the publishable key (prefixed NEXT_PUBLIC_) is safe in the browser. It also helps to create one shared Stripe client. Make a file at lib/stripe.ts: import Stripe from “stripe”; export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!); Now every route can import the same configured client. Step 2: Create the checkout session route This server route creates a Stripe Checkout session and returns its URL. Create app/api/checkout/route.ts: import { NextResponse } from “next/server”; import { stripe } from “@/lib/stripe”; export async function POST() { const session = await stripe.checkout.sessions.create({ mode: “payment”, line_items: [ { price_data: { currency: “usd”, product_data: { name: “Your Product” }, unit_amount: 2000, // $20.00, in cents }, quantity: 1, }, ], success_url: ${process.env.NEXT_PUBLIC_APP_URL}/success , cancel_url: ${process.env.NEXT_PUBLIC_APP_URL}/cancel , }); return NextResponse.json({ url: session.url }); } A few notes: amounts are in the smallest currency unit (cents), mode is “payment” for a one-time purchase (use “subscription” for recurring), and success_url and cancel_url are where Stripe sends the user after. The route returns session.url, the hosted Stripe page you will redirect to next. Step 3: Add the checkout button On your page, add a button that calls the route and redirects the user to Stripe. In a client component: “use client”; export default function CheckoutButton() { async function handleClick() { const res = await fetch(“/api/checkout”, { method: “POST” }); const data = await res.json(); window.location.href = data.url; // redirect to Stripe } return <button onClick={handleClick}>Buy now</button>; } That is the entire customer-facing flow: the user clicks, your route makes a session, and the browser sends them to Stripe’s secure page to enter card details. You never touch the card data. Step 4: Create the webhook (the critical part) This is the step that makes the integration trustworthy. After a payment, Stripe sends a message to your server confirming it. You listen for that message and fulfill the order, send the product, mark it paid, email the receipt. Create app/api/webhooks/stripe/route.ts: import { NextResponse } from “next/server”; import { headers } from “next/headers”; import { stripe } from “@/lib/stripe”; import Stripe from “stripe”; export async function POST(req: Request) { const body = await req.text(); // CRITICAL: raw text, not JSON const signature = (await headers()).get(“stripe-signature”)!; let event: Stripe.Event; try { event = stripe.webhooks.constructEvent( body, signature, process.env.STRIPE_WEBHOOK_SECRET! ); } catch (err) { return new NextResponse(“Invalid signature”, { status: 400 }); } if (event.type === “checkout.session.completed”) { const session = event.data.object as Stripe.Checkout.Session; // Fulfill the order here: mark paid, send the product, email receipt console.log(“Payment confirmed:”, session.id); } return NextResponse.json({ received: true }); } Two things catch almost everyone here. First, you must read the raw request body with req.text(), not parsed JSON, because Stripe verifies a signature against the exact raw bytes. Second, always return a 200 response, even for events you do not handle, otherwise Stripe retries for up to 72 hours. Verifying the signature is what proves the message genuinely came from Stripe and not an attacker. Step 5: Test locally with the Stripe CLI You cannot test webhooks just by clicking around, you need Stripe to reach your local server. The Stripe CLI does this. Install it, log in, then forward events to your app: stripe listen --forward-to localhost:3000/api/webhooks/stripe This prints a webhook signing secret (starting whsec_), put that in your STRIPE_WEBHOOK_SECRET. Now run a test payment through your checkout button using Stripe’s test card number, 4242 4242 4242 4242 with any future expiry and any CVC, and watch the CLI forward the checkout.session.completed event to your webhook. When your webhook logs the confirmation, the full loop works. Step 6: Go live Switching to real payments is a short checklist. Replace your test API keys with your live keys (from the Stripe Dashboard, after activating your account). In the Stripe Dashboard, under Developers then Webhooks, add your production webhook endpoint, https://your-domain.com/api/webhooks/stripe , and copy its signing secret into your production environment variables. Deploy, and run one real, small transaction to confirm the live flow end to end. On Vercel or similar, add all your environment variables in the project settings. That is it: real payments flowing, confirmed by webhook, with card security handled entirely by Stripe. The mistakes that break Stripe integrations A few errors catch almost everyone. Avoid these. Trusting the browser instead of the webhook. If you mark an order paid based on the user landing on your success page, you will lose orders and let people fake payments. The webhook is the only source of truth. This is the single most important rule. Parsing the webhook body as JSON. Reading the body any way other than raw text breaks signature verification. Use req.text(). Exposing the secret key. The secret key must stay server-side only. Never prefix it with NEXT_PUBLIC_ or use it in a client component. Not returning 200 from the webhook. If your handler errors or returns a non-200, Stripe retries for up to 72 hours. Handle events, then return 200. Forgetting the production webhook. Local testing uses the CLI; production needs a webhook endpoint registered in the Stripe Dashboard with its own signing secret. Forgetting this means payments work but orders never get fulfilled live. Ready to add payments to your app? Adding Stripe to a Next.js app is genuinely approachable: hosted Checkout handles the hard, sensitive parts, and a correct webhook makes it reliable. Get those two right, and you have production-grade payments without ever touching raw card data. When you want payments built properly, including subscriptions , multiple gateways, or complex billing, as part of a real product, the Craxinno team integrates Stripe and other payment gateways into Next.js and mobile apps. See recent work in the Craxinno portfolio, explore our custom software development service , or email sales@craxinno.com .
AI ChatbotHow to Add AI Chat to Your Website (Step-by-Step)
How to Add AI Chat to Your Website (Step-by-Step) Adding AI chat to your website is far easier in 2026 than most business owners expect, and there are three ways to do it, from a no-code tool you can set up in an afternoon to a fully custom assistant trained on your own content. The right path depends on one thing: how much you need the chat to actually know about your business. This guide walks through all three, step by step, so you can pick the one that fits and get it live. Here is the key decision to make first, because it saves you time and money. A generic chat widget that answers from a script is cheap and fast but limited. An AI chat that answers accurately from your own content, your products, policies, and FAQs, is more powerful and is what most businesses actually want, and it is now very achievable. Knowing which you need before you start is the difference between a quick win and a frustrating one. This guide covers the three ways to add AI chat, a step-by-step for each, what it costs, and how to choose. The quick answer: three ways to add AI chat If you want the options at a glance, here they are, from easiest to most powerful. A no-code chat tool (easiest). Sign up for a service like a hosted AI chat widget, paste a snippet of code into your site, and you have AI chat live in an afternoon. Best for simple needs and non-technical teams. A platform with your own content (middle). Use an AI chat platform that lets you upload your documents, website pages, or FAQs, so the chat answers accurately from your actual business content. Still mostly no-code, more useful, modest monthly cost. A custom AI chat (most powerful). Have a developer build a chat assistant trained on your content, connected to your systems (orders, bookings, accounts), that matches your brand and can actually take actions. Best when chat is important to your business and you want full control. The honest rule: start with the simplest option that meets your need. Most businesses are well served by option two, a platform that answers from their own content, without the cost of a custom build. First, decide what you actually need Before choosing a method, answer two quick questions, because they determine which path fits. Does the chat need to know your business? If you just want to greet visitors and answer a few generic questions, a basic widget is fine. If you want it to answer accurately about your products, pricing, policies, or services, you need a method that uses your own content, which rules out the most basic widgets. This is the single most important question. Does the chat need to do things, or just answer? If answering questions is enough, a platform works. If you need the chat to take actions, look up an order, book an appointment, update an account, you are moving toward a custom build, because that requires connecting to your systems. Most businesses start with answering and add actions later. Your answers point you straight to one of the three methods below. Method 1: Add a no-code AI chat widget (the fast path) This is the quickest way to get AI chat live, and it needs no developer. Here is the process. Step 1: Choose a tool. Pick a hosted AI chat service. Many exist, offering a chat widget you can add to any website, often with a free tier to start. Step 2: Sign up and configure. Create an account, set the chat's name, greeting, and tone, and choose basic settings like colors to match your brand. Step 3: Add your knowledge (if supported). Better no-code tools let you paste in FAQs or point the tool at your website so it can answer from your content. Do this if available, it is what makes the chat actually useful. Step 4: Copy the code snippet. The tool gives you a small snippet of code (usually one line). Step 5: Paste it into your website. Add the snippet to your site, in your site builder's "custom code" or "footer" section, or, on WordPress, via a plugin or the theme footer. Save, and the chat appears on your site. Step 6: Test it. Open your site, ask the chat a few real questions, and refine its settings or knowledge based on how it answers. That is it, AI chat live, often within an afternoon. The limit is that no-code tools offer less control and cannot deeply connect to your systems. Method 2: Use a platform trained on your content (the sweet spot) This is where most businesses should land. These platforms are still largely no-code, but they let the chat answer accurately from your own business content, which is what makes AI chat genuinely useful. Step 1: Choose a content-aware AI chat platform. Pick a service built to ingest your documents and website and answer from them (this uses a technique called RAG , which grounds answers in your real content so the chat does not make things up). Step 2: Upload your content. Add your FAQs, product and service pages, policies, and any help documents. The platform processes them so the chat can retrieve the right answer. Step 3: Configure behavior and brand. Set the tone, the greeting, what to do when it does not know (for example, offer to connect to a human), and match your brand. Step 4: Add it to your site. As with method one, paste the provided snippet into your website. Step 5: Test with real questions, then refine. Ask the questions your customers actually ask, see where answers fall short, and improve the content you fed it. The quality of your uploaded content largely determines how good the chat is. This path gives you a chat that answers accurately about your business, usually for a modest monthly fee, without a custom build. For most businesses, it is the best balance of power and effort. Method 3: Build a custom AI chat (the powerful path) When AI chat is important to your business, when you need it to match your brand exactly, answer from your full knowledge, and take real actions, a custom build is the answer. This needs a developer, but it gives you complete control. A custom AI chat typically uses an LLM (like Claude or GPT) connected to your content through RAG, so it answers accurately from your data, and connected to your systems so it can act, look up an order, check availability, update a record. It lives on your site exactly as you design it, with no third-party branding, and you own it. The build process, at a high level: define what the chat should do and answer, connect it to your content and systems, engineer and test its behavior against real questions, and deploy it to your site with a clean handoff to a human when needed. This is real development, and it is what our guide on the cost to build an AI chatbot breaks down in detail, and if the chat needs to complete tasks rather than just answer, that moves into agent territory, which our guide on AI agents vs chatbots explains. Choose this when chat is a core part of your customer experience and the simpler options have hit their limits. What it costs A quick, honest picture so you can budget. No-code widget: often free to start, then roughly $20 to $100 a month for a small business as you add features and volume. Content-aware platform: typically $50 to a few hundred dollars a month, depending on volume and features. The sweet spot for most businesses. Custom build: a one-time development cost (plus ongoing model usage and maintenance), which starts in the low five figures and scales with complexity. Right when chat is important enough to justify owning it. The pattern: the more the chat needs to know and do, and the more control you want, the more it costs, so match the spend to how much the chat matters to your business. How to choose your method A simple way to decide. If you want AI chat live fast, for simple questions, and have no developer, use a no-code widget (method one). If you want the chat to answer accurately about your business without a custom build, which is most businesses, use a content-aware platform (method two). If chat is core to your business and you need full control, brand match, and the ability to take actions, build custom (method three). And the smart sequence: start simple, prove chat helps your visitors, learn what they actually ask, then upgrade to a more powerful method if the value is there. There is no need to build custom on day one, and often no need to build custom at all. Ready to add AI chat to your website? Adding AI chat is one of the highest-return, lowest-friction ways to improve your website in 2026, it answers visitors instantly, around the clock, and captures leads you would otherwise lose. Start with the simplest method that meets your need, ground it in your real content, and upgrade only when the value justifies it. When you need AI chat that truly fits your business, trained on your content, connected to your systems, matched to your brand, the Craxinno team builds custom AI chat and assistants that work in production. See recent AI work in the Craxinno portfolio , explore our AI development service , or email sales@craxinno.com .
© 2026 — Craxinno Technologies
