Do I need a website or something with a login?

They solve different problems and they cost different amounts. Knowing which one you are describing is usually the first useful thing to work out.

A website is the part strangers see. Its job is to win the next customer, and everything on it is public.

An app is the part your team sees. It sits behind a login, it holds records, and its job is to make the daily work take less time. Plenty of businesses need one and think they need the other.

The question that sorts it

Who is supposed to be looking at it, and are they logged in? If the answer is "anybody, and no", it is a website. If it is "my team, or my customers after they hire me, and yes", it is an app.

The confusing cases are the ones in the middle: a booking page, a customer portal, a job tracker your customers can peek at. Those are apps with a public front door, and they get built as apps.

What an app is actually for

Almost always the same shape: something is currently held in a spreadsheet, a group chat, a notebook, or somebody's head, and it has outgrown that.

  • More than one person needs the same current answer A spreadsheet handles one person well and three people badly. The moment two people are editing versions of the truth, that is the signal.
  • The same record has to move through stages Enquiry, quoted, scheduled, done, invoiced. Tracking a stage in a colour-coded cell works right up until it does not.
  • Somebody outside the business needs a look in A customer wanting to see where their order is, without phoning to ask, is the most common reason a small business ends up wanting a login.

When the spreadsheet is the right answer

Frequently. A spreadsheet that one person maintains, that everybody trusts, and that nobody is fighting over is not a problem waiting to be solved. Replacing it with software makes it slower to change and gives you something to maintain.

We will tell you when that is where you are, and when an off-the-shelf tool already does the job better than anything worth building. Talking a business out of a build is a normal outcome of the first conversation.

What it costs you after it is built

This is the part that gets skipped. Anything with a login has ongoing weight: it needs somewhere to run, the records need backing up, people need adding and removing, and when the business changes the software has to change with it.

That is a fair trade when the tool is saving real hours every week. It is a bad trade for something used twice a month, and worth knowing before you start rather than after.

The questions we get asked.

Can one project be both?
Often, and it is a common shape: a public site that wins the customer, with a logged-in area behind it for the people who have already hired you. They are built as two things that share a look.
Should I just use an off-the-shelf tool?
If one fits, yes, and we will say so. The case for building is when every tool in the category assumes a way of working that is not yours, and you would spend more time fighting it than it saves.
Who owns the data?
You do, and you should be able to get all of it out in a format you can open, without asking anybody. That is a question worth putting to any vendor, us included.
What happens when I need it changed?
Everything with a login eventually needs changing, because businesses change. It is worth agreeing up front how that works rather than discovering it the first time you need a new field.