DEV Community: Mihai-Cristian Bâltac

We Built a Chatbot Without an LLM: Here’s How It Works

Mihai-Cristian Bâltac — Fri, 04 Sep 2026 07:30:15 +0000

When you hear "chatbot" in 2026, the obvious architecture is something like:

For one of our projects, we deliberately didn't do that.

The chatbot needed to answer questions about things like:

prices;
opening hours;
appointments;
service availability;
business policies.

For those kinds of questions, we cared more about predictability than creativity.

If the business says:

We only work by appointment.

we don't want a model to turn that into:

Appointments are recommended, but you may be able to come without one.

It sounds helpful.

It is also wrong.

So we built a deterministic chatbot with:

Astro;
TypeScript;
Sanity;
Fuse.js.

No LLM generates the customer-facing answers.

Here's how it works.

The basic idea

Instead of asking a model:

What should I answer?

we ask our system:

Which known intent does this question most likely belong to?

The business controls the actual response.

Conceptually:

The important part isn't actually Fuse.js.

It's everything around it.

Sanity is the knowledge source

We didn't want prices, answers, keywords, or conversation options buried inside the application code.

An intent can look approximately like this:

export interface ChatIntent {
  id: string
  title: string

  phrases: string[]
  keywords: string[]
  negativeKeywords?: string[]

  answer: string

  priority?: number

  contextTags?: string[]
  requiredContextTags?: string[]

  buttons?: ChatButton[]

  enabled: boolean
}

For example:

{
  "title": "Consultation price",
  "phrases": [
    "How much does a consultation cost?",
    "What is the price of a consultation?",
    "What do you charge for a consultation?"
  ],
  "keywords": [
    "price",
    "cost",
    "charge",
    "consultation",
    "consult"
  ],
  "answer": "A consultation costs...",
  "enabled": true
}

This separation turned out to be useful.

The matcher decides what the user means.

The business decides what the answer is.

If the business changes a price or opening hour, it can be updated from Sanity without changing the matching algorithm.

First, normalize everything

Real users don't type like your test data.

They write:

how much consult
consultation price???
HOW MUCH
how mutch is consultation

Or, in Romanian:

cat costa consultatia

instead of:

Cât costă consultația?

So before matching anything, we normalize the input.

A simplified version:

export function normalizeText(value: string): string {
  return value
    .toLowerCase()
    .normalize('NFD')
    .replace(/\p{Diacritic}/gu, '')
    .replace(/[^\p{L}\p{N}\s]/gu, ' ')
    .replace(/\s+/g, ' ')
    .trim()
}

Normalization gets rid of a surprising amount of unnecessary complexity.

But it isn't enough.

Exact matches should still win

Before doing anything clever, check the obvious cases.

function exactPhraseMatch(
  message: string,
  phrases: string[],
): boolean {
  return phrases.some(
    phrase => normalizeText(phrase) === message
  )
}

If the user asks exactly something we already know, there is little reason to rely on fuzzy matching.

We can also look for known phrases inside longer messages:

function containedPhraseMatch(
  message: string,
  phrases: string[],
): boolean {
  return phrases.some(phrase =>
    message.includes(normalizeText(phrase))
  )
}

But things become harder when someone writes:

Hi, I have a dog and I'd like to know roughly how much it would cost to bring him in for a consultation.

That's where multiple signals become useful.

Keywords help, but they aren't the answer

An intent about consultation pricing might contain:

[
  'price',
  'cost',
  'charge',
  'consult',
  'consultation'
]

We can calculate keyword coverage:

function keywordCoverage(
  message: string,
  keywords: string[],
): number {
  if (!keywords.length) return 0

  const matches = keywords.filter(keyword =>
    message.includes(normalizeText(keyword))
  )

  return matches.length / keywords.length
}

But imagine the user only writes:

price

We might have:

consultation price
vaccine price
subscription price
analysis price

Technically, they all match.

So keywords become another signal rather than the decision.

Then comes fuzzy matching

