DEV Community: Prithvi

Building an AI Agent That Goes Beyond Customer Support

Prithvi — Thu, 13 Aug 2026 04:56:58 +0000

Most AI customer-support tools start with a simple idea: connect a knowledge base and let an AI answer customer questions.

That's useful, but customer conversations rarely stop at answering a question.

A customer might be a potential buyer who needs more information, an existing customer with a technical issue, or someone whose request needs to be routed to the right team.

That's the problem we're trying to solve with Ollabear.

One Agent, Multiple Workflows

Ollabear is designed around three major workflows:

Sales conversations
Customer support
Ticket triage

For sales, the agent can qualify leads, answer product questions, provide quotes, and book meetings.

For support, it can answer questions using company-specific knowledge and provide cited responses.

For ticket triage, it can understand incoming requests and help route complex issues to the appropriate human.

Give the Agent Your Knowledge

An AI agent is only useful if it understands the product it's representing.

Ollabear can learn from sources such as websites, product documentation, help centers, previous tickets, and other business knowledge.

This means the agent isn't limited to generic AI knowledge.

It can work from information specific to the business.

The Ollabear documentation provides more information about how the platform works.

AI + Humans

One of the important design decisions is knowing when not to automate.

Some conversations need human judgment.

Instead of forcing AI to handle everything, Ollabear can escalate complex conversations to the appropriate human while providing relevant context.

The workflow becomes:

Customer
↓
Ollabear
↓
Answer / Action
↓
Human escalation when needed

This allows AI to handle repetitive conversations while humans focus on cases that actually require their attention.

Connecting the Existing Stack

Businesses rarely want another isolated tool.

Ollabear supports 200+ integrations, making it possible to connect the agent with existing business workflows.

You can explore the available Ollabear integrations.

There are also different Ollabear use cases for sales and customer-support workflows.

The Bigger Idea

The future of AI support isn't just about generating better answers.

A useful AI agent should be able to understand context, access relevant business knowledge, take actions, and recognize when a human needs to step in.

That's what we're building with Ollabear: an AI agent designed to participate in the complete customer conversation lifecycle—not just answer questions.

Building a Lightweight SaaS Architecture With Bun and SQLite

Prithvi — Wed, 12 Aug 2026 06:57:13 +0000

When building a modern web application, it's tempting to start with a large infrastructure stack. Databases, caches, queues, containers, and microservices can all be useful—but adding them before they're necessary can make development and maintenance harder.

While building CampusTPO, we took a more lightweight approach.

Why Keep the Stack Simple?

CampusTPO is built around Bun and SQLite, with a modular application structure.

SQLite provides a relational database without requiring a separate database server. Combined with WAL mode, it provides a practical foundation while keeping deployment relatively simple.

The important lesson isn't that SQLite is always the best choice.

It's that infrastructure should match the application's actual requirements.

Authentication and Security

Authentication is treated as part of the application's foundation.

The application includes:

Email/password authentication
Email verification
Google sign-in
Password recovery
Session management
Account management

Security is also built into the architecture through:

Role-based access control
CSRF protection
Content Security Policy
Rate limiting
Password hashing
Audit trails

A Modular Architecture

The codebase separates responsibilities into clear layers:

Routes
   ↓
Services
   ↓
Repositories
   ↓
SQLite

This keeps request handling, business logic, and database operations separated without requiring a distributed microservices architecture.

Don't Build for Problems You Don't Have

A queue can be useful when background processing becomes necessary.

A cache can be useful when there is an actual caching problem.

A distributed database can be useful when the workload requires one.

But introducing these components too early creates additional configuration, deployment, monitoring, and maintenance requirements.

Instead, the architecture can evolve as real requirements emerge.

The Bigger Lesson

Building CampusTPO has reinforced a simple principle:

Start with the smallest architecture that solves the current problem well.

Keep the boundaries clean, measure real bottlenecks, and introduce additional infrastructure when there is a genuine reason for it.

Good architecture isn't about using the most technologies.

It's about understanding why each component exists.

Tags: #webdev #saas #architecture #bun #sqlite

Building a Lightweight SaaS Application With Bun and SQLite

Prithvi — Wed, 12 Aug 2026 05:32:32 +0000

When building a SaaS application, it's easy to assume that a production-ready system needs a large infrastructure stack from day one.

Multiple databases, caches, queues, containers, microservices, and external services can all have their place. But adding complexity before it's actually needed can make a project harder to develop, deploy, and maintain.

While building CampusTPO, we took a more lightweight approach.

Keeping the Infrastructure Simple

CampusTPO is built around Bun and SQLite, with a server-rendered application architecture.

