When a business outgrows a website and needs a portal or web app.

The signals that you have outgrown a website

Nobody wakes up wanting a web app. What happens is that a business gets big enough, or specific enough, that the gap between how it works and what generic software allows starts costing real hours every week. The signals are consistent:

• A spreadsheet is running something important. One person maintains it, everybody else emails them to ask what it says, and if that person is away the process stops.
• Customers phone to ask questions the system already knows. Where is my order. When is the technician coming. Can I have that invoice again. Every one of those calls is a piece of information you already hold, being delivered by a human.
• The same information gets typed twice. Out of the booking form, into the accounting software. Out of email, into the schedule. Double entry is where errors live and it scales badly.
• You are paying for software you use a tenth of, and it still cannot do the one thing that matters to you.
• Growth would mean hiring somebody to do administration, not to do the work you sell.

One of these is normal. Three or four together and there is usually a real business case, because you can put an hourly cost against them and compare it to a build.

What actually counts as a portal or a web app

The words get used loosely. A useful line: a website tells people things, and a web app lets people do things. The moment there are accounts, records that change, and different people seeing different data, you are in application territory whatever it is called.

The things businesses around the region ask us for most often:

• A customer portal. Clients sign in to see their own documents, invoices, job history or progress. It removes a category of phone call permanently.
• A booking or scheduling system that matches how you really schedule, including the awkward parts generic tools cannot express, such as travel time between towns or two-person jobs.
• A member area. Associations, clubs and training providers with content, renewals and rosters behind a login.
• An internal dashboard. Nobody outside sees it. It exists so the people running the business stop asking each other for numbers.
• A quoting or estimating tool that applies your pricing rules consistently, which is what the Lead Machine estimator is for trades.
• An integration layer that moves data between two systems you already pay for and which do not speak to each other.

Try off the shelf first, honestly

We will tell you to buy something instead of building it more often than you would expect, because for a lot of problems that is simply the right answer and we would rather say so at the start than halfway through.

Buy, when the process is genuinely standard. Accounting, payroll, email marketing, general purpose scheduling, storefronts selling ordinary products. These are solved problems with mature products, and a custom version will cost more and do less.

Build, when one of these is true:

• Your process is the advantage. If the way you do it is why customers choose you, bending it to fit a product is giving up the thing you are paid for.
• You are paying per seat for a fraction of a product, and the subscription over three years is approaching the cost of owning something that fits.
• Two systems need to talk and neither will. Often the cheapest build is not a replacement, it is a connector.
• The data is sensitive enough that where it lives matters, and the product you are considering cannot tell you clearly.
• You have already tried three products and each failed at a different point. That is usually a real sign, not impatience.

What a custom build costs, and why the range is wide

Anybody quoting a portal from a one-paragraph description is guessing, and the guess is usually low, which is how projects end up in dispute. The honest answer is that the range is wide until the scope is written down, and writing it down is the first piece of work.

What actually moves the number:

• Number of user types. One kind of user is straightforward. Customers, staff and administrators each seeing different things is three sets of rules, three sets of screens and three sets of tests.
• Integrations. Every external system is somebody else's rules, somebody else's outages, and a category of problem that appears months later.
• Payments. Taking money adds compliance, refunds, failed payment handling and reconciliation. It is never just a button.
• Data migration. Getting years of existing records in, cleanly, is regularly a bigger job than the feature that uses them.
• How wrong things are allowed to go. An internal tool where a mistake means redoing an afternoon is a different build from one where a mistake means a customer sees another customer's file.

We quote these individually after a scoping conversation, and the scope is written down before a line is built. What we will not do is name a figure for a portal on a phone call, because that number would be fiction and you would reasonably hold us to it.

Scoping it properly, before anything is built

Most failed software projects fail in the first two weeks, before anybody writes anything, because the scope was a conversation rather than a document. A scope worth signing has four parts.

• The jobs, in plain sentences. “A customer signs in and downloads any invoice from the last two years.” Written this way, both sides can tell whether it is done.
• What is explicitly out. The out list prevents more arguments than the in list. If reporting is phase two, it should say so in writing.
• Who sees what. Every user type against every kind of record. This is boring to write and it is where the security problems would otherwise have been.
• What happens when it breaks. Who is called, how fast, and what a fix is expected to cost after launch.

Expect scoping to take a couple of weeks of back and forth on anything substantial. That fortnight is the cheapest part of the project and it is the part that decides whether the rest goes well.

Security and data, at a level you should insist on

Once you hold customer records, a mistake stops being embarrassing and becomes a legal matter. Businesses across Atlantic Canada handling personal information have obligations under PIPEDA, and “the developer set it up” is not a defence anybody accepts.

Questions worth asking whoever builds it, including us:

• Where is the data physically stored, and can it be kept in Canada if that matters to your customers or your contracts.
• How are permissions enforced? Hiding a button is not a permission. The rule has to live on the server, where a curious user cannot reach it.
• What is logged? Who looked at what, and when. You will want this the first time somebody asks a difficult question.
• How are backups tested? Taken is not the same as tested, so restore one and find out.
• What happens if you disappear? Where does the code live, who else could pick it up, and is that written down anywhere.

That last one is a fair question to ask a one-person studio, and we would rather you asked it. The answer should be that the code is in a repository you have access to, built with ordinary well-known tools rather than anything exotic, and documented well enough that a competent developer could take it over.

Build it in stages, and pay that way too

The single best protection against a project going badly is refusing to do it all at once. Stages give both sides a chance to notice a wrong assumption while it is still cheap.

• Stage one is the smallest useful thing. A demonstration does not count. Something narrow that real people use in the real business, because that is the only reliable source of truth about what is missing.
• Each stage is quoted and paid for on its own. You are never holding a large balance against work that has not happened, and either side can stop at a clean boundary.
• Stage boundaries are working software, not documents. A stage ends when somebody uses it.
• Expect the plan to change after stage one. It always does, and that is the point. Feedback from actual use is worth more than another month of planning.