We use Fuse.js to catch approximate wording and typos.

Something roughly like:

import Fuse from 'fuse.js'

const fuse = new Fuse(searchablePhrases, {
  includeScore: true,
  threshold: 0.35,
  keys: ['text'],
})

Then:

const results = fuse.search(normalizedMessage)

This helps with variations such as:

consultation
consutation
consultaton

But this is where one of the more important lessons from the project appeared:

The best fuzzy result isn't necessarily a safe answer.

Fuse will try to find the nearest thing.

Our chatbot needs to decide whether that nearest thing is actually good enough.

So we combine signals

Conceptually, each candidate gets something like:

interface MatchSignals {
  exactPhrase: number
  containedPhrase: number
  keywordCoverage: number
  fuzzySimilarity: number
  contextBoost: number
  priorityBoost: number
  negativePenalty: number
}

And those signals can contribute to a score:

function calculateScore(signals: MatchSignals) {
  return (
    signals.exactPhrase * 0.35 +
    signals.containedPhrase * 0.20 +
    signals.keywordCoverage * 0.20 +
    signals.fuzzySimilarity * 0.15 +
    signals.contextBoost * 0.05 +
    signals.priorityBoost * 0.05 -
    signals.negativePenalty
  )
}

Those weights are illustrative.

The real point is the architecture:

Exact phrase
      +
Keywords
      +
Fuzzy similarity
      +
Context
      +
Priority
      -
Negative signals
      ↓
Confidence

No single signal gets complete control.

Negative keywords were surprisingly useful

Consider:

consultation price
cancel consultation

Both contain consultation.

For the pricing intent we might have:

keywords: [
  'price',
  'cost',
  'charge'
]

but also:

negativeKeywords: [
  'cancel',
  'cancellation',
  'reschedule'
]

If someone writes:

How do I cancel my consultation?

the word consultation helps both candidates, but cancel actively hurts the pricing candidate.

Sometimes knowing what an intent isn't is almost as useful as knowing what it is.

The most important check: ambiguity

Suppose our matcher returns:

[
  {
    intent: 'consultation-price',
    score: 0.81
  },
  {
    intent: 'subscription-price',
    score: 0.79
  }
]

Technically, consultation-price won.

But did it really?

The difference is:

0.02

We don't want:

return matches[0]

Instead, we can use both an answer threshold and an ambiguity margin.

const ANSWER_THRESHOLD = 0.75
const AMBIGUITY_MARGIN = 0.10

const [best, second] = matches

if (best.score < ANSWER_THRESHOLD) {
  return fallback()
}

if (
  second &&
  best.score - second.score < AMBIGUITY_MARGIN
) {
  return clarification()
}

return answer(best.intent)

Again, the numbers are only examples.

The idea is much more important:

A candidate isn't trustworthy merely because it came first.

We have three outcomes

Instead of:

matched
not matched

we use:

type MatchResult =
  | {
      type: 'answer'
      intent: ChatIntent
      confidence: number
    }
  | {
      type: 'clarify'
      candidates: ChatIntent[]
    }
  | {
      type: 'fallback'
    }

1. Answer

User:
How much does a consultation cost?

Bot:
A consultation costs...

2. Clarify

User:
How much does it cost?

Bot:
Which service would you like the price for?

[Consultation]
[Tests]
[Subscription]

3. Fallback

User:
I have a complicated situation...

Bot:
I don't have enough information to answer that correctly.

Would you like me to send your question to the team?

For this project, refusing to answer is a feature.

What about follow-up questions?

Then we ran into conversations like this:

User:
How much does the consultation cost?

Bot:
...

User:
And what does it include?

Analyzed independently:

and what does it include

is almost useless.

So we keep lightweight conversation context:

interface ConversationContext {
  previousIntent?: string
  activeTopic?: string
  contextTags: string[]
}

After the first question:

{
  previousIntent: 'consultation-price',
  activeTopic: 'consultation',
  contextTags: ['consultation']
}

Another intent can require:

