Technology
A concrete description of how AbhiKai is built and why it needs the infrastructure it does — written for engineers, technical due diligence, and cloud programme reviewers rather than for a brochure.
No badges and no buzzwords. Where something is not built, it is listed as not built.
1. What kind of system this is
AbhiKai is a multi-tenant SaaS application. One deployment serves every business, and each business's data is isolated from every other's inside the same database. That is the cheapest way to run it and the hardest way to get right, which is why isolation is enforced at the storage layer rather than in application code.
The web application is server-rendered by default. Marketing pages are prerendered to static HTML at build time and served from a CDN; the product pages render on the server per request with the signed-in user's permissions already applied.
2. Tenancy and isolation
Every row that belongs to a business carries its business id, and row-level security policies in Postgres decide what a given session may read. A query that forgets to filter returns nothing rather than another tenant's rows.
Roles — Owner, Manager, Team Lead, Sales — are enforced in the same policies. A salesperson's session cannot read a colleague's leads even if the request is hand-crafted, because the restriction lives below the API rather than in it.
3. Designing queries for growth
A lead table grows for as long as a business keeps advertising, and it is never truncated. So every list in the product is built the same way, deliberately:
- An index that covers the exact WHERE and ORDER BY the query uses, rather than relying on a sequential scan.
- Keyset (cursor) pagination — never OFFSET, which gets linearly slower the deeper a user scrolls.
- Aggregates read from maintained counters instead of counting rows on every page load.
- No N+1 access patterns: a list of leads and their owners is one query, not one per row.
- The target is that response time is a function of page size, not of table size.
4. Data model
Postgres is the system of record. The core entities are businesses, memberships and roles, leads, customers, activity events, and the billing catalogue of plans and prepaid packs.
The activity log is append-only. A call, a note, a status change or a reassignment is recorded as an event with an actor and a timestamp and is never edited in place, because an audit trail that can be rewritten is not an audit trail.
5. AI workloads
AI runs at two points: on an inbound lead, to score it and suggest who to call first, and on demand, to turn a rep's two dictated lines into a clean note and a draft reply.
These are inference calls per enquiry, not per session, so cost scales with a customer's advertising spend rather than with their headcount. Every AI action is inspectable — the score shows its reasoning, and anything that could reach a customer can require human approval before it is sent.
6. Ingest and background work
Leads arrive from webhooks — website forms, Meta lead ads, WhatsApp — and webhook traffic is bursty by nature: a campaign goes live and a month of volume arrives in an afternoon. Intake endpoints authenticate with their own tokens rather than a user session, validate against a schema shared with the client, and are idempotent so a retried delivery cannot create a duplicate lead.
Scheduled work handles follow-up reminders, stale-lead alerts, daily digests and reporting rollups. Payment webhooks are signature-verified and processed idempotently, so a replayed notification can neither double-charge a customer nor double-credit an account.
7. Current stack
Stated plainly, because a vague technology page is a red flag:
- Application — Next.js on the App Router with React Server Components, TypeScript in strict mode end to end.
- Database and auth — Postgres with row-level security, plus managed authentication.
- Storage — private object storage; files are reached only through short-lived signed URLs.
- Payments — Razorpay hosted checkout, so card data never touches our servers.
- Email — a transactional provider for verification, invitations, receipts and alerts.
- AI — a hosted inference provider, engaged under terms that prohibit training on customer data.
- Validation — one schema per input, shared by client and server, so the two can never disagree.
8. How we hold quality
Nothing merges unless type checking, linting and a production build all pass with zero errors and zero warnings, and the unit suite is green. Performance is a budget rather than an aspiration: marketing pages are measured with Lighthouse on both mobile and desktop, and a regression is treated as a failure.
Client-side JavaScript is treated as a cost. Marketing pages ship none of their own — the FAQ accordions are native HTML elements and every animation is CSS — which is why they are fast on the cheap Android phones our customers' teams actually use.
9. What is not built yet
An honest list, because the roadmap is public and this is the engineering half of it:
- Two-factor authentication for user logins — the most requested security item.
- Single sign-on, SCIM provisioning and IP allow-listing.
- A read-replica strategy; today reads and writes hit the same primary.
- A public API and webhooks for customers to build against.
- Regional data residency guarantees beyond what our providers offer.
- Third-party security certification — none held and none currently in progress.
Questions about this document? Email hello@abhikai.com with the document name in the subject.