Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteenThe business lists products, menu items, or services with descriptions that sell the benefit, not just the specs.
Works with
What it does
The user enters raw product details (name, ingredients or materials, price, key feature), and Lekha writes a description sized for the target listing (e-commerce page, menu card, catalog). Bulk mode lets the user upload a spreadsheet of many items and generate descriptions for all of them in one pass.
A furniture retailer uploads a spreadsheet of forty new sofa listings — dimensions, fabric, price — and needs forty descriptions that sell the look and comfort, not just repeat the spec sheet, before the online catalogue launches this weekend. Writing each one by hand at that volume simply won't finish in time, and a thin row in the spreadsheet is exactly where a generated description is most tempted to guess.
This writes descriptions sized for the target listing — an e-commerce page, a menu card, a catalogue entry — from whatever product details are supplied, and a bulk mode processes an entire spreadsheet in one pass rather than one item at a time. Every description still needs to be checked against the row it came from before the catalogue goes live.
Lekha runs this directly on the platforms your customers already use — no separate app for them to install.
How it works
Supply the raw facts — name, materials or ingredients, price, a key feature — either one item at a time or as a spreadsheet of many rows for the retailer's entire new sofa collection at once.
Pick where this description will actually appear — an e-commerce page, a printed menu card, a catalogue — since the length and structure needed differ across those formats significantly, and a description built for one rarely reads well pasted unedited into another.
For a spreadsheet upload, each row is processed individually with progress tracked and any row that fails flagged clearly, rather than the whole batch stalling silently on one problematic entry buried somewhere in the middle of a long list.
Each generated description is returned tied to its source row, making it straightforward to check the finished text against the original details supplied before anything is published live, particularly wherever a row's original detail was thin or partly missing to begin with.
Why it matters
The furniture retailer's full new-sofa upload gets processed in one bulk pass instead of someone typing forty descriptions by hand before Monday's launch deadline, with each one still worth a quick check against its own row.
A description written from raw dimensions and fabric details reads as something that sells the comfort and look, rather than a re-typed version of the spec sheet a customer already has.
A row that fails to generate correctly during a bulk run is flagged individually, so it can be fixed and rerun without needing to redo the entire batch from the start.
The detail
The single biggest risk with bulk description writing is a sparse input row. When a spreadsheet entry has a name and a price but no material, dimension, or ingredient listed, a model asked to write a full, appealing description will often invent a plausible-sounding detail to fill that gap — a fabric that sounds right, a dimension that reads believably — because a confident gap-fill looks more finished than an obvious hole. This is a known and real risk, not a rare glitch, and it scales with volume: forty thin rows means forty chances for an invented detail to slip into a live listing a customer might act on directly.
The practical response is checking each description against its actual source row before publishing, and this matters more, not less, at bulk scale — the temptation with a forty-item batch is to skim the output and trust that it's fine because it reads well, but reading well and being accurate to the supplied facts are different things a fast skim won't reliably distinguish. A spot-check habit — comparing at least the material, dimension, and price fields against the source row — catches this before a customer receives a sofa that doesn't match its listing.
Cost also scales linearly with row count here in a way worth planning for before running a very large batch — a job across several hundred items uses proportionally more processing than a single item, and estimating that before committing avoids an unpleasant surprise partway through a launch weekend.
Industry use cases
6 industries where Lekha applies this directly.
A used-car dealer pastes the make, model, year, and mileage for a new arrival, and Lekha drafts a listing description plus a short social caption, both flagging that any claim about condition or history beyond the given facts needs the dealer's own confirmation before posting.
See the automotive playbookA skincare brand uploads its full product line as a spreadsheet with ingredients and benefits per item, and Lekha generates a description and a caption for each product in one bulk run instead of one at a time.
See the beauty and cosmetics playbookA furniture retailer uploads a new collection's specs and Lekha drafts descriptions for the e-commerce listing plus a matching Instagram caption set, keeping material and dimension details exactly as supplied.
See the home decor and furnishing playbookA broker pastes a property's square footage, bedroom count, and location, and Lekha drafts a listing description and a short email to interested buyers, both built strictly from the supplied facts.
See the real estate playbookA restaurant launching a new seasonal menu pastes the dish names and ingredients, and Lekha generates a description for each dish plus a launch-announcement caption, ready to review before the menu print deadline.
See the restaurants and food playbookA day spa asks Lekha to write copy for a new facial package, and Lekha drafts the description but flags a line implying a specific skin-improvement result as needing the owner's confirmation before it's used in an ad.
See the spas and salons playbookMore from Lekha
The business gets copy that consistently sounds like them, in every language, without re-explaining tone in every prompt.
Learn moreThe business drafts a usable first version of an ad, caption, email, or product description in seconds instead of starting from a blank page.
Learn moreThe business can dial a single draft from formal to playful (or vice versa) without rewriting it from scratch.
Learn moreThe business reaches Hindi-speaking and code-mixed audiences with copy that reads naturally, not like a literal translation.
Learn moreThe business turns one piece of English copy into ready-to-use versions in other languages without hiring a translator for routine content.
Learn moreThe business gets a blog post or landing page draft built around a target keyword, ready to publish with minimal editing.
Learn moreQuestions
The model can fill that gap with a plausible-sounding invented detail rather than leaving it blank, because a description with every field filled in looks more finished than one with a visible gap. This is a real risk at bulk scale specifically — the fix is either supplying more complete data upfront or checking each generated description against its source row for exactly the fields that were thin or missing to begin with.
A full check is safer, but at minimum a spot-check comparing the material, dimension, and price fields in each description against the original spreadsheet row is the practical middle ground. The risk of an invented detail scales with how sparse the source data was, so rows that had less information to begin with deserve closer attention than ones that were already complete and specific.
Yes, the same underlying details can be formatted for different target listings — a menu card typically needs something shorter and more evocative than a full e-commerce product page does. Choosing the right target format per description matters, since a description written well for one format can read oddly short or oddly long if simply reused unedited for the other.
That specific row is flagged individually rather than stalling or silently skipping the rest of the batch, so the retailer can see exactly which item needs attention and fix or resupply that row's data before rerunning just that one entry. The rest of the successfully processed batch isn't held up waiting on the one problematic row to be resolved first.
The rest of your stack
No rip-and-replace — write product & menu descriptions works alongside the systems already running your business.
Coming soon
