Web applications
What it takes to build a custom website that operators actually use
A public website and a custom web application share a browser. They do not share a job. This article explains what Enterprise Technology Group actually builds when a client asks for a “custom website,” and how that work connects to SaaS, mobile, and modernization.
Published 2018-06-12 · Updated 2026-09-19
Why do custom websites stall after launch?
Most stalled sites were scoped as pages, not as software. Marketing copy, a contact form, and a CMS theme can look finished in a browser. Operators then discover there is no role model, no audit trail, and no place for the work they do every day.
ETG treats a custom site as custom web application development when staff or customers must log in, update records, or move a job through states. The public pages can still exist. They sit in front of a system, they are not the system.
What should you specify before a pixel is designed?
Write the jobs: who logs in, what they must finish in under two minutes, and which systems already hold the source of truth. Those three answers decide tenancy, auth, and whether you need a site, a SaaS platform, or a staged modernization of something that already works.
If the answer is still fuzzy, run the ungated software scope estimator. It does not replace a discovery call. It keeps the first conversation on surfaces and constraints instead of a generic brochure rebuild.
| Signal | Brochure site | Custom web application |
|---|---|---|
| Login | Optional, if any | Named roles with permissions |
| Data | Pages and media | Records that change during the workday |
| Success metric | Traffic | Time-to-complete a real job |
Continue with the software scope estimator, software development services, or request a project quote.