DMFUDaily Mess For U

01

Two applications, one problem

A mess is where a great many students and working professionals in India eat daily: a kitchen serving a fixed menu at a fixed price, generally on a monthly plan. Identifying a good one is a matter of word of mouth, and administering one is typically a paper record.

DMFU addresses both halves. One application serves the people eating — search what is nearby, review the menu, compare the price and the ratings, then subscribe. The other serves the kitchen, which administers its own listing, menu and plans through it.

02

What the finder provides

The application is structured around how a person actually selects a mess: proximity, budget, dietary preference, and recent reputation.

• Nearby messes ranked by ratings from people who have eaten there.
• Vegetarian and non-vegetarian filtering, which for many users is the first criterion rather than a preference.
• Full detail before committing: address, photographs, menu, pricing and plan options.
• Daily meals or a subscription, according to the user’s schedule and budget.
• A Mess Pocket wallet, topped up with coupons and redeemed at the counter.
• Notifications when a mess opens or closes, so no one travels to a closed kitchen.
• Meal ratings, which are what keep the rankings meaningful.

03

The second application, for the kitchen

Everything the finder displays has to originate somewhere, and that somewhere is a person running a mess with no particular interest in software. The manager application is therefore deliberately the smaller of the two: it performs the few operations that keep a listing accurate, and nothing further.

The pairing is what makes the product function. An unmaintained listing becomes inaccurate within a week, and an inaccurate listing is worse than none, because it directs someone to a kitchen that closed an hour earlier.

• The listing itself: name, address and photographs — what a prospective customer sees first.
• The menu and the pricing, which change more frequently than anything else.
• The plans offered, daily or monthly, so the finder can display the cost.
• Open or closed status, which drives the notification a subscriber receives.
• Coupons redeemed at the counter against a subscriber’s Mess Pocket.
• Ratings and feedback as they arrive, which is what keeps the rankings honest.

04

Migrating a live database without data loss

The production database used a legacy schema that no longer fitted the product. Changing it meant moving live records belonging to users who would open the application the following morning regardless.

I wrote the migration in Python specifically for this data, rather than adopting a general-purpose tool that would have required the data to be more consistent than it was. Every existing user record was preserved. No one signed in to find a subscription missing, which is the only measure by which a migration succeeds.

05

The infrastructure behind the applications

An application on a phone is the visible half. The other half was an Ubuntu VPS I owned outright: Apache, SSL automation so certificates renewed without intervention, and domain routing.

The component worth noting is the shell tooling — automated backups, and health checks capable of restarting what they found unresponsive. A food application has a firm daily peak at lunch and dinner, with no one available to intervene. Self-healing was not an enhancement; it was the on-call arrangement.

06

Two Play Store releases

I designed the interface in Figma before implementation, which is the least expensive point at which to discover that a screen does not work.

The full Play Store path followed for both applications: signing, versioning, a staged rollout rather than a release to the entire user base at once, and crash monitoring afterwards. Releasing to a store is a different discipline from deploying a server — a defective build cannot be withdrawn from a user’s device, so the staging is the safeguard.