Website vs Web App vs Custom Software: Which One Are You Paying For?

A website, web app and custom software can all live in a browser. That is why buyers confuse them. The difference is not the screen. The difference is what the system must do. A website mainly explains, builds trust and captures enquiries. A web app lets users log in, enter data, make choices and complete tasks. Custom software can include web apps, dashboards, integrations, workflows, rules, permissions and reporting.

The budget changes because the responsibility changes. A normal business website may need strategy, design, copy, SEO, forms and analytics. A web app may need authentication, database design, user roles, validation, dashboards and testing. Custom software may need discovery, process mapping, integrations, security, support and ongoing development.

The custom software cost page shows current figures of KES 150,000 for discovery, KES 600,000 for an MVP web application and KES 1,500,000 for a larger custom platform. Those figures are not comparable to a simple website because the work is not the same.

A business website explains who you are, what you offer, who you serve, why buyers should trust you and how they can take the next step. It may include a homepage, service pages, about page, contact page, blog, pricing guidance, case studies, landing pages and forms. Its main job is communication.

A website can still be strategic and valuable. It can support SEO, Google Ads, referrals, hiring, tenders, credibility and lead generation. But most visitors are not logging in to manage a workflow. They are reading, comparing, trusting and contacting the business.

A web app lets people do things. Users may log in, submit records, view dashboards, manage bookings, update profiles, track orders, approve requests or download reports. The interface is not only presenting information. It is accepting input, storing data and changing state.

This requires deeper planning. The team must define user roles, permissions, data fields, validation rules, notifications, statuses, admin screens, error states and support needs. A button that saves information is more expensive than a button that opens a contact form because it creates a responsibility around data.

A web app can still have public website pages. Many businesses need both: a marketing website for visitors and a web app for customers, staff or partners.

Custom software goes beyond a single interactive feature. It models the way a business works. That could be a CRM, school admissions system, SACCO member portal, order management system, reporting dashboard, booking workflow, internal approval process, supplier portal or ecommerce operations tool.

The cost is higher because the project has to understand the real process. Who starts the workflow? Who approves? What data is required? What happens when something is rejected? Which notifications go out? Which report does management need? Which systems must connect? What should happen when a user makes a mistake?

• Custom software needs process mapping before development.
• User roles and permissions must be clear.
• Data structure affects reporting and future changes.
• Integrations need testing, error handling and support.
• Post-launch changes are normal because real users expose edge cases.

Not every project fits neatly into one box. A real estate website with property listings may be mostly a website with a structured catalogue. A school website with application forms may be a website with workflow features. An ecommerce store may be a website, a store platform and an operational tool at once.

The quote should identify which parts are content pages and which parts are functional systems. A page explaining admissions is website work. A portal that lets parents submit documents, track status and receive updates is software work. A product page is ecommerce content. A stock sync or supplier dashboard is software.

Software has more ways to fail. A website page may have a typo or broken layout. Software can save wrong data, expose private information, block users, duplicate records, break an integration, send the wrong notification or produce misleading reports. More risk means more planning and testing.

Software also needs a longer life plan. Users will ask for changes after launch. Reports will evolve. Workflows will need exceptions. Security and hosting must be monitored. Integrations may change. The first launch is rarely the final version.

When a business needs software, the first version should usually be an MVP rather than the full dream system. An MVP is the smallest useful version that solves one important workflow. It lets the business test real usage before spending heavily on every possible feature.

MVP planning is not about building something weak. It is about choosing the first release carefully. The MVP might include one user role, one workflow, one dashboard and one integration. Later phases can add automation, reporting, payment logic, notifications or more user types once the core value is proven.

This is why discovery matters. Discovery helps the team decide what belongs in the first build and what should wait. Without it, custom software projects often overbuild early and underfund the parts that make the system reliable.

Discovery is the paid thinking work before full development. It can feel slower than jumping straight into design, but it often saves money because it exposes assumptions early. A business may discover that a better website and a structured form solve the first problem. Another business may discover that it needs a staff dashboard, approval workflow and reporting before any public website changes matter.

Good discovery maps the current process, identifies users, lists decisions, separates must-have features from later ideas and defines the first release. It also checks constraints: existing tools, budget, data quality, hosting, security, integrations and who will manage the system after launch. This prevents a proposal from becoming a wish list with no delivery discipline.

For buyers, discovery also makes quotes easier to compare. Instead of asking suppliers to guess the cost of a vague platform, the business can ask for a defined MVP. That MVP might still evolve, but the starting point is grounded in real workflow decisions.

Discovery can also reveal when the business should not build software yet. Sometimes the immediate issue is unclear responsibility, poor data, weak forms or a missing reporting routine. Fixing those may cost less than building a full system. Other times, discovery proves that the manual process is costing enough time and errors to justify software. Either outcome is useful because the budget follows evidence instead of excitement.

• Map the current manual process before designing screens.
• Name each user role and what that role can see or do.
• Decide the first workflow the system must handle well.
• List integrations, reports and automations that can wait.
• Define support and maintenance expectations before launch.

WordPress can handle many business websites and some structured content needs. WooCommerce can handle ecommerce. Shopify can handle managed retail workflows. A custom application can handle unusual data and workflows. The buyer should avoid choosing technology before defining the job.

If a standard tool fits the work cleanly, use it. If the business keeps fighting the tool, custom development may be justified. The expensive mistake is forcing complex operations into a cheap plugin setup, then paying repeatedly to patch problems that should have been designed properly.

Compare platform decisions with the WordPress vs custom website guide before approving a build.

A buyer does not need to know every technical term. The right questions will show whether the project is a website, a web app or custom software.

• Will users log in, or will visitors only read and contact us?
• Will the system store records, orders, applications, bookings or customer data?
• Are there different user roles with different permissions?
• Does the workflow have statuses, approvals, notifications or exceptions?
• Does the system need to connect with payments, SMS, email, CRM or accounting tools?
• What reports or dashboards should management see?
• What happens after launch when users request changes?

If most answers are no, you may only need a strong website. If several answers are yes, the quote should be treated as software scope, not ordinary web design.

Start with the business problem, not the tool name. If the problem is weak trust, unclear services or poor lead capture, improve the website. If the problem is manual work, scattered records, repeated approvals or poor visibility, explore software. If the problem is selling products online, start with ecommerce and only add custom software when store operations demand it.

Ask for the proposal to separate public website pages, user-facing app screens, admin dashboards, integrations, data migration, hosting, support and future phases. That separation makes the cost easier to judge and protects the project from vague expectations.

Paying for the right thing is not about choosing the most expensive option. It is about matching the budget to the job. A focused website can be smarter than unnecessary software. A planned MVP can be smarter than pretending a complex workflow is just another website page.