Taking a 16-year-old grocery business online without losing its regulars

The regulars were the risk, not the technology

Morsalkım had run as a neighbourhood grocery for 16 years before we built its website, mobile app and vendor panel. The technical work was not the hard part. The hard part was that the business had built its customer relationship on a phone call and a familiar face, and any digital platform that made that relationship feel replaced, instead of extended, would cost more in lost trust than it gained in convenience.

What we left alone on purpose

We kept the phone ordering line running exactly as it had for 16 years. We built order intake so a phone order and a web order land in the same queue, on the same screen, handled by the same staff. A regular who had ordered by phone for a decade did not need to change a habit, and staff did not need to treat phone and web as two workflows with two sets of stock.

Delivery zones, not one flat radius

A grocery business runs on tight delivery windows and thin margins per order, so a single radius drawn on a map does not match reality. We built delivery zones as areas the owner controls directly, each with its own delivery slots, minimum order value and cutoff time, matching how the driving routes and staffing actually work instead of a generic circle. Zones are configuration, not code, so adding a district or a second shop later is a settings change, not a release.

The vendor panel was the real product

• Stock updates that reflect what is physically on the shelf, entered by staff who are not developers.
• Order routing between the phone queue and the web queue without double entry.
• Delivery zone and slot management the owner can change by season.
• Basic sales visibility, showing which products the online channel moves, separate from the phone channel.

The customer-facing website and app matter, but the vendor panel is what decided whether the business could run this channel without hiring someone dedicated to it. A 16-year-old business does not have spare headcount for a new digital operations role, so the panel had to work for the same staff who were already stocking shelves and answering the phone.

Matching old customers to new accounts

Sixteen years of phone orders meant sixteen years of customer records, but those records lived as a name and a delivery address in a staff notebook, and later a simple till system, not as an email address or a password. Making every regular create a fresh account before we recognized who they were would have brought back exactly the friction we were trying to avoid. Instead we matched new accounts to existing records by phone number, the one identifier that had stayed consistent for sixteen years, and let staff confirm a match by hand when the number alone was ambiguous. A regular who had called in for over a decade could start ordering in the app with their history and delivery address already there, not as a stranger to the system.

What we would not do differently

We resisted building a generic multi-vendor marketplace shell and fitting this business into it. A generic shell optimizes for onboarding many vendors fast, not for the specific delivery and stock reality of one grocery business with decades of local relationships. The app and web store were built against the vendor panel's real data model from the start, not bolted on afterward.

The lesson for other legacy businesses going online

Do not treat digitizing a long-running local business as replacing what already works. Find the specific relationship or habit the business depends on: the phone line, the face-to-face trust, the flexible delivery arrangement. Design the platform to extend that habit, not compete with it. The technology is the easy part. Protecting sixteen years of regulars while adding a new channel is the actual project.