requiredContextTags: ['consultation']

and receive a small scoring boost.

We don't need an LLM-sized memory system for every type of conversational context.

Sometimes remembering what we're currently talking about is enough.

Astro exposes the matcher

The UI doesn't contain the matching logic.

It sends the message to an Astro API endpoint:

POST /api/chatbot/message

For example:

{
  "message": "how much does a consultation cost",
  "sessionId": "..."
}

A simplified endpoint:

import type { APIRoute } from 'astro'
import { matchMessage } from '@/lib/chatbot/matcher'

export const POST: APIRoute = async ({ request }) => {
  const body = await request.json()

  const result = await matchMessage({
    message: body.message,
    sessionId: body.sessionId,
  })

  return new Response(
    JSON.stringify(result),
    {
      headers: {
        'Content-Type': 'application/json',
      },
    },
  )
}

The frontend receives a predictable result:

{
  "type": "answer",
  "message": "A consultation costs...",
  "buttons": [
    {
      "label": "Book an appointment",
      "action": "..."
    }
  ]
}

This also means we can replace or redesign the chat UI without rewriting the matcher.

Sanity shouldn't sit in front of every message

The intents don't change every few seconds.

So querying Sanity for every user message would add unnecessary work.

Instead, the knowledge base can be cached:

let cachedKnowledge: KnowledgeBase | null = null
let expiresAt = 0

export async function getKnowledge() {
  if (
    cachedKnowledge &&
    Date.now() < expiresAt
  ) {
    return cachedKnowledge
  }

  const intents = await fetchIntentsFromSanity()

  cachedKnowledge = buildKnowledgeBase(intents)
  expiresAt = Date.now() + CACHE_TTL

  return cachedKnowledge
}

Sanity remains the source of truth.

It doesn't necessarily need to be part of the critical path for every message.

The unexpected part: unanswered questions are useful

Originally, the goal was straightforward:

Reduce repetitive customer-support questions.

But then we started thinking about the fallback data.

Imagine seeing:

37 × "do you provide emergency services?"
21 × "can I pay monthly?"
18 × "are you open on Saturdays?"

Those aren't only chatbot failures.

They're customer signals.

They can indicate:

a missing chatbot intent;
unclear website content;
terminology customers use that the business doesn't;
a potential article;
a UX problem;
a possible new service or package.

This changed how I think about the system.

The chatbot isn't only an answering machine.

It can also become a customer research interface.

Ironically, this is where AI becomes interesting

We deliberately avoided generative AI for official answers.

But I think AI could be extremely useful one step later.

Imagine collecting 500 unanswered questions and asking a model to cluster them.

It might identify:

Cluster: Emergency availability

- do you handle emergencies?
- can I come in urgently?
- do you offer emergency consultations?
- do you accept emergencies at night?

Then a human decides:

Should we create another intent?
Is the website missing important information?
Are customers using different terminology?
Is there demand for something the business doesn't currently offer?

That gives us a separation I like:

AI → analysis

Deterministic system → official answers

It's not really "AI vs no AI."

It's about putting each tool in the part of the system where its characteristics are useful.

The main thing I learned

The difficult part of this chatbot wasn't teaching it to answer questions.

It was teaching it when not to answer.

A fuzzy search system can almost always find something that looks similar.

A trustworthy system needs another capability:

I found something,
but I'm not confident enough to use it.

For prices, schedules, policies, service conditions, and similar business information, that behavior can be more valuable than generating a natural-sounding response every time.

And the questions it refuses to answer?

Those may eventually become the most interesting data in the whole system.

If you're interested in the longer implementation guide and the product reasoning behind the experiment, I've documented the project in more detail on the Digital Empr Research & Development site. Unfortunately, the website is currently only available in Romanian, but we’re planning to translate it into English soon.

Disclosure: I designed and implemented the system described here. AI tools were used to assist with editing and structuring this article; the technical decisions and project experience are my own.

