Why we built an always-on consultation product
The idea behind Pandit AI started from a simple observation: personalized guidance is usually locked behind scheduled appointments and business hours. You book a slot, you wait, and by the time it arrives, the moment that prompted the question has often passed.
But that's not when people actually have the question. Most of the real, honest "what should I do here" moments show up at 11pm, not during office hours. Someone is lying awake turning something over in their head, or facing a decision the next morning and wants to think it through tonight. A consultation product that's only available 9-to-5 misses almost all of that.
So the core insight wasn't really about AI at all. It was about availability. We wanted something a person could open at any hour, ask an honest question, and get a thoughtful response back in seconds, without waiting for someone else's calendar to open up.
That sounds simple to state. It was not simple to build well, and most of what follows is what we got wrong before we got it right.
There's also a quieter reason availability matters: a lot of the questions people bring to a consultation product are ones they've already been sitting with for a while. They're not looking for a first opinion. They're looking for a place to finally say the thing out loud and get a considered response, without scheduling it, without explaining themselves to a receptionist, and without waiting three days for an opening. Building for that meant treating "right now" as a real requirement, not a nice-to-have.
Lesson one: personalization requires more than a generic prompt
Our first internal versions did what most teams do first: wrap a general-purpose AI model with a themed system prompt and call it done. It answered questions. It even sounded reasonable. But it felt shallow, in the specific way generic advice always feels shallow. It read like advice written for anyone, because it was.
The problem wasn't the model. It was that we were answering the first message in isolation, the same way a stranger would answer a question shouted across a room. Genuinely useful, personalized guidance requires knowing more about the person and their situation before generating advice, not after.
Getting this right meant structuring the conversation itself, not just the prompt. That meant:
- Gathering relevant context first. A few well-chosen follow-up questions before the "answer" does more for perceived usefulness than any amount of prompt engineering.
- Treating the conversation as a whole, not a single exchange. Context gathered earlier needs to actually inform what comes later, not get discarded after each turn.
- Resisting the urge to answer immediately. The fastest response usually isn't the best one. A brief pause to ask the right question first produces a noticeably better outcome.
None of this is exotic. It's closer to how a good conversation actually works than to how a search engine works. But it's easy to skip when you're excited about shipping something that technically answers questions.
We also had to accept a slower path to a good answer than a demo-friendly one. It's tempting, especially early on, to optimize for a single impressive response you can show off. Real usage looks different. Most people don't arrive with a perfectly framed question; they arrive with a rough shape of a problem and figure out the actual question as the conversation goes. A product that only handles the tidy, well-specified version of a question misses most of the value it could provide.
Lesson two: tone matters as much as accuracy
A consultation product lives or dies on whether people feel comfortable being honest with it. If someone holds back the real question because the tool feels cold or clinical, the accuracy of the underlying answer stops mattering. They never asked the actual thing on their mind.
We learned this the hard way. Early responses were technically fine and emotionally flat. They read like a form letter, and people responded to that by disengaging, giving shorter answers, or not coming back at all.
An answer nobody trusts enough to act on isn't actually a good answer, no matter how correct it is.
A meaningful amount of the work that went into Pandit AI wasn't model selection or prompt structure. It was tone. Warm, direct, and non-judgmental, without tipping into being saccharine or so soft it stops saying anything concrete. That balance is genuinely difficult to hold. Lean too far one way and it feels robotic; lean too far the other and it feels evasive, like it's avoiding a real answer to spare your feelings.
Getting the tone right took far more iteration than getting the facts right. That was a surprising ratio going in, and it isn't one we've seen mentioned much in generic writing about building AI products.
One thing that helped was reading actual conversations back, not summaries of them, and noticing exactly where someone's replies got shorter or more guarded. That's usually the tell that a response landed wrong, whether it was too blunt, too vague, or just slightly off in register. It's slow, unglamorous work compared to tuning a model's parameters, but it's where most of the real improvement actually came from.
Lesson three: privacy isn't a feature, it's a prerequisite
People share genuinely personal things with a product like this: relationships, decisions they're anxious about, questions they wouldn't necessarily ask a friend. That changes what "privacy" has to mean. It can't be a checkbox added after launch. It has to be a foundational design decision, made before a single line of the product exists.
In practice, that meant deciding early, not later, that:
- Personal conversations are not sold or shared with third parties.
- Conversations aren't used to train models on identifiable people without their consent.
- Being private and being approachable aren't in tension. People are more honest, not less, when they trust the thing listening.
Treating privacy as an afterthought is one of the easiest ways to quietly build a product people don't fully trust, even if they can't articulate why. For a consultation product specifically, that erosion of trust shows up immediately as shallower, more guarded questions, which defeats the entire point of building it.
This also changes how you evaluate certain shortcuts. Plenty of tempting product decisions, storing more data "just in case," logging full transcripts by default, adding a feature that quietly requires broader access than it needs, look reasonable in isolation. Held up against the actual promise of the product, that it's a safe place to ask an honest question, most of them stop looking reasonable. Deciding privacy up front made those later calls much easier, because there was already a clear standard to check them against instead of relitigating it feature by feature.
What "24/7" actually requires technically
"Available any hour of the day" sounds like a marketing line until you have to actually build the infrastructure behind it. Reliable uptime and fast response times matter more here than for a typical business tool, where people generally tolerate a slow load or a retry.
A person reaching for Pandit AI at midnight, mid-decision, is not in the mood to tolerate friction. If the product times out, hangs, or throws an error at that exact moment, it doesn't just lose a session. It breaks the specific promise the product is built on: that it's there when nothing else is.
That shaped real decisions from day one, not just aspirations:
- Designing for graceful degradation instead of hard failures when a dependency is slow, so a person gets a usable response rather than a spinner or an error page.
- Treating response latency as a product metric, not just an engineering one, because a slow answer at a vulnerable moment feels worse than a slow answer to a routine business query.
- Building monitoring and fallback paths in from the start, rather than bolting on reliability after the first outage taught us the hard way.
None of this is unique to AI products. But it matters more here than it does for most business software, because the moments people use it are often private, sometimes vulnerable, and rarely convenient to reschedule.
Put together, none of these lessons were about chasing a more advanced model or a cleverer prompt. They were about product decisions: how a conversation is structured, how a response is worded, what happens to someone's data, and what happens when a server is slow at 2am. That's not a very exciting story to tell, but it's the honest one, and it's the version of "building an AI product" we'd want to read if we were the ones evaluating whether to trust one.