Web
Moving WhatsApp orders to your own platform
WhatsApp is a good place to talk to a customer and a bad filing cabinet for orders. The message mixes with the greeting, the product photo, the question about whether it is still available, and the receipt. At the end of the day nobody can calmly say how many orders stayed open, which one was delivered and which one was paid. Migrating does not mean switching the chat off. It means the conversation stays where people already write, and the order lives on a platform with a status, an owner and a fact that does not depend on scrolling.
What breaks when the order is a chat
The queue breaks. Two people answer the same number and each thinks the other wrote down the address. Stock breaks: a product that already left is promised because the truth is on the shelf, not in the thread. The shift breaks: the morning order stays marked unread next to a new voice note. The close breaks, because building the day means rereading conversations. None of that is a fault of the phone. It is the limit of using a chat as if it were a system. While the volume fits in one person's memory, the limit does not hurt. When there is more than one shift or more than one site, it hurts every day.
What not to migrate on day one
You do not need to jump in one move to an ERP. The first useful cut is the order: who is asking, what they ask for, where it goes and which status it has. The old chat history can stay on the phone. Copying thousands of messages into a database does not tidy the operation; it tidies an archive. You also do not need to forbid WhatsApp to customers. Many will keep writing there. The new rule is internal: when the order is accepted, someone creates it on the platform. The chat stops being the only copy.
That panel, with users and data, is the kind of work described in web applications in Medellín. The published reference starts at €4,500 when there is business logic, not when you only want a page.
How the flow looks on the platform
An honest flow for an SME fits in a few statuses: received, in preparation, ready, and delivered or cancelled. Each status has an owner. The order keeps the detail that today gets lost in the voice note: products, quantities, address and a note. If there is inventory, deducting on confirm avoids promising what is not there. If there is no inventory yet, the status still helps: the kitchen or the warehouse sees a list, not a shared phone. The office can look at the day without asking for screenshots to be forwarded. The customer can still get the message on the usual channel; what changes is that the shop no longer rebuilds the order from that message.
Which stack fits
For several people and a site that is sometimes away from the shop, a web application in ASP.NET Core lets them enter through the browser, without installing a program on every phone. If the counter lives on a printer, a scanner and an unstable network, the till can be Windows Forms and the tracking panel can be web: both talk to the same data. If the person delivering is on the street, an Android app with .NET MAUI can carry the day's list. You do not have to choose all three in the first month. You do need the order to have one place. The €500 MVP can be that minimum create-order flow, and it is deducted if the project continues.
A named case, of a real web operation and with no invented metrics, is the supermarket platform. It shows a catalogue and an order on a site of your own, not a ranking of chat tools.
How to switch without stopping the day
The switch runs in parallel for a real week, not in an announcement. During those days the chat stays open and every accepted order is also recorded on the platform. The team notices which field was missing: the building, the payment method, the time. Those gaps are fixed in the scope, not with a new WhatsApp group. When the platform list matches what went out to the street, the chat stops being the source. The person who writes to the customer can still be the same person. The difference is that they look at the order on the screen and do not rebuild the sentence. Thirty days after delivery cover defects in what was built, not a second redesign of the process.
What to tell the team
The internal announcement is short. The customer can write the same way. We stop answering that it is done only in the chat when the order has not been created. Nobody loses the phone. You gain a list that survives the change of shift. If someone forgets to create the order, the failure is visible: it is not on the list. That is easier to correct than a message that scrolled up. You do not need a long manual on day one. You need a status and a person responsible for moving it.
If you want to take the order out of chat into a concrete flow, you can describe it through contact. It is enough to say who answers today, which data cannot be missing and whether stock is already controlled or not yet.
Which scope to ask for first
Ask for creating the order and the statuses, not for everything WhatsApp does. Voice notes, informal photos and the greeting can stay in the chat. If the first pain is the public page and not the operation, that is a €1,500 landing or a €2,500 site, and mixing it with the panel confuses the milestone. If the pain is the order queue, the web application reference starts at €4,500. Support at €150 a month, with no lock-in, makes sense when the panel already runs the day and you want someone for faults, not to keep writing in the group. The code is in your name when the payments are complete.
Short questions
Do we have to stop using WhatsApp?
No. Chat can stay as the conversation. It stops being the only place where the order exists.
Does the €500 MVP cover the whole operation?
No. It covers one main flow, for example creating the order. The application with users and data starts at €4,500. The €500 is deducted if you continue.
Can old chats be imported?
That is not the goal. History can stay on the phone. What gets designed is the new order, with a status and an owner.