Marketing Started Making Sense When I Stopped Seeing It as Content and Started Seeing It as Infrastructure

Mihai-Cristian Bâltac — Tue, 21 Apr 2026 08:49:19 +0000

For a long time, marketing felt vague to me.

As a developer, I was used to things that were concrete: inputs, outputs, dependencies, systems.

Marketing seemed to live in a different world. People talked about building a brand, posting consistently, creating awareness, increasing trust.

None of that was wrong.

But a lot of it felt too abstract to respect.

What finally made marketing click for me was a simple shift:

I stopped seeing it as content, and started seeing it as infrastructure.

The Mistake I Was Making

Like a lot of technical people, I was only seeing the visible layer.

I saw:

posts
ads
blog articles
emails
headlines
hooks

What I was missing was everything underneath:

where leads actually go
what gets measured
what breaks trust
where people drop off
how fast a team can react
how much manual work sits behind “simple” marketing actions

Once I started paying attention to that layer, marketing stopped feeling fluffy.

It started feeling familiar.

Where It Became Real

The shift happened when I started looking at websites less like deliverables and more like parts of larger systems.

A form is not just a form.

It is also:

lead capture
routing
filtering
tracking
follow-up

An events page is not just an events page.

It can also be:

a source of truth
a publishing workflow
a distribution problem
an operations problem

That was the shift.

I stopped asking only:

How should this page look?

And started asking:

What system is this page part of?

A Quick Example

One of the clearest examples was a business updating event information in more than one place.

The website had one version. Facebook had another. Sometimes one got updated and the other did not.

At first, that looks like a content problem.

It is not.

It is a system problem.

The real fix is not “write better.”
The real fix is to make one place the source of truth and reduce duplication.

That is when marketing started making more sense to me.

Because a lot of “marketing work” is really about reducing friction, inconsistency, and delay.

Why Developers Have an Advantage Here

Developers are not automatically better marketers.

But we do have one useful advantage:

we are trained to think in systems.

That matters more than it seems.

Because once you look past the surface, a lot of marketing becomes a question of structure:

what happens before attention
what happens after someone clicks
what gets tracked
what gets repeated
what creates friction
what slows teams down
what breaks consistency

That mindset transfers well.

It helps you notice that:

traffic without routing is incomplete
content without distribution logic gets wasted
tracking without trust is misleading
a CMS is not just an editor, but a control layer

That was the point where marketing became easier to respect.

Why “Infrastructure” Is the Right Word

Content is visible.

Infrastructure is what makes content:

repeatable
measurable
connected
easier to maintain
easier to scale

And that is where a lot of business value actually comes from.

Not one perfect campaign.

A better system.

A lot of marketing problems are really system problems in disguise:

weak handoff after a lead arrives
disconnected tools
duplicated updates
poor measurement
too much manual work
friction in simple workflows

That is why I no longer see marketing and implementation as separate worlds.

In many cases, they are the same problem viewed from different angles.

What I Believe Now

I used to think marketing was mostly about content.

Now I think content is just one visible expression of a larger system.

Marketing started making sense when I saw it as infrastructure:

how attention is captured
how trust is reinforced
how leads are routed
how actions are tracked
how information stays consistent
how teams move faster with less friction

That shift changed how I think about websites, CMS setups, automations, reporting, and even simple forms.

Because a lot of the time, the most useful thing you can build is not another feature.

It is a cleaner system.

If you're curious what this looks like in practice, here are the kinds of problems I currently help solve.

Has marketing ever made more sense to you once you stopped seeing it as promotion and started seeing it as a system?

I Thought Good Software Would Market Itself. I Was Wrong.

Mihai-Cristian Bâltac — Tue, 14 Apr 2026 10:42:23 +0000

For most of my career, I believed something a lot of technical people quietly believe:

If you build something genuinely good, people will notice.

Clean code. Good UX. Fast performance. Real value.

Surely that should be enough.

It was not.

The Belief That Broke

My background was mostly in frontend, UI, and later full stack work. For years, I thought like a builder first: make the product better, make the system stronger, and the results will follow.

