Logins, Data and Backups: What We Build In by Default

When people picture a custom application, they picture the screens. Fair enough — the screens are the part you use.

But roughly half of what makes an application trustworthy is invisible. It is the part that decides who can see what, keeps the data safe when somebody makes a mistake, tells us when something breaks, and lets a change be tried somewhere harmless first. It is also the part most often quietly removed from a cheap quote, because you cannot see it missing on the day you launch. You see it missing about eight months later.

Here is what we include on every project, and why each item earns its place.

Accounts and passwords

Every application we build has real accounts. People sign in with an email address and a password, and the password is never stored as text anyone can read — not by us, not by anyone with access to the database. It is put through a one-way hashing function, so what is stored can be checked against a password typed later but cannot be turned back into the original. That is the standard, not a premium feature, and it is worth asking about if you are buying software from anybody.

We use a managed authentication service rather than hand-rolling one. Sign-in, sign-out, password reset, session handling and the email that goes with a reset are exactly the areas where homemade code goes wrong subtly, and where getting it wrong is expensive. This is not a place to be creative.

The password advice worth passing to your team

Most accounts are not lost to anything sophisticated. They are lost because a password used at work was also used on a website that was later breached, and somebody tried the combination everywhere. Four habits cover most of the risk:

• Never reuse a password across accounts. This is the whole game. One breach elsewhere should not reach your business.
• Use a password manager. It is the only realistic way to have a different long password everywhere. The one built into your browser is far better than reuse; a dedicated manager is better again, mostly because it works everywhere.
• Prefer length over punctuation. Current guidance from the US National Institute of Standards and Technology (SP 800-63B) is to allow long passphrases, to check new passwords against lists of known-breached ones, and to stop forcing routine expiry — forced monthly changes mostly produce Summer2026! followed by Autumn2026!. Change a password when there is a reason to believe it is exposed.
• Turn on a second factor wherever the account matters — email, banking, anything that can reset other accounts. A code or a prompt on your phone stops a stolen password on its own from being enough.

You can check whether an address of yours has appeared in a known breach at haveibeenpwned.com, a long-running free service. A hit does not mean anything of yours is currently compromised; it means any password you used on that site should be considered public.

Permissions, enforced where they cannot be bypassed

Accounts are only half of it. The other half is what each account may see.

In the databases we build, every table has row-level security switched on. In practice that means the rule — a contractor sees their own jobs, a customer sees their own invoices, a manager sees the team — is enforced by the database itself, not by the screen. Hiding a button is not security; anybody can ask the server directly. If the rule lives in the database, the answer is the same no matter how the question is asked.

This is why "just add a login" is never the whole request. The interesting work is the permission model, and it is worth thinking about before the build: who are your kinds of user, and what should each of them never be able to see?

Backups, and what they are actually for

People assume backups are for disasters. Mostly they are for Tuesdays. The common scenario is not a fire — it is somebody deleting the wrong record, or a change that turns out to be wrong once real data goes through it.

Two things are worth separating. The first is your data: we run on managed Postgres, and automated backups are part of the managed service. How frequently they are taken and how far back they reach depends on the plan a project is on, so we state which plan and what that means in the proposal rather than waving at the word "backups".

The second is everything that is not data: the application code, the database structure, and the configuration that makes it run. That all lives in version control, with every change recorded. If the running system disappeared entirely, it could be rebuilt from the repository and the data restored into it. A backup of the data without the means to rebuild the system around it is only half a recovery plan.

And, since it needs saying somewhere: a sync service is not a backup. If a file syncs to the cloud, deleting it deletes both copies. Recycle bins and version history help, but they run out, and they are limited protection against something that was wrong for a month before anyone noticed.

Knowing when something breaks

Every application we ship reports its own errors. When something fails for a real user, the failure is captured with enough technical context to find it, and we can see it without waiting for a phone call. Personal data is kept out of those logs deliberately — error reports should tell us what broke, not who it broke for.

Alongside that, every production site is watched by an uptime monitor, so if it stops responding, somebody knows. The alternative — finding out from a customer — is worse for everybody, and it always arrives at the wrong moment.

Somewhere safe to be wrong

Every project gets a staging environment: a complete copy of the application, at its own address, with its own database, where a change can be tried before it goes anywhere near your real data. You can open it on your phone and click around while the work is in progress.

Behind that, every change runs through an automated check before it can be merged — the code is linted and type-checked, unit and browser tests run, and a scan looks for credentials accidentally committed. None of this is visible to your customers. All of it is the reason a small change on a Thursday does not become an outage on a Friday.

Why this is standard rather than an upgrade

We build every project on the same stack and the same template, so this list is not assembled from scratch each time and does not have to be sold as an extra. It is simply what a competent application has.

The test to apply to any quote, ours included, is simple: ask what happens when somebody deletes the wrong thing, how you will find out if the application breaks at two in the morning, and where changes get tried first. The answers tell you what is really included.

Get an estimate and we will walk you through exactly what your project would include.