Most data models used in Indian software were inherited from Western frameworks and encode assumptions that do not hold here. The failures are individually small and collectively constant: a name that will not save, an address that cannot be delivered to, a phone number rejected as invalid. Each generates a support ticket, and each is entirely avoidable at design time.
Names first. A required last name field excludes a substantial number of Indians who use a single name — common in parts of South India where a given name may be preceded by initials expanding to a father's name and a village. Initials with full stops break validators that expect only letters. Names are longer than Western fields anticipate, and they exist in multiple scripts. The safe design is one required full-name field storing the name as the person writes it, with optional structured fields only if you have a genuine use for them, and never a first-name field used in greetings that produces something the person does not recognise as their name.
Addresses are worse, because the Indian address is fundamentally different in structure. It is frequently relational rather than absolute — a building name, a floor, a landmark, an area, a locality — and the landmark is not decorative. It is how the delivery actually happens. A form with two address lines and no landmark field forces users to jam it into a line that downstream systems truncate, and the parcel does not arrive. PIN codes are six digits and may begin with any digit, so no integer type and no leading-zero stripping.
The PIN code carries more information than teams realise and is worth using properly: it maps to a locality and a state, so validating city and state against it catches a large proportion of address errors before dispatch rather than after. Building that check into the form saves more delivery failures than almost any other single intervention.
Phone numbers should be stored as strings, with the country code, and normalised to a canonical form on write. Indian mobile numbers are ten digits with a limited set of leading digits, but users enter them with a leading zero, with a plus-nine-one, with spaces and with hyphens, and all of those are the same number. Storing them unnormalised means the same customer appears three times and none of your lookups work. Landlines carry variable-length STD codes, so any validation assuming a fixed total length will reject legitimate numbers.
Two final ones that catch teams out. Financial years run April to March, so any reporting period, fiscal quarter or year-to-date calculation copied from a foreign codebase will be wrong by a quarter and nobody will notice until an accountant does. And the Indian digit grouping system uses lakhs and crores with different comma placement, so a figure formatted by a default locale library reads as unfamiliar to the person checking it. Neither is difficult; both are invisible until someone complains.