One of the reasons for choosing SQLite is straightforward: it provides a capable relational database without requiring a separate database server to manage.

For an application that doesn't yet require distributed database infrastructure, this can significantly simplify development and deployment.

SQLite's WAL mode also provides a practical way to handle concurrent reads and writes while keeping the database architecture relatively simple.

The philosophy is not that SQLite is the right choice for every application.

It's that the database should match the actual requirements of the application.

Authentication as a Core Feature

Authentication is one of those areas that is easy to underestimate when starting a SaaS project.

It's not just a login form.

A complete authentication system needs to consider account creation, verification, sessions, password recovery, and account management.

CampusTPO includes:

Email and password authentication
Email verification
Google sign-in
Password reset
Session management
Account management

Treating authentication as part of the application's foundation makes it easier to build the rest of the system around authenticated users and permissions.

Security From the Beginning

Security was another consideration throughout the architecture.

The application incorporates several security mechanisms, including:

Role-based access control (RBAC)
CSRF protection
Content Security Policy (CSP)
Rate limiting
Password hashing
Audit trails

These aren't independent checkboxes that automatically make an application secure.

They work together as layers.

For example, RBAC determines what an authenticated user is allowed to access, while CSRF protection helps defend state-changing requests against forged requests. CSP provides another layer against certain classes of browser-based attacks.

The important part is considering these controls during development rather than trying to bolt them onto the application later.

Keeping the Codebase Modular

Another design decision was keeping the application's responsibilities separated.

A simplified representation looks like:

Routes
↓
Services
↓
Repositories
↓
SQLite

The route layer handles incoming requests.

The service layer contains application and business logic.

The repository layer handles data access.

The database remains behind that abstraction instead of being accessed directly throughout the application.

This separation isn't about creating as many layers as possible.

It's about giving different responsibilities clear boundaries.

As the project grows, that makes it easier to test individual components, change implementation details, and understand where particular functionality belongs.

Why Not Use More Infrastructure?

This has probably been one of the more interesting lessons from the project.

There's a tendency in modern application development to assume that a "serious" application needs a large technology stack.

Redis.

Message queues.

Kubernetes.

Multiple database systems.

Microservices.

Distributed workers.

Sometimes those technologies are exactly what a product needs.

But sometimes they aren't.

If the application doesn't currently have a problem that requires a queue, adding one doesn't necessarily improve the architecture.

It can instead introduce:

More services to deploy
More configuration
More failure points
More monitoring requirements
More maintenance
More things developers need to understand

A smaller architecture can actually be the better engineering decision when it matches the current requirements.

Building for Evolution

Keeping things simple doesn't mean designing an application that can never grow.

Quite the opposite.

A good starting architecture should leave room for change.

For example, if application requirements eventually justify moving away from SQLite, having database access isolated behind repositories makes that transition easier.

If background processing becomes necessary, a queue can be introduced when there's an actual workload that benefits from it.

If traffic increases significantly, individual components can be optimized or replaced based on measurable bottlenecks.

The key is to let the application's requirements drive those decisions.

The Bigger Lesson

One of the biggest lessons from building CampusTPO has been that architecture is about trade-offs.

There isn't a universally "best" technology stack.

A distributed architecture might be appropriate for one product and completely unnecessary for another.

A PostgreSQL cluster might be essential for one application while SQLite is perfectly reasonable for another.

The right question isn't:

"What technologies do large applications use?"

It's:

"What does this application actually need?"

That's the question we're trying to keep in mind while developing CampusTPO.

The goal is a foundation that is simple enough to understand, secure enough to trust, modular enough to maintain, and flexible enough to evolve.

And sometimes, that's a better starting point than building for a scale you don't have yet.

What Building Billing Software Taught Me About Workflow Design

Prithvi — Mon, 10 Aug 2026 10:30:21 +0000

Billing software sounds simple until you look at what actually happens inside a business.

An invoice is only one part of the workflow.

A typical business may need to manage customers, quotations, invoices, payments, vendor bills, and GST-related records while keeping everything consistent.

That's where the interesting engineering problems begin.

The Problem With Isolated Features

It's easy to build individual modules:

Customers
Quotations
Invoices
Payments
Vendors
Reports

But users don't experience these as separate modules.

They experience a workflow:

Customer
↓
Quotation
↓
Invoice
↓
Payment
↓
Reporting

The software becomes much more useful when these stages are connected.

For example, customer information shouldn't need to be entered repeatedly when creating a quotation and then an invoice. Payment records should connect back to invoices, while reporting should use the same underlying data.

Designing Around the Workflow

This was one of the ideas behind 21bill, a browser-based billing platform for businesses.

The platform brings together GST-compliant invoicing, quotations, customer management, vendor bills, payment tracking, and GST reporting.

