ViewTech Digital · Singapore
How websites and apps are built
There is no single correct way to build a digital product. The approach you pick shapes cost, timeline, and how easy the system is to change later.
This page sets out the main options used in Singapore projects and the situations each one tends to suit. Read it as a comparison, not a recommendation: most products end up combining two or three of these routes, and the useful question is which one carries the least unnecessary weight for what you are asking people to do.
Six routes appear below, from a hosted template through to software written for one business. Each entry covers what the route is good at, where it runs into limits, and the kind of project it usually fits.
The six routes
Comparing the ways a site or app gets built
Template and content-managed websites
Fastest route to a public presence. Choose a theme, arrange pages, publish. Suits a company profile, a service listing, or a small ecommerce store with a limited catalogue. The trade-off: you work inside the platform's structure, and unusual layouts or workflows become awkward. For many small businesses this is still the sensible starting point, and it can be replaced later without losing your content.
Custom software development
The system is written for your process rather than adapted from someone else's. Suits businesses whose workflow is genuinely different, or whose competitive edge sits in how they operate. Expect a longer discovery phase, because the team has to understand the rules before writing code, and expect higher upfront cost. In return you get a system that fits, and a codebase you can extend as the business changes.
Web app development
A web app runs in the browser but behaves like software. Users log in, see their own data, and complete tasks. Common examples include booking systems, internal dashboards, and customer portals. This is often the right first step because it works on any device with a browser and updates instantly for everyone. If your users are mostly at desks, or need to check something quickly, it is usually more practical than a mobile app.
Native apps
Written separately for iOS and Android, using the tools each platform provides. That means two codebases and two development tracks, which raises cost. The benefit is full access to device features: camera, sensors, background processing, and smooth animation. Native apps also tend to feel more responsive. Choose this route when performance or hardware access is central to the product, not as a default.
Cross-platform apps
One codebase runs on both major mobile platforms. Frameworks in this space have matured, and for many business apps the difference in feel is small. The practical advantage is one team, one release process, and lower long-term maintenance. Some deep hardware integrations still need platform-specific code, so the approach works best when the app is mostly about data, workflow, and interface.
Hybrid apps
A hybrid app wraps web code inside a mobile shell, so the same pages appear in an installed app. It is a pragmatic option when you already have a web app and want a presence in the app stores without a full rebuild. The limits show up in animation, offline behaviour, and access to newer device features. Treat hybrid as a bridge rather than a destination, unless your requirements stay simple.
Rows are listed by how much of the work has to be designed from scratch, not by quality.
Ecommerce store choices
An ecommerce store sits between template and custom. A hosted platform gets you selling quickly with standard checkout, inventory, and shipping. A custom store gives you control over catalogue logic, pricing rules, and integrations with your own systems. In Singapore, a common pattern is to start on a hosted platform and move to custom once order volume or unusual fulfilment requirements make the platform restrictive.
Two details decide most of these cases. First, whether your catalogue is a fixed list of standard products or a set of rules that changes what a customer sees. Second, whether fulfilment follows a courier template or needs its own steps, such as local pickup, scheduled delivery windows, or stock held in more than one place. A hosted platform handles the first version of both without much configuration; the second version usually pushes you toward custom work.
What to write down before you choose
- The two or three tasks customers must finish on the site.
- Whether pricing, stock, or availability changes per customer.
- Which existing systems the store has to talk to, and how often.
- Who edits the catalogue after launch, and how often.
Choosing between them
Match the approach to the job. Information on a phone: a responsive website. Accounts and workflows: a web app. Hardware-heavy features: a native app. Both platforms, business logic, limited budget: cross-platform.
The mistake to avoid is starting with a technology decision before the user problem is clear. Write down what people need to do, then pick the approach that carries the least unnecessary weight.
Mixing approaches
Few real products use one approach alone. A business might run a marketing website, a customer web app, and a cross-platform mobile app, all sharing a single back end. Systems integration ties these together so data stays consistent. Planning the shared parts early, such as user accounts and the database, saves significant rework. It also means a later mobile app can reuse the same foundation instead of starting again.
Shared accounts
One login that works across the website, the customer portal, and the mobile app. Deciding this early avoids rebuilding user records when the second product arrives.
One database
A single source of truth for orders, customers, and content. Duplicated data across products is the most common cause of later reconciliation work.
A clear integration layer
The rules that move data between the back end and each front end. Kept separate, a new mobile app can plug in without touching the website.
Where the approaches meet
Web apps, cross-platform apps, and custom stores all share the same practical concern: keeping one set of business rules while more than one interface talks to it. That is why the choice of build approach and the choice of technology stack tend to be settled together, not one after the other. The technology notes on this site go through the stack decisions in the same plain terms used here.
Write down what people need to do before anyone chooses a technology.
A build approach is a consequence of the user problem, not a starting point. Teams that name the tasks first spend less of the project reworking decisions that were never necessary.
Questions readers ask
Short answers to the points that come up most often when people compare these routes.
Can a template site be replaced later without starting over?
Usually yes, if the content is stored in a way you can export. The pages, product records, and text are the valuable part; the theme is not. What gets lost is the specific arrangement of the theme, so a replacement means rebuilding the layout while keeping the material you have written.
Do we need a mobile app if we already have a web app?
Not automatically. A web app reaches any device with a browser, including phones, and updates for everyone at once. A mobile app earns its cost when people need offline access, push notifications, or camera and sensor features that a browser handles poorly. If none of those apply, the web app is doing the job.
Is cross-platform always cheaper than building two native apps?
For business apps that lean on data and workflow, one codebase usually means less to build and less to maintain. It stops being the cheaper option when the product depends on deep hardware behaviour on both platforms, because that work still has to be written twice inside the shared project.
When does a custom store make sense over a hosted platform?
When the catalogue stops behaving like a list. Rules that change prices per customer, stock held in several places, or fulfilment steps the platform does not offer are the usual triggers. Until then, a hosted platform with standard checkout and shipping is faster to launch and easier to run day to day.
How much of this should be decided before talking to a team?
Enough to describe the tasks and the constraints. You do not need to name a framework, but you should be able to say who uses the product, what they do on it, what it must connect to, and roughly when it is needed. Those four answers let a team give you a useful response instead of a general estimate.
Where to go next
The rest of this resource follows the same sequence: what you build on, how long the work tends to take, and how to tell development companies apart when you start comparing them.
Comparing development companies
Build approaches are only half of the decision. The other half is the team doing the work, and the questions worth asking are practical: how they run discovery, who writes the code, how they hand it over, and what happens after launch.
Compare development company types
Corridors and glass make up most of what visitors actually see of a development team before a first meeting.
Still weighing two approaches?
Write out the tasks your users need to complete and bring them along. A short conversation is usually enough to say which route fits and which parts you can postpone. Reach us Monday to Friday, 9:00 AM – 6:00 PM, at [email protected] or +65 6746 4680.