How to get architecture, security, data protection and technical debt right early.

Speed matters, but some shortcuts become permanent. Good technical foundations are the handful of decisions that keep you fast for years: a simple architecture, sensible security, personal data handled properly and technical debt taken on knowingly.

Why it matters

Business customers will ask about security and data protection before they buy. Investors and acquirers will look at your code and IP during due diligence. And a messy foundation slows every future change. A little care now avoids a costly rewrite later.

Architecture: keep it boring

• Choose mainstream technology your team knows and that is easy to hire for. Novel tools add risk without helping customers.
• Start with a single, well-organised application and one database. Split into separate services only when there is a clear reason, such as very different scaling needs.
• Use managed services for hosting, databases, sign-in and file storage, so you are not running infrastructure yourself.
• Keep environments separate: development, staging and production, with production data never copied into development without being anonymised.
• Write down decisions. A short note for each significant choice, with the reason and alternatives considered, saves arguments later.

Security basics

1. Turn on two-factor authentication for every account: code repository, cloud, email, domain registrar and payment provider.
2. Give people the least access they need and remove it promptly when they leave.
3. Keep secrets such as keys and passwords out of code; use a secrets manager.
4. Keep dependencies up to date and enable automated vulnerability alerts.
5. Back up data automatically and test that you can restore it.
6. Log important events and set alerts for unusual activity.

The UK National Cyber Security Centre’s small business guide is a useful baseline, and many business customers will ask whether you hold Cyber Essentials.

Data protection by design

UK GDPR requires data protection by design and by default. In practice: collect only the personal data you need; know where it is stored and who can see it; decide how long you keep it; write a clear privacy notice; and put data processing terms in place with suppliers and with customers whose data you process. If you are processing personal data you may need to pay the data protection fee. The ICO guidance for organisations sets out the rules, which change over time. This is general information, not legal advice.

Technical debt

Technical debt is the future cost of shortcuts taken now. Some is sensible: shipping fast to learn is often worth it. The problem is debt nobody knows about. Keep a visible debt list, note why each shortcut was taken, and, as a rule of thumb, reserve around a fifth of each cycle for paying it down. Prioritise debt that slows frequent changes or creates security risk.

Worked example

ClaimPilot handled patient details on behalf of physiotherapy clinics. Before its first pilot, a volunteer security reviewer found production data copied into the developers’ test database and shared admin passwords. The team switched on two-factor sign-in everywhere, moved secrets into a secrets manager, anonymised test data, wrote a data processing agreement for clinics and kept a one-page record of what personal data they held and why. When the largest clinic group sent a security questionnaire three months later, they answered it in a day.

Common mistakes

• Over-engineering for scale you do not have.
• Shared logins and no two-factor authentication.
• Real personal data in test environments.
• No tested backups.
• Hidden technical debt that surfaces during due diligence.
• No record of who has access to production systems and data.

What to measure

• Accounts with two-factor authentication switched on.
• Outstanding critical dependency vulnerabilities.
• Date of last successful backup restore test.
• Size and age of the technical debt list.
• Time to complete a customer security questionnaire.