Most build or buy decisions are made between two options that both fit someone else. A packaged tool fits the company it was designed around. Full custom software fits a larger company with a longer timeline and a bigger budget. The business in the middle, the one actually making the decision, often ends up with neither, and keeps running on the workaround it already has.

This is the web edition of a short Mobilio Asia whitepaper on choosing the platform a business runs on. The designed seven page version is readable on our LinkedIn page.

The problem: most operations already run on a workaround

Walk into many growing businesses and the real system is not a system at all. It is a spreadsheet, a stack of paper forms and a chat group. Between them they hold orders, appointments, stock counts and customer details, and they work well enough until the business grows past the people who know where everything is.

When the time comes to replace that, the choice is usually framed as two doors. Buy a packaged tool and adapt the business to its screens. Or commission full custom software and carry the cost and the timeline of a much larger project. What both framings tend to miss is the workflow the business actually runs today, which is the thing the new system has to support on day one.

Why it is hard: both obvious answers cost you later

  • A packaged tool bends the business to its screens. The parts that do not fit get handled outside it, which is how the spreadsheet survives the rollout.
  • Full custom software is scoped for a larger company and a longer timeline. Everything is designed from a blank page, including the parts every business needs in the same shape.
  • When neither fits, the spreadsheet stays. The decision gets postponed, and the workaround quietly becomes permanent.
  • Staff drop an interface that overwhelms them. A system that is technically complete but hard to use on a busy day is a system people route around.
  • A wrong first choice means moving the data twice. Once into the tool that did not fit, and again out of it.

What good looks like: your workflow, without starting from zero

There is a middle path between adapting to someone else's product and building everything from scratch. In practice it has five properties:

  • One record, reachable from a desk, a phone or the field. Data is centralised, and the people who need it can reach it from the device in their hand.
  • An interface built for operational simplicity. A modern interface that does not overwhelm the staff who use it every day.
  • Scoped to the units the business actually runs on. Not a feature list, but the specific jobs the business cannot stop doing.
  • A first release measured in weeks. Not months, and not a long programme before anyone sees anything work.
  • The next release adds to the same system. Growth means adding a module, not replacing what is already running.

How Mobilio approaches it: scope by module, build only what is new

Mobilio Asia scopes client applications by module, where each module is a functional unit with a known place in the system. The shape of a typical first release:

  • A base that every build needs: user login and profile management, company information and a product or service catalogue.
  • Up to three modules to start, chosen from the jobs the business runs on, such as appointments, orders and tracking, payments and checkout, or inventory.
  • A web app, with a mobile app where it helps the people who use it.
  • Admin dashboards carrying the client's own branding.
  • Cloud deployment, with onboarding video walkthroughs and documentation.
  • Four to six weeks to deliver, depending on complexity.

Because the base and the modules already have a known place in the system, the weeks go on what is actually new for that business: choosing the right modules, fitting them to how it works, and putting it in front of the people who will use it.

What to ask a vendor: six questions before you sign

Whoever you talk to, ourselves included, these questions separate a system that will grow with the business from one that will need replacing:

  1. Which parts are already built, and which are new for us?
  2. Can we start small and add modules later without a rebuild?
  3. Who owns the data, and can we take it with us?
  4. Will our staff in the field use it on a phone?
  5. What happens in month twelve, when we need a new module?
  6. Is the team that builds it the team that runs it?

Where to start: the three things you run on

The most useful first step is not a requirements document. It is a short list of the three jobs the business runs on every day, the ones where the spreadsheet or the chat group hurts most. That list is usually the right first release, and everything else can be added to the same system once it is working.

If you would like to talk it through, write to contact@mobilio.asia. Mobilio Asia works from Singapore, Ho Chi Minh City and Hanoi.