Journal ENGINEERING 8 Feb 2026 13 min read

Fourteen years of receipts.

What 45+ documented case studies taught us about writing software. Eight cross-cutting lessons, each attributed to the project that earned it.

Darpan Dalal
Darpan Dalal
Founder & CEO

The Creative Mantra case-studies brochure is 32 pages. Forty-five projects across three practices — UI/UX & software development, management systems, and applied AI/ML — each written up in the same shape: Scope, How we planned, How we delivered, What we learnt, How the client improved.

The "What we learnt" sections are the parts we go back to. Fourteen years of "What we learnt" lines up as a kind of accidental engineering handbook — not a list of principles we set out to prove, but a list of lessons projects handed us, one at a time, in the language of the specific domain they came from.

Eight of them are below. Each is a line we now carry into the next engagement. Each one is credited to the project that earned it. Together they are the closest thing we have to a Creative Mantra worldview.

Eight receipts · one per project · 2011 → 2026

01 Case · Cryptobind

"In BFSI and GovTech, credibility is the conversion event."

The engagement

Data-protection and cryptography suite from JISA Softech, India's first indigenous OEM of Hardware Security Modules — deployed with India's largest public-sector insurer to protect 30+ crore PII records.

Why it stayed with us

When you sell into deeply technical CISO and compliance teams, the buyer's first question is not "what does this do?" — it is "can I trust the people who built it?" Compliance badges, provenance and clear technical documentation move deals further than any hero animation. We now default to "receipts-first" design on regulated-industry sites: every claim answered by a document, every feature answered by a compliance mapping.

02 Case · Bingo Card Creator

"Speed to first artefact is the loyalty loop for consumer utilities."

The engagement

A long-running consumer web app used by teachers, event planners and community organisers to design and print custom bingo cards or run virtual bingo games — now serving 550k+ users worldwide.

Why it stayed with us

The teacher who found the site five minutes before class does not want to sign up. She wants a printable card. Every second we removed from "landing page → printable card" moved retention. Template libraries, AI word generators, live-play modes — all of it is scaffolding around that one metric. Consumer utilities do not earn loyalty on their landing page; they earn it in the two minutes between arrival and artefact.

03 Case · Wordsquared

"Games are systems where the interface is the game."

The engagement

The world's first massively-multiplayer online crossword game — a Scrabble-style tile game played on a shared, effectively infinite board with real-time multiplayer, later selected as a Google Chrome Experiment.

Why it stayed with us

A 48-hour prototype that went viral and had to become a live product. What we learnt is that in a game, every UI decision is a rules decision. Change the way a tile drops onto the board and you have changed the strategy. Change the way the map scrolls and you have changed what "position" means. This is not true of most software; it is true of every game. Designing the interface and designing the ruleset are the same job.

04 Case · Prime Staff

"Two-sided marketplaces need two homepages."

The engagement

A staffing and manpower business serving employers across sectors in India — a credibility site that also acts as a two-sided funnel for employers looking for talent and candidates looking for roles.

Why it stayed with us

Every two-sided marketplace we have built has tried, at some point, to solve the problem with one homepage and two buttons. It never works. Employers wanted to size up the firm's reach; candidates wanted to know whether it was worth submitting a CV. The moment we split the entry paths — separate "Hire" and "Apply" tracks off the homepage, separate copy, separate proof — submissions on both sides went up. One homepage, two buttons is a compromise no visitor asked for.

05 Case · ISKCON Kopargaon Shirdi

"Non-profit and devotional sites live or die by ease of participation."

The engagement

The official website for ISKCON Kopargaon, an extension centre of ISKCON Juhu located moments from Shirdi in Maharashtra, serving devotees, pilgrims and college students.

Why it stayed with us

For a temple site, aesthetic decisions are the small game. The big game is how many taps sit between intent and contribution. When a pilgrim decides to donate to Annadaan or register for a Gita Life program, every extra field, every unnecessary confirmation, every payment method that fails silently is a person who does not participate. Removing friction from participation mattered more than any visual choice we made.

06 Case · JTS Rental

"In vehicle rentals, the calendar is the product."

The engagement

A truck rental operator running the entire business — from reservation to return — off custom rental software with per-truck calendar management.

Why it stayed with us

Every other feature — pricing, contracts, insurance, maintenance — hangs off the calendar. Any inconsistency in the calendar cascades into a customer disappointed at the counter, or a truck sitting idle when a booking was possible. We built the calendar as the immovable core and treated every other feature as a consumer of it. It is the difference between a rental system that scales and one that quietly loses ten percent of its available inventory to double-bookings and phantom holds.

07 Case · T-TMS Agentic Mailer

"The wrong-order guard is the single most important safety rail."

The engagement

An autonomous AI agent built on top of T-TMS for freight brokers. Runs the end-to-end brokerage workflow — email classification, load matching, carrier scoring, rate offers, negotiation — and books loads in T-TMS when carriers accept.

Why it stayed with us

An agent that occasionally books the wrong load is not a shipping product; it is a lawsuit. The wrong-order guard — a hard stop that refuses to book if an explicit order ID lookup fails — is the difference between an agent you trust and an agent that gets switched off after the first bad booking. In agentic systems, the interesting engineering is not in what the agent can do; it is in what the agent is not allowed to do. Model choice matters less than guardrail design.

08 Case · Manuscripts.ai

"Authors want the AI to refuse more than they want it to generate."

The engagement

An author-first AI manuscript editor for novelists, screenwriters and playwrights. Built on Gemini 2.5 Pro with a "Pad" brainstorm surface that is deliberately walled off from the manuscript itself.

Why it stayed with us

Twenty-five discovery interviews with working authors surfaced the same fear repeatedly: they wanted guardrails more than capabilities. The most-praised feature across feedback was not any AI capability — it was the wall between the brainstorm surface and the manuscript. The top writer held 300k words while making zero AI calls, telling us the editor itself (typography, structure, focus mode) solved the real need. In writer tools, adoption is a shape, not a number: refusal is a feature.

The pattern underneath the receipts.

Read the eight lessons back-to-back and one pattern repeats — the same one that closes the case-studies brochure itself. The software we ship earns its place by removing friction from a specific job — booking a load, printing a bingo card, closing a lending file, catching a caries — and by leaving a clean record of every decision it took to get there.

The job is always specific. The record is always specific. That is what a receipt is. Fourteen years of them is what we have.

If any of the eight lines above sound like the shape of what you are trying to build, that is usually a good signal. Send us the paragraph.