Websites & Web Apps
Websites, landing pages and web apps
Three terms get used interchangeably in proposals, and the confusion costs clients time. This page separates them: a business website presents information, a landing page focuses on a single action, and a custom web application does work with logins, data, and business rules.
Why the distinction matters before you sign anything
The effort involved is different for each category. A website is mostly a content and design exercise. A web app is a software project, with everything that implies: testing, access control, data handling, and ongoing development after launch. A landing page sits closer to the website end of that range, but it carries a narrower job and usually a campaign deadline.
Proposals often blur the three together, which makes comparing them difficult. If two quotes describe the same deliverable in different words, the scope — not the total — is where you will find the real difference.
A quick first read
- Website
- Presents information and contact details
- Landing page
- Drives one specific action
- Web app
- Stores data and runs a process
The short version
Start with the tasks your staff or customers repeat. The answer names the build.
Chapter one
The business website
A business website introduces your company, describes what you offer, and gives visitors a way to get in touch. Typical pages include a home page, an about page, a services or products section, and contact details. Some sites add a blog or news section for updates.
- Content and design lead the work; there is little logic to test.
- Most sites run on a content management system so staff can edit text and images without a developer.
- The build is usually measured in weeks rather than months.
WordPress is a common choice for this category, particularly for SMEs that need frequent updates and lower maintenance complexity. It is not the only option — the important question is who edits the site after launch and how often. If the answer is "someone in the office, every week," a managed content platform saves more time than it costs.
Budget the content, not just the build. Text, images, and page structure usually arrive later than planned, and that delay sits outside the developer's control. A site with twenty well-written pages ships faster than one with six pages that are still being drafted.
Chapter two
The landing page
A landing page has one job: get the visitor to take a specific action, such as filling in a form, booking a slot, or downloading something. It usually sits outside the main site navigation, often as part of an advertising or campaign link, and it removes the distractions that would pull attention away.
Where it lives
Separate from the main menu. A visitor arrives from an ad, a campaign email, or a QR code and sees one page with one destination.
What it removes
Navigation, sidebars, and any link that leads somewhere other than the intended action. Fewer exits, clearer focus.
What improves it
Testing. Small changes to headings, form length, and button wording are common, and they are cheap to run once the page exists.
When you need several
If you run more than one campaign, you will likely end up with several landing pages sharing a common structure. Build the first one properly and the rest follow quickly.
Chapter three
The custom web application
A web app is software that happens to run in a browser. It handles logins, roles, data, and rules. Examples include a booking system, a customer portal, an internal approvals tool, or a quoting engine that connects to your accounting software. Users interact with it, and it does something with the result.
Because it stores and processes data, a web app needs more than design work. Access control, validation, backups, and error handling all need to be planned before the first screen is built. On the back end, teams commonly use Laravel or Django for this kind of build.
What a web app usually includes
- Accounts and roles, so different people see different parts of the system.
- A database with a clear structure and a plan for backups.
- Validation and error handling, so bad input does not corrupt records.
- An agreed cycle for changes after launch, because workflows rarely stay still.
Chapter four
Deciding which one you need
Start with the tasks your staff or customers repeat. The wording of the answer points to the build:
What the task sounds like
The fit
What that implies
"Read information and contact us."
Business website
Content pages, a contact route, and a way for staff to edit text.
"Take one action from a campaign."
Landing page
A single page, one form or booking, and a testing routine after launch.
"Log in, enter or retrieve data, and follow a process."
Custom web app
Roles, a data model, integrations, and a support cycle after launch.
Mixed cases exist, and they are more common than the clean versions above. A business website with a customer login area is part website, part app. In that situation, expect two phases of work rather than one: the public pages first, then the signed-in area with its own data and rules.
Say so at the start if you suspect a mixed case. Splitting the work into phases is easier to estimate than treating a hybrid as a single deliverable and discovering the gap halfway through.
Chapter five
Responsive design across all three
Responsive design means the layout adapts to the screen it is shown on. It applies to every category on this page — the website, the landing page, and the web app.
In Singapore, a large share of traffic to business sites comes from phones. Building desktop-first and adjusting later usually costs more than designing for small screens from the start, because the adjustments touch spacing, navigation, and form layout together.
Check forms on a phone
Long forms with many fields are harder to complete on a small screen, and that affects whether visitors finish them. Where a form can be shorter, making it shorter is usually worth more than any visual change.
Chapter six
When a template is enough
Not every project needs custom development. Templates and site builders can produce a credible business website quickly and at lower cost. They are a reasonable choice when your requirements are standard: a handful of pages, a contact form, and a blog.
Custom work starts to make sense when you need a specific workflow, an integration with an existing system, unusual content structures, or full control over performance and accessibility. The platforms and frameworks page describes the tools involved in each case.
Chapter seven
Integrations and APIs
API integration is how a website or app talks to other software: payment providers, CRM systems, email platforms, or internal databases. Each connection adds a dependency. If the external service changes its interface, the integration may need updating.
Ask which integrations are in scope, how they are tested, and what happens if a third-party service is unavailable. A short outage plan is worth agreeing on before launch, not after. It can be as simple as a clear message on the screen and a manual fallback for the team.
- Which connections are in scope, and who owns the third-party account.
- How each integration is tested before launch, and with what test data.
- What the site does when an external service is down or returns an error.
Every connection is a small ongoing responsibility, not a one-time task. Plan for who checks it after launch.
Chapter eight
What to expect on cost and time
Costs follow complexity. A landing page is the smallest piece of work. A business website sits in the middle. A custom web app is the largest, and the estimate depends heavily on how many workflows and integrations are involved.
Ask for a breakdown by stage so you can see where the effort sits, and compare proposals on scope rather than a single total. Two quotes with the same total can cover very different amounts of work.
Smallest scope
Landing page
One page, one action, and a short testing cycle. The main variable is how many versions you plan to run and how the form connects to your follow-up.
Middle scope
Business website
A set of pages, a content system your staff can use, and a responsive layout. The main variable is content readiness and how much editing the team needs to do after launch.
Largest scope
Custom web app
Workflows, roles, data, and integrations, with testing and support after launch. The main variable is how many processes and external systems are involved.
Questions we hear
Before you brief a team
Short answers to the questions that come up most often when a business is deciding between a website, a landing page, and a web app.
Can a business website grow into a web app later?
Yes, and it is a common path. Start with the public pages, then add a signed-in area when a real process needs one. The important part is planning the data and access rules before the second phase starts, so the first phase does not have to be rebuilt.
Do we need a landing page if we already have a website?
Only if you are running a campaign with one clear action. A landing page keeps attention on that action by removing navigation. If the goal is simply to inform visitors and let them browse, your existing pages already do that job.
Who edits the site once it is live?
For a business website, usually someone in your own team, which is why a content management system matters. For a web app, changes to workflows or rules typically go back through the development team, so agree a support arrangement up front.
How do we compare two proposals fairly?
Ask each team to list what is included by stage: discovery, design, build, content, testing, launch, and support. Then check the two lists side by side. The scope gaps usually explain any difference in price faster than the totals do.
Tell us what your team repeats, and we will suggest the smallest build that fits
Send the tasks, the systems you already use, and any deadline you are working toward. If a template would serve you better than custom work, that is a useful answer too.
ViewMatrix Digital · Calle Esmeralda 1025, 2340000 Valparaíso, Región Metropolitana, Chile · +65 6210 8789 · Monday to Friday, 9:00 AM – 6:00 PM