The goal isn't simply to create another invoice generator.

It's to reduce the amount of repetitive administrative work surrounding billing.

A Few Engineering Lessons

Working on workflow-driven software highlights a few principles that apply to many applications.

Model relationships, not just records.

An invoice should have meaningful relationships with customers, payments, and other business data.

Automate repetitive operations.

Every repeated manual step is an opportunity to improve the workflow.

Keep the user experience simple.

Users shouldn't need to understand the underlying database structure to complete a business task.

Design for future integrations.

Business applications rarely exist in isolation. APIs and well-defined interfaces make future integrations easier.

Final Thought

The biggest lesson is simple:

Users don't think in database tables. They think in workflows.

Whether you're building billing software, CRM systems, HR platforms, or education software, understanding that difference can have a major impact on both architecture and user experience.

If you're interested in exploring the product, check out 21bill or the 21bill FAQ.

What Building Placement Management Software Taught Me About Workflow Design

Prithvi — Fri, 07 Aug 2026 05:56:52 +0000

When developers think about campus placement software, it's easy to imagine a simple portal where companies post jobs and students submit applications.

In reality, that's only a small part of the problem.

A complete placement process involves multiple stakeholders:

Students
Training & Placement Officers (TPOs)
College administrators
Recruiters
HR teams

Each group has different requirements, and the software has to keep everyone synchronized.

The Workflow Is More Important Than the Dashboard

A typical campus recruitment cycle looks something like this:

Students register and complete their profiles.
Companies share job opportunities.
Eligibility criteria are applied automatically.
Eligible students apply.
Placement officers coordinate interview schedules.
Recruiters shortlist candidates.
Offers are released.
Placement statistics are updated.

On paper, none of these steps seem particularly difficult.

The challenge comes from managing hundreds or even thousands of students while ensuring every stakeholder has accurate, up-to-date information.

The Spreadsheet Problem

Many institutions still rely on spreadsheets for placement management.

Spreadsheets are excellent for organizing data, but they become difficult to maintain when multiple people need to update records simultaneously.

Common issues include:

Duplicate entries
Version conflicts
Manual eligibility verification
Missing communication
Time-consuming report generation

At scale, these problems can significantly slow down the placement process.

Automation Makes a Difference

One of the biggest improvements modern placement platforms offer is automation.

Instead of manually filtering students for every company, eligibility rules can be applied automatically.

Instead of emailing hundreds of students individually, notifications can be triggered based on recruitment stages.

Instead of manually preparing placement reports, administrators can generate them from existing data.

Automation doesn't replace placement officers—it allows them to spend more time supporting students and collaborating with recruiters.

A Practical Example

These ideas are reflected in Campustpo, a platform built to simplify campus recruitment for colleges, universities, Training & Placement Offices, recruiters, and students.

Rather than treating placements as isolated tasks, it supports the complete recruitment workflow from student registration to placement analytics.

If you're interested in learning more:

🌐 Homepage: https://campustpo.com/
🚀 Platform: https://campustpo.com/
Final Thoughts

Good software isn't measured by the number of screens it has.

It's measured by how effectively it removes repetitive work.

Whether you're building software for education, healthcare, finance, or logistics, the principle remains the same:

Design around workflows—not individual features.

I'm curious how other developers approach workflow-heavy applications.

What techniques have helped you simplify complex business processes?

[21bill](https://21bill.com/) — a [billing software](https://21bill.com/billing-software) for Indian SMBs — to do. Not sure of an HSN code? 21bill has a free [HSN/SAC directory](https://21bill.com/hsn) with GST rates and plain-English FAQs for the most-us

Prithvi — Tue, 04 Aug 2026 10:47:38 +0000

DEV Community: Prithvi

Building an AI Agent That Goes Beyond Customer Support

Building a Lightweight SaaS Architecture With Bun and SQLite

Why Keep the Stack Simple?

Authentication and Security

A Modular Architecture

Don't Build for Problems You Don't Have

The Bigger Lesson

Building a Lightweight SaaS Application With Bun and SQLite

What Building Billing Software Taught Me About Workflow Design

What Building Placement Management Software Taught Me About Workflow Design

[21bill](https://21bill.com/) — a [billing software](https://21bill.com/billing-software) for Indian SMBs — to do. Not sure of an HSN code? 21bill has a free [HSN/SAC directory](https://21bill.com/hsn) with GST rates and plain-English FAQs for the most-us

21bill — India's Simplest Billing Software (invitation only)

Billing Software for Indian SMBs — Invitation Only | 21bill

HSN & SAC Code Directory for Indian SMBs — GST Rates & Guidance | 21bill