Notes from the workshop.
How we build software that ages well — the products, the craft behind them, and the case for software you can actually keep.
All writing
-
Software shouldn't expire
Most software is built to be disposable. The pieces of your life that matter deserve software that ages well — here is the case for building it.
-
The case against selling your data
A profitable software business does not need to sell its users. Here is the bet Ekarche is built on — and why three products exist to prove it.
-
How Docusift reads any document without a template
Most extraction tools make you build a template per document type. Docusift takes the opposite approach — here is how, and why it matters for finance teams.
-
The 45-day clock every Indian supplier should know
The MSMED Act gives small suppliers a 45-day payment right most never track. Here is how the clock works — and how Lekha keeps it for you.
-
Why one company builds several products
A focused startup builds one thing. Ekarche builds several, on purpose. Here is the logic behind one origin and many products.
-
What 'AI-native' means when we build for you
AI-native means the intelligence is part of the architecture — doing the real work, not bolted on at the edge. Here is what that looks like in the software Ekarche builds.
-
Getting invoices into QuickBooks, Xero and Sheets without
re-keying
The slow part of document work is not reading an invoice — it is typing the numbers a second time. Here is how Docusift lands the result where finance already works.
-
Turning a bank statement into clean, reconciled rows
Two banks, two different PDFs — and no template that fits both. Here is how Docusift turns a bank-statement PDF into clean, reconciled rows you can export.
-
Why every field Docusift extracts carries a confidence score
Extraction is a judgement, not a certainty, so every field Docusift returns carries a confidence score — and the low ones route to a person before they land.
-
What accounts payable looks like when invoices read
themselves
Month-end is quieter when the invoices read themselves. Here is what an accounts-payable workflow looks like with less re-keying and fewer late corrections.
-
Beyond invoices — the documents Docusift reads
Invoices are only the start. Receipts, W-2s, bills of lading, bank statements — here is the range Docusift reads, and why template-free extraction makes it possible.
-
Your household's memory, gathered into one calm app
School circulars, the RC, warranty cards, insurance renewals, bills — the things a household keeps in its head, gathered into one calm app. Memoria is production-ready.
-
A household app in the languages your family actually speaks
Most household apps assume one language at home. Memoria is built for the several an Indian family actually speaks — not translated late, but multilingual by design.
-
Shared with your family, and no one else
Memoria shares your household's paperwork with your family and no one else — encrypted, kept per household, never sold. Here is how the sharing stays private.
-
The renewals that quietly slip past a busy household
Insurance renewals, school circulars, warranty windows — the due dates that slip past a busy household. Here is how Memoria surfaces them while there is still time.
-
A ledger with both sides in one book
A manufacturer owes suppliers and is owed by buyers — two piles of paper that rarely meet. Here is why both sides belong in one ledger, and how Lekha holds them.
-
Capture the supplier's bill from the document, not the
keyboard
Re-typing a supplier's bill into a ledger is where the numbers first go wrong. Here is the case for capturing the purchase straight from the document instead.
-
Following a receivable from purchase order to payment
A receivable rarely fails all at once — it slips a step at a time. Here is how following it down the purchase-order-to-payment chain keeps it from falling through.
-
Udyam registration and the 45-day clock, in plain English
The 45-day payment right rests on being a registered MSME. Here is what Udyam registration does, in plain English, and why it turns a right into something you can hold.
-
Records and tracks — where Lekha stops, and your accountant
starts
Lekha records and tracks your bills; it does not do your accounting. Here is why that narrow line is the honest one — and why a smaller tool is often the better one.
-
What an AI-native operations console is being built to do
An operations console for incidents, changes, on-call and postmortems, with the intelligence built in. Here is what Argus is being built to do, framed as a proof of concept.
-
Finding the incident you've already solved
You have almost certainly solved this incident before. Here is the idea behind similar-incident search and drafted postmortems in Argus — a proof of concept, honestly framed.
-
One agent, one brand — the shape of Kirti
Kirti is one agent per brand — the thing that does the work, not a dashboard you operate. Here is the shape of the idea, framed as the future-stage proof of concept it is.
-
A brand's presence, run as one closed loop
Site, SEO, GEO, content, social and paid rarely pull as one. Here is the idea behind running them as a closed loop on an encrypted per-customer substrate — Kirti, as a POC.
-
Seeing the whole product before you build it
Most software gets described, then built, then discovered to be wrong. Here is the idea behind seeing the whole product as a clickable prototype first — Koryvant, in build-stage.
-
A clickable prototype that hands off to any stack
A clickable prototype that hands off to any stack — every screen, every state, both themes, a bespoke design language. Here is Koryvant's design-complete idea, in build-stage.
-
How we build web apps on React and Next.js
How we build web apps on React and Next.js — the whole surface, every screen and state, accessible in light and dark, and tested from the very first commit.
-
When a project genuinely wants Next.js
Next.js or plain React on Vite and React Router? An honest look at when each is the right call — server rendering, search legibility, and complexity you do not need.
-
Typed, tested backends on Fastify
How we build backends on Fastify — TypeBox schemas at every boundary, one consistent error shape, and coverage grown alongside the code rather than retrofitted before a deadline.
-
FastAPI for Python services that have to hold up
When Python is the right backend and how we build it — FastAPI with real typing, validation, and tests, especially for AI-heavy work like classification and search.
-
One Flutter codebase, two platforms that feel native
One Flutter codebase, two platforms that feel native — and why the real work is the unglamorous states: first run, offline, mid-sync, error, and empty.
-
API contracts that outlive the engagement
We build APIs a client's own team can own after we hand off — typed, documented, tested contracts, no lock-in, and no hidden coupling that makes us impossible to leave.
-
Runtime config in an encrypted database
Why runtime configuration belongs in an encrypted per-tenant database with env as bootstrap only — and how that architecture, not a policy notice, enforces our privacy thesis.
-
Automating your business without duct-tape
Connecting the tools a business already runs so work flows between them without fragile duct-tape — GoHighLevel, Zapier, n8n, Make, webhooks, and custom integrations that hold.
-
Zapier, n8n, or custom — how to choose
Zapier and Make, self-hosted n8n, or a custom integration? An honest guide to the trade-offs — speed, ownership, privacy, and cost — and how to tell which one a job actually needs.
-
Infrastructure you can read and reproduce
Hand-built infrastructure drifts and vanishes with whoever built it. Terraform turns infra into a file you can read, reproduce, and fully own.
-
Test-driven from the first commit
Coverage bolted on after the fact tends to lie. Here is why we write the failing test first, from the first commit, and what the two required layers look like.
-
Secure by default, in practice
Security added at the end is theatre. Secure by default means scoped access, encrypted data, and fail-loud config built in from the first line of code.
-
Per-tenant encryption: privacy by architecture
Privacy on a settings page is a promise. Per-tenant encryption makes it structure — your configuration and data flows decided by where they live, not by policy.
-
Reproducible builds and mirrored base images
Pulling base images from anonymous public registries breaks deploys and trust. Here is why we mirror them to a controlled registry and build the same bytes each time.
-
Where rate limits belong
Per-route rate limits inside the app are an anti-pattern that floods the service. Rate limits belong at the edge, keyed by IP — with one exception worth knowing.
-
Accessibility is a requirement, not a final pass
Accessibility built in from the start is cheaper, better, and verifiable to a standard your team can check — not a polish pass bolted on the week before launch.
-
Performance budgets: a slow page is a broken page
A slow page is a broken page. Treating LCP and CLS as a spec — a budget the build must meet — turns speed from an aspiration into a requirement you can enforce.
-
Durable formats: files you can still open in twenty years
Software you rent can vanish; data you own you can still open in twenty years. Export and durable formats are the difference — and they are engineering decisions.
-
Teaching an AI product to say 'I'm not sure'
Good AI software knows what it does not know. Per-field confidence scores let a product flag uncertainty and route to review instead of guessing with a straight face.
-
The empty state is the product
Demos show the happy path. The empty, loading and error states are where real trust is won or lost — so we design the moments a demo skips as carefully as the rest.
-
Light and dark, both first-class
Dark mode is not a toggle bolted on at the end. Shipping light and dark as equals means tokens only, no raw values, and both themes tested across every breakpoint.
-
The long view, in the software itself
Ageing well is a property of the code, not a company's promises. Here is what the long view actually asks of software — durable formats, slow architecture, fewer moving parts.
-
One origin, shared foundations
Several products from one hand work only if they share a spine. Here is the foundation under the Ekarche family — one encrypted substrate, one security posture, shared formats.
-
What it means to own the software you paid for
You paid for it, but do you own it? Real ownership means no lock-in, durable formats, export on demand, and the freedom to leave with everything intact. Here is the test.
-
The exit-optimised company and its collateral
When a product is built to be sold, the sale is the point and the users are the collateral. Here is who pays for the exit — and the different bet a company can make instead.
-
Building slowly, on purpose
Slow is not the same as late. Building deliberately — deciding the hard-to-reverse things carefully, shipping the surface quickly — is a discipline that produces durable software.
-
Data you can always take with you
Export is the truest test of whether your data is really yours. When it is designed in as a feature rather than a grudging afterthought, leaving is easy — and that is the point.
-
Privacy as architecture, not policy
A privacy promise on a settings page is only as good as the company keeping it. When privacy is enforced by where configuration lives, it holds even when good intentions don't.
-
What a small team can do
A small team cannot do everything, and that is its advantage. Fewer things, done properly, with no seams where the work was handed off. Here is what that buys.
-
Live, production-ready, or a proof of concept
Live, production-ready, and proof of concept mean different things, and blurring them is a small dishonesty we refuse. Here is exactly where each Ekarche product stands.
-
Software for decades, not quarters
Software ages well only when the business behind it is free to let it. No board, no quarterly targets, no pressure to pivot — the company shape that makes patience rational.