That belief feels rational, especially when you spend most of your time around other technical people.

But the moment you try to build something outside your job, you run into a different reality:

good work does not automatically create attention.

Why I Started Questioning It

Then the market changed.

AI got better. Layoffs became more common. More teams started doing more with fewer people. More non-technical people started building tools and workflows with AI.

At the same time, I kept hearing the same kind of quiet anxiety from people in tech:

“Every quarter we have another meeting where they announce the team will shrink again.”

That pushed me into a question I had avoided for a long time:

If being a good developer is no longer enough, what else do I need to become?

The Wrong Assumption

When I started building things outside my job, I made a very common mistake.

I thought quality would create demand.

I thought if I made something useful, polished, and technically strong, people would come. Maybe through referrals, word of mouth, or “organic growth.”

It sounds reasonable.

It is also one of the biggest lies builders tell themselves.

A good product does not create traffic by itself.

A good website does not create attention by itself.

A good app does not create customers by itself.

What good software does is this:

once people arrive, it helps convert, retain, and impress them.

But first, people have to arrive.

That is where marketing starts.

What Frustrated Me About Marketing

When I started taking marketing seriously, it felt frustratingly vague.

As developers, we are used to practical steps:
install this, configure this, test this, fix this.

Marketing felt full of advice like:

post consistently
know your audience
provide value
build your brand

None of that is wrong.

But when you are starting, it can feel too abstract to act on.

So I approached marketing the same way I eventually learned programming:

learn the concepts
understand the mental models
test things in the real world
keep what works
stop confusing theory with progress

That changed the way I looked at it.

The Hardest Lesson

The hardest lesson was this:

building something good and getting attention for it are two different skills.

A lot of technical people overvalue creation and undervalue distribution. I did too.

We assume the hard part is making the product.

Sometimes it is.

But often the harder part is making the right people aware that it exists, understand why it matters, and trust it enough to try it.

I also had another wrong assumption:

I thought that if I wanted a problem solved badly enough, a lot of other people probably wanted the same thing.

Sometimes that is true.

Often it is not.

A lot of developer-built products are polished versions of our own frustrations. That is not automatically bad, but it is not the same thing as market demand.

To understand what other people actually need, you have to do something many developers avoid:

talk to people. A lot of them.

Where Developers Still Have an Advantage

The interesting part is that once I stopped expecting software to market itself, I started seeing a different advantage.

Developers are not automatically good at marketing.

But good developers do have one big advantage:

we are trained to think in systems.

And that matters more than I expected.

Because once you move past the surface-level idea of marketing, a lot of it becomes a question of structure:

what happens before attention
what happens after someone clicks
where people drop off
what gets measured
what creates friction

That was familiar territory.

I stopped seeing marketing as “making posts” and started seeing it as part communication, part systems design, part customer understanding.

That made it much easier to take seriously.

What I Believe Now

I no longer believe that good software markets itself.

I believe this instead:

good software matters once attention already exists
distribution is a real skill, not an afterthought
understanding business makes technical work more valuable
talking to customers beats guessing
building is important, but it is not the whole game

The market is getting noisier. More people can create. More tools reduce the gap. More companies buy outcomes, not technical elegance.

So the question is no longer just:

Can you build it?

It is also:

Can you understand who it is for, why it matters, and how it reaches the right people?

That is the shift I am trying to make now.

And honestly, I think more developers should make it too.

What changed your perspective more: building products, or trying to get people to care about them?

Has anyone managed to create a custom Gem in Gemini for image generation that actually works well?

Mihai-Cristian Bâltac — Tue, 24 Mar 2026 18:41:06 +0000

I’ve tried a lot of approaches: giving it JSON instructions, adding reference images, and describing the style in detail, but the results still don’t follow the intended look consistently.

What I’m trying to achieve is simple:
I want to upload one image and have Gemini generate a new image in the same visual style.

At the moment, it doesn’t seem to handle that reliably.