KalPakka

KalPakka is a payment follow-up workspace that helps small businesses track promises, plan collections and draft personalized AI generated reminders, so they get paid without losing customer trust.

Comment

Inspiration

Every small business owner knows the message. You type it, delete it, type it again, and then leave it in drafts. Someone owes you money, they said they would pay, the date has passed — and asking about it feels like putting the whole relationship at risk to recover an invoice.

So you wait another week, and the awkwardness compounds: the longer you leave it, the harder it becomes to raise.

That hesitation is not a personal quirk. It is a global economic problem hiding in plain sight. The Atradius Payment Practices Barometer 2025 found that overdue invoices account for 42% of B2B credit sales in North America, 44% across Asia, and 47% in Western Europe, with bad debt running between 5% and 10% by region. Sage and Plum Consulting's The Domino Effect (2017) put numbers on the scale: 11% of all invoices issued by small and medium businesses are paid late — around USD 1.01 trillion a year — and 7.5% are eventually written off entirely, for a total global impact the report estimated at USD 3 trillion.

Decades of invoicing software have not moved those numbers, and we think we know why. Businesses do not fail to chase because they lack a reminder. They fail because they do not know what to say. This is not a collections problem. It is a conversation problem — and conversation is exactly what large language models are good at.

KalPakka is named after the Hindi phrase kal pakka — "tomorrow, for sure." The promise you hear right before a payment does not arrive. Every country has its own version of it.

What it does

KalPakka is a promise ledger with a Gemini-powered Conversation Coach.

Instead of tracking invoices, it tracks promises: a person said they would pay a specific amount on a specific date. Each promise carries its amount, date, customer, reference and full history, and moves through six recorded outcomes — open, fulfilled, rescheduled, broken, disputed, cancelled. A reschedule never overwrites the original; it creates a successor and preserves what was first promised, so a customer's real track record stays visible.

Each morning the owner opens a short list: who needs following up today, and why. Selecting anyone produces a Conversation Coach draft written from the recorded facts — the exact amount, the exact date, whether they have missed a date before — in nine languages, at the tone and objective the owner picks.

The single most important design decision: KalPakka never sends anything by itself. It drafts, the owner reads and edits, the owner sends. An AI that messages your customers about money while you are asleep is not a product anyone should want. The restraint is the point.

How we built it

KalPakka was built 100% with AI coding tools — OpenAI Codex and Claude Code. That is only interesting because of the method that made it hold together.

Documentation is the control surface. The repository carries 118 Markdown documents, including a design decision register of 175 numbered decisions and 93 tracked known issues, each with its reasoning, its trade-off and what would change it. Architecture and flow diagrams are written as Mermaid in the planning documents. This is what makes AI-built software maintainable: a later session — human or model — inherits the argument, not just the code, and cannot silently undo a decision without meeting the reason it was made.

Verification is layered, not assumed. 830 unit tests across 71 files. 55 end-to-end Playwright journeys across 18 spec files, eleven of which run axe accessibility audits. Fifteen database test files that exercise row-level security and tenant isolation directly against Postgres, so "one business cannot see another's data" is proven rather than asserted. And an accepted-corpus suite that pins the exact wording of every Coach draft, so a change in tone shows up as a failing test.

Safety rails around the model. A strict packet boundary decides what may reach Gemini at all — forbidden keys, identity placeholders, and redaction of emails, phone numbers and IDs. Every AI path has a deterministic fallback, so the product still works when the provider does not. There is a kill switch, and per-tenant metering with cost caps.

Challenges we ran into

Designing the Conversation Coach. A model that invents a figure in a message about money is worse than no model at all. So every draft passes a fact-lock validation engine that checks the amounts and dates in the generated text against the recorded promise before the owner ever sees it. The hard part was calibration: strict enough to be trustworthy, without rejecting good writing.

Designing the adaptive guide. Gemini decides which follow-up questions to ask the owner — but inside a closed vocabulary: eight permitted controls, a fixed set of input kinds and option codes, at most five steps, and at most one dependency between them. The model chooses which question to ask; it cannot invent a new one. Constraining generative AI while keeping it genuinely adaptive turned out to be the hardest design problem in the project.

Testing against real promises. This produced the most humbling result of the build. In one evaluation run, six of thirty-four Gemini drafts were rejected by our own validator as "prohibited wording" — and on inspection, not one of them contained a penalty, a threat or a legal claim. The owner was being told their draft contained "penalties, legal action", which was simply untrue. One rule was matching "as soon as possible"; another was flagging kripya, ordinary polite Hindi for "please". The model was fine. Our validator was wrong, and it was wrong in a way that quietly undermined trust in a good draft. Testing generative AI with real data mostly means discovering that your own safety rules are sometimes miscalibrated.

Accomplishments that we're proud of

The fact-lock validation engine — generated text about money, checked against recorded facts before a human sees it. The closed-vocabulary adaptive guide, which lets Gemini choose the question without ever inventing one. A product that drafts in nine languages and still never sends a single message on its own. And the evidence base underneath all of it: 830 unit tests, 55 end-to-end journeys, tenant isolation proven at the database, and accessibility audited across eleven user journeys.

What we learned

That fact-locking is the difference between a demo and a product you would let near a customer: constrain the model's output against recorded truth, and give it a deterministic fallback for everything else.

That a promise has stages, and each one needs a different conversation. A payment due tomorrow, a date missed once, a date missed three times, and a customer who has gone quiet are four different situations. Treating them the same is why generic reminders do not work — and building the product around those six outcomes, rather than around invoices, is what made the Coach possible at all.

And that AI-built software lives or dies on written reasoning. The code was the easy part.

What's next for KalPakka

Near term: Spread the word, go deeper into the conversation.

Marketing to onboard new businesses, hard evidence that the drafts move money — collection rate and days-to-payment, measured per business against its own baseline. A tool that makes chasing feel easier without getting people paid faster is not worth anyone's morning.

And widening what the Coach handles. Today it is strongest on the follow-up itself. Next come the conversations after it: negotiating a payment plan, a disputed amount, the customer who reschedules a third time, the one who has gone silent. Each is a different stage of the same promise, and each needs its own conversation rather than a firmer version of the last.

Then: Scale-up, features, teams and plans.

More user acquisition, Team access, so the person who makes the call need not be the person who owns the account. Paid tiers. Integrations with the invoicing tools businesses already use, so a promise can be recorded without retyping it.

The long game: a shared record of who keeps their promises.

Today every business keeps its own private customer list. "Google" in one ledger has nothing to do with "Google" in another. Verified business identity changes that — one real company, one entity, selectable when recording a promise — so a track record attaches to the business rather than to one supplier's spreadsheet.

That unlocks what no single ledger can: a trustworthiness rating built from real payment behaviour. Not self-reported credit, but whether a company actually pays when it says it will. Larger firms have credit insurance and reporting agencies; the one-person business has a gut feeling. Closing that asymmetry is the most valuable thing KalPakka could do.

It is also what we would build most slowly. A payment-reliability score is credit information, and it carries real duties: verified identity, consent, the right to see and dispute your own record, and rules that stop one aggrieved supplier damaging a company's standing.

Built With

Share this project:

Updates