When a business conversation suddenly turns technical, you don't need to change the subject. Give a confident 20-second answer, put a pin in the tech, and bring the focus back to what you're actually helping with.
You're not pretending to be a developer — you're keeping the conversation moving. "I know roughly how that works, and Luis can walk you through the details later. Now, back to your pricing…"
Comes up whenever you ask "how are you charging customers?"
Stripe is the cash register of the internet — it charges cards and moves the money to a bank account. Setting it up means creating an account, verifying an identity, and connecting it to their site. One thing you should know that they might not: Stripe accounts require someone 18+, so a parent, guardian, or the program usually has to be involved.
"Stripe is basically your online cash register — you make an account, verify who you are, and plug it into your site. Heads up: you need an adult on the account. The setup itself is a solved problem, a tech mentor can do it with you in one sitting."
"Before the register matters, what goes in it — what's the price, and is it one-time or a subscription?"
A token (or API key) is a long password that proves their website is allowed to use their Stripe account. It lives in the Stripe Dashboard under Developers → API keys. There are two: a publishable key (fine to be visible) and a secret key (never share it, never paste it in a group chat).
"A token is like the key to your cash register — it proves your site is allowed to charge through your Stripe account. It's in your Stripe dashboard under Developers → API keys. Keep the secret one private."
"Pin it for Luis — he'll show you where it goes. Meanwhile: how much are we charging, and would your first customer actually pay it?"
No! Stripe has Payment Links: they click a button in the dashboard, get a checkout link, and can put it behind any "Buy" button — zero code. For a first version that's usually the right move, and it's a genuinely great answer for you to have in your pocket.
"You don't have to. Stripe has Payment Links — you create a link in the dashboard and put it behind your Buy button, no code at all. Perfect for your first sales."
"So the tech is a link away — the real question is who clicks it. Who's your first paying customer?"
Stripe has a practice mode. In test mode, everything looks real but no money moves, and there's a fake card number (4242 4242 4242 4242) for trying checkouts. Flipping to live mode is a switch in the dashboard once the account is verified.
"That's test mode — a sandbox where you rehearse the checkout with a fake card before real money moves. It's a feature, not a bug: demo the fake checkout to a real customer and watch their reaction."
"Actually, this is validation gold — put the test checkout in front of five people and see who gets their card out."
Comes up when you ask about users, accounts, or retention.
OAuth is "let Google vouch for you." Instead of the startup storing usernames and passwords (risky, lots of work), the user clicks "Sign in with Google" and Google confirms who they are. Setting it up means registering the app on Google's developer console and copying two codes into the site. Fiddly, but standard.
"OAuth just means Google vouches for your user so you never have to store passwords — safer for you and easier for them. You register your app with Google, they give you a couple of codes, and you wire up the button. It's fiddly the first time but it's a well-worn path."
"Pin the wiring for Oliy. Bigger question first: why do users need an account — what do they get once they're signed in?"
When they register their app with Google, Google hands back two codes: the client ID (public — like the app's name tag) and the client secret (private — like the app's password). Same pattern as Stripe's publishable vs. secret keys. The kids paste these into their code or settings.
"Those are the two codes Google gives your app when you register it — an ID that's public, like a name tag, and a secret that's private, like a password. You get them from Google's developer console."
"That's a 10-minute job with a tech mentor. Let's get back to what a signed-in user is worth to you."
Often, no — and this one is your home turf. Login is a week of engineering that delays learning whether anyone wants the product. A landing page, a form, a waitlist, or a manual concierge version usually validates faster. If they're building accounts before they have users, that's a strategy conversation, not a tech one.
"Maybe you don't yet! Login is a lot of effort that teaches you nothing about whether people want this. Could version one work with just a form and an email?"
This one doesn't need a pin — it IS the business conversation. Keep going.
Comes up when you ask "how many users do you have?" or "what do you know about your customers?"
A database is the app's memory — a giant organized spreadsheet where it saves users, orders, and messages so they're still there tomorrow. If the team uses tools like Firebase, Supabase, Airtable, or a website builder with accounts, they already have a database; it came with the tool.
"Your database is just your app's memory — a big structured spreadsheet where it keeps users and orders. If you're using something like Firebase or Supabase, that IS your database. You probably already have one without realizing."
"Whatever it's called, it's where your customer data lives — which brings me back to my question: what do you actually know about your users?"
A classic rabbit hole. At their size, the honest answer is: it barely matters. Any mainstream option works, switching later is very possible, and the popular beginner-friendly ones (Supabase, Firebase) are fine defaults. Debating SQL vs. NoSQL before having users is procrastination wearing a technical costume.
"At your stage any popular one is fine, and you can switch later — teams do it all the time. Pick whatever your tech mentor recommends in five minutes and don't look back. The choice won't make or break the company; finding customers will."
"Five-minute decision with Oliy, done. Now — the thing that IS worth debating: who's the customer this data describes?"
Their data sits on the provider's cloud servers (Google's, Amazon's, Supabase's…), not on anyone's laptop — and those providers handle backups far better than any startup could. The realistic risks are mundane: losing the account password, or an accidental "delete all" while testing.
"It lives in the cloud with the provider, and they're better at backups than any of us. Just make sure more than one teammate can access the account, and be careful with delete buttons while testing."
"Your data's safe. Are your customers' expectations safe too? If you collect emails, what did you promise to do with them?"
Comes up in support, onboarding, and "we'll add AI" conversations.
Nobody builds the AI brain — they rent it. Companies like Anthropic and OpenAI sell access to their models through an API. A "chatbot" is three parts: a chat window on the site, written instructions telling the AI how to behave, and the rented brain answering. The hard part isn't the wiring — it's writing instructions that make it useful.
"You don't build the AI — you rent it from companies like Anthropic or OpenAI. Your chatbot is really just a chat window plus written instructions plus their AI answering. Wiring it up is a known recipe; the craft is in the instructions."
"Pin the wiring. First: what should the bot accomplish — deflect support tickets, qualify leads, onboard users? That decides everything else."
Another rabbit hole with a short answer: any major provider is fine to start, and swapping later is easy — it's designed to be. The instructions they write (the "prompt") affect quality far more than which brand of model sits behind it.
"Any of the big ones is fine to start, and switching later is easy. What you write in the instructions matters way more than which model you pick. Don't let this decision block you for even a day."
"Model picked, moving on — what would make a customer say the bot actually helped them?"
Careful — "token" here is a different word than the Stripe/login kind! AI tokens are little pieces of words; providers bill per token, like a utility meter running while the AI reads and writes. Costs at prototype scale are usually pocket change, but a popular free chatbot can quietly become a real bill — which is a genuinely interesting business-model problem.
"AI providers charge per 'token' — chunks of words, like a water meter for text. Testing costs cents. But note it's a cost that grows with usage, which is exactly why we need to talk about pricing."
"So every chat costs you something — does every chat earn you something? Let's look at your unit economics."
The rented AI knows the world in general, not their startup. The simple fix: paste their FAQ, product details, and policies into the bot's instructions so it answers from their material. Fancier versions feed it documents automatically, but paste-it-in works great at this stage.
"Out of the box it knows everything except your company. You fix that by feeding your FAQ and product info into its instructions — literally pasting it in works at your stage. Which means someone has to write that FAQ… and that's a business task, not a coding one."
"Writing what the bot should say = writing what your company says. Great excuse to nail your messaging — let's draft it."
One-liners for words that fly across the table. Enough to nod and keep the meeting on track.