Website vs Web App vs Custom Software

The difference in plain terms

The test is what the visitor does. If they read and then contact you, it is a website. If they log in and see or change their own information, it is a web application. If your staff use it to run the business, it is internal software. The label matters because each is scoped differently.

Signs you have outgrown spreadsheets and plugins

You have outgrown them when the workaround costs more than the fix. The usual signs are the same data typed into several systems, a spreadsheet only one employee dares to edit, customers calling for information you already have and decisions made on numbers nobody fully trusts.

This is common in Palm Beach County's operations-heavy trades: builders tracking selections and draws, marine service yards scheduling haul-outs, property managers handling seasonal owners who are out of state half the year. The business grew, the tools did not, and good people fill the gap by hand.

• The same customer details are entered in three or more places
• A key process depends on one employee's spreadsheet or memory
• Staff spend hours each week copying data between tools
• Customers call or email for status you could show them
• Errors trace back to version confusion or a missed handoff
• Plugin and subscription costs keep rising while the gaps stay
• You cannot answer a basic question about the business without a manual count

Build versus buy

Buy software for anything that works the same way in every company: accounting, payroll, email, a standard CRM, a standard store. Build only where your process is different in a way that earns you money or where no product fits without painful compromise. Most businesses should buy most things.

The middle path is often the right one: buy the standard pieces and build the thin layer that joins them. A customer portal that reads from the accounting system and the project tracker you already pay for is a far smaller project than replacing both.

When a CRM is the real answer

If the problem is that leads are lost, follow-up is inconsistent or nobody can see the pipeline, you need a CRM before you need anything custom. An off-the-shelf CRM set up properly and connected to your website forms solves this for most firms. Custom CRM work is for sales processes that standard products cannot model.

Many requests for custom software turn out to be requests for a CRM that someone actually configured. The test is whether your stages, fields and handoffs can be expressed in a mainstream product without bending the business around it. If they can, buy it. If your deals involve steps no standard tool understands, such as multi-party approvals or project-based pricing, a custom layer or a custom build starts to make sense.

When you actually need a mobile app

You need a native app when the product depends on the phone itself or on daily repeat use. Otherwise a responsive web application reaches everyone with a browser and nothing to install. Both app stores also reject thin apps: Apple and Google each publish a minimum functionality rule.

Apple's App Review Guidelines say an app should include features, content and an interface that make it more than a repackaged website, and that apps should not primarily be marketing materials, advertisements or web clippings. Google Play's policy says it does not allow apps that only have limited functionality and content, such as static apps without app-specific features.

Apple's guidelines also require its in-app purchase system when an app sells access to features or content inside the app, which changes the economics of anything sold digitally. Read the current guidelines with your developer before you commit to a store.

• It needs the camera, location, notifications or other device hardware
• It must work without a connection, such as on a job site or on the water
• Customers will open it often enough to keep it on their home screen
• Field staff need it in their hands all day
• The app offers something the mobile website cannot

What changes when you hold customer data

Once people log in or you store their records, security becomes your responsibility. The Federal Trade Commission's guidance for businesses opens with two rules: do not collect personal information you do not need, and keep it only as long as you have a legitimate business need. Design the system around both.

The FTC's Start with Security guide draws its lessons from the agency's own enforcement cases. It tells businesses to restrict access to sensitive data, limit administrative access, insist on complex and unique passwords, store passwords securely, use industry-tested methods rather than inventing their own and make sure service providers implement reasonable security.

The Cybersecurity and Infrastructure Security Agency reduces the basics for small and medium businesses to four practices: teach employees to avoid phishing, require strong passwords, require multifactor authentication and update business software. Regulated fields such as healthcare and finance carry additional obligations. Have counsel or a compliance officer confirm what applies before a portal goes live.

• Collect the minimum data the feature needs
• Decide in advance how long each kind of record is kept
• Give each user role only the access it requires
• Require multifactor authentication for staff and administrators
• Write security expectations into every vendor contract
• Keep software updated and have a plan for reported vulnerabilities

Start with the smallest useful version

Pick one bottleneck, build the least that removes it, and put it in front of real users within weeks rather than quarters. A first version that lets clients check one status or lets staff skip one spreadsheet teaches you more than a long specification and limits what you spend before you know it works.

The discipline is in what you leave out. Write down the one job the first version must do, who does it today and how you will know it worked. Everything else goes on a list for later, ordered by what users ask for once they have the tool in their hands.

This is also why a website is so often the door to larger work. The site reveals where inquiries stall, which questions repeat and what customers want to do for themselves. The next build should answer what the site has already shown you, and the one after that should answer what the portal shows you.

• Name the single bottleneck and the people it affects
• Define the smallest version that removes it
• Launch it to a small group and watch how they use it
• Measure the hours saved or the calls avoided
• Add the next feature only when the evidence asks for it