Topic Web and software engineering

Building Secure, Scalable Software: Decisions to Make Early

The short answer

Secure and scalable software comes mostly from a handful of decisions made before the first screen is built: how users sign in and what each role can see, how the data is modelled and separated between customers, where slow work runs, how you will see problems, and which threats you plan for. Most other scaling work can safely wait.

Written by

Siddharth Kajaria, Founder and CEO

Published

Updated

Reading time

11 min read

A building cutaway with deep foundations and a basement of locked rooms finished, while the floors above are bare frame.
In this post11 min read
  1. What is secure and scalable software?
  2. Why the early decisions matter most
  3. The decisions to make before you build
  4. A summary table: now or later
  5. Start with a modular monolith
  6. Signs it’s time to invest in scale
  7. How we’d approach the early decisions

Key takeaways

  • Security and scale are set mostly by structure: sign-in and roles, the data model, tenancy, background jobs, monitoring and a threat model.
  • Decide anything that shapes data or permissions early; add capacity only when you can measure the need.
  • Use proven sign-in, check permissions on the server for every request, and scope every query to the user or customer.
  • Run slow work in background jobs, keep the app stateless and test your backups by restoring them.
  • Start with a modular monolith and split services out only for a measured reason.

Security and scale are usually discussed as long checklists for developers. Those checklists matter, and our secure web development checklist is one. But if you are a founder or product owner planning a new web product, the decisions that set how secure and how scalable it will be come earlier, and most of them aren’t about code at all. They are about how users and data are organised, and what the system does when something goes wrong.

This guide covers those early decisions: which ones to make before you build, what a sensible default looks like for each, and which ones can safely wait until the product has real users.

What is secure and scalable software?

Secure and scalable software protects its users’ data from people who shouldn’t see it and keeps working as the number of users, customers and records grows, without a rewrite. Security means the right people can do the right things and nobody else can. Scalability means that growth costs you more servers, not a new architecture.

Both properties come from structure. You can add a faster server or a security scan later; you can’t easily change how data is separated between customers once thousands of them depend on it.

Why the early decisions matter most

Early decisions matter most because they are the hardest to reverse. Changing a screen is a design task. Changing how sign-in works, how customers’ data is separated or how records relate to each other touches every part of the product and every row of stored data, and has to be done while the product is live.

The rule of thumb: decide early anything that shapes the data or the permissions, and leave anything that only adds capacity until you have measurements.

The decisions to make before you build

1. How users sign in and what each role can do

Decide now: use a proven sign-in service or your framework’s built-in authentication, never home-made password handling. Write down every role (customer, staff, admin, support) and exactly what each can see and change. Require two-factor sign-in for admin and staff accounts from day one.

The most common serious flaw in web software is weak access control: a user changes an ID in a link and sees someone else’s invoice. The defence is structural. Every request checks permissions on the server, and every database query is scoped to the signed-in user or customer.

Can wait: single sign-on with customers’ own identity providers, until a customer asks for it.

2. The data model and how customers are separated

Decide now: if more than one business will use the product (a SaaS model), choose how their data is kept apart. There are three common patterns, compared below.

Three ways to keep customers’ data apart in a multi-customer product, compared
Compared onA customer ID on every rowOne shared databaseA schema per customerOne database, one schema eachA database per customerSeparate databases
SeparationThe weakest of the three: it relies on every query filtering by the customer ID, which the framework or database should enforce rather than leave to each developer.Stronger: each customer’s tables sit in their own schema.The strongest: each customer’s data sits in its own database.
Changes to the data modelOne set of tables to migrate.More work: each change runs once for every customer’s schema.Each change runs once for every database, and each new customer needs a database of its own.
Running costThe simplest and cheapest to run.In between: still one database to run.The highest running cost.
Large or regulated customersExpect questions about how their data is kept apart, and be ready to show how the filter is enforced.A clearer answer to those questions than a shared table.Often what large or regulated customers ask for.
Best whenMany small customers, and the filter on every query is enforced by the framework or the databaseYou want stronger separation without running a database for every customerLarge or regulated customers require their data kept fully apart, and the contract value covers the running cost

Also decide now: which fields hold personal data, so you can protect, export and delete them later; and an audit log of who changed what, for anything involving money, permissions or records people depend on.

Can wait: splitting data across several database servers (sharding). A well-indexed managed database handles far more than most products ever reach.

3. Where slow work runs

Decide now: anything slow or unreliable runs as a background job through a queue, not inside the web request. That includes sending email, generating reports and PDFs, importing files, calling payment or AI services, and resizing images. The page responds immediately, the job runs separately and can retry if it fails.

This one decision prevents most early performance problems, and it is awkward to retrofit once slow work is scattered through the code.

Can wait: a separate queueing platform. Most web frameworks have a job system that runs on the database or a simple store such as Redis.

4. Keeping the app stateless

Decide now: the application servers keep nothing that matters on their own disks. Sessions live in the database or a shared store, and uploaded files go to object storage. Then you can run two copies of the app, or ten, behind a load balancer when traffic grows, and replace any of them at any time.

Can wait: auto-scaling rules. Start with a fixed number of copies and add rules when you see the traffic pattern.

5. How you will know something is wrong

Decide now: error tracking that alerts a named person, structured application logs kept for a set period, and basic health checks with uptime alerts. Without these, your users become your monitoring system.

Can wait: distributed tracing and detailed performance dashboards. When you add them, an open standard such as OpenTelemetry keeps you free to change tools.

6. Which threats you plan for

Decide now: spend an hour on a threat model before the build. List what is valuable in the system (personal data, payments, admin powers), who might want it, and how they could get at it. Microsoft’s STRIDE categories (spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege) are a useful prompt for the “how”. Each likely threat becomes a requirement, such as rate limits on sign-in or file-type checks on uploads.

Use the OWASP Top 10 as a shared vocabulary with your developers for the most common web application risks.

Can wait: a full external penetration test, until before launch or before a large customer signs.

7. Dependencies and secrets

Decide now: every project locks its dependency versions, and an automated tool such as Dependabot or Renovate opens updates for review. Passwords, API keys and certificates live in a secrets manager or the hosting platform’s encrypted settings, never in the code or a shared document.

Can wait: a formal software bill of materials (SBOM), until a customer or regulator asks for one.

8. Backups and recovery

Decide now: automated daily backups of the database and stored files, kept somewhere separate from the live system, and a restore test before launch. Agree two numbers with the business: how much data you could afford to lose (the recovery point) and how long the product can be down (the recovery time). Those numbers decide how often you back up and how much standby capacity you pay for.

Can wait: a second hosting region, unless the product can’t tolerate a regional outage.

A summary table: now or later

The eight decisions above, plus the architecture choice in the next section, split cleanly in two: what to decide before you build, and what can wait until a clear trigger arrives.

9 areas

What to decide before you build, and what can wait until a clear trigger, area by area
AreaDecide before you buildCan wait, and until when
Sign-in and rolesProven sign-in, written roles, two-factor for adminsCustomer single sign-on: a customer asks
Data and tenancyThe separation pattern, personal-data fields, an audit logSharding: measured database limits
Slow workBackground jobs and a queueA separate queueing platform: job volume demands it
App serversA stateless app, files in object storageAuto-scaling rules: you know the traffic pattern
MonitoringError tracking, logs, uptime alertsTracing and dashboards: the team needs them
ThreatsA one-hour threat model, rate limitsAn external penetration test: before launch or a big customer
Dependencies and secretsLocked versions, automated updates, a secrets managerAn SBOM: a customer or regulator asks
BackupsDaily backups, a restore test, recovery targetsA second region: downtime tolerance requires it
ArchitectureOne modular applicationMicroservices: separate teams or very different load
The ruleIt shapes the data or the permissionsIt can wait for a trigger: measured load, or a customer or regulator asking

The rule behind the split is the one from the start of this guide: decide what shapes the data and the permissions, and wait on anything that only adds capacity.

Planning a new build?

We plan the system before the screens: the decisions above, each with the choice, the reason and when to revisit it, before design starts.

See web app developmentPlan the system first

Start with a modular monolith

For most new products, the best architecture is one application with clear internal modules (accounts, billing, orders, reporting), each owning its own data and talking to the others through defined interfaces. It deploys as one unit, which keeps it simple to run, test and secure.

  1. One application, clear modules

    Accounts, billing, orders and reporting live in one codebase and deploy as one unit.

  2. Each module owns its data

    Modules talk to each other through defined interfaces, not by reaching into each other’s tables.

  3. Measure the load and the teams

    Watch where the load lands and where people get in each other’s way, rather than guessing up front.

  4. Split out one module

    When one module needs to scale or release on its own, its clean boundary makes it straightforward to move into a service.

If one module later needs to scale or release on its own, its clean boundary makes it straightforward to split out. Starting with many small services before you know where the load and the team boundaries are usually means more deployments, more network failures and more to secure, with no benefit yet. If an existing codebase has drifted far from this shape, our post on managing technical debt covers how to plan the clean-up.

Signs it’s time to invest in scale

Invest when you can measure the need, not before. Tick the signals that are true for your product today; each one names the fix it points to.

5 signals

The system under load

Show or hide the signals3 signals

  1. 01 Response times climb at busy hours

    What you see
    Pages and API calls slow down at peak times, even after obvious fixes such as missing database indexes.
    The fix it points to
    Find the slow queries first. A slow query needs an index, not a new architecture.

  2. 02 The database is the bottleneck

    What you see
    The database is the busiest part of the system, mostly with reads.
    The fix it points to
    Read replicas or caching take load off it.

  3. 03 Background jobs queue up faster than they finish

    What you see
    The queue grows through the day, and emails, reports or imports arrive late.
    The fix it points to
    More job workers, or separate queues so slow jobs don’t hold up quick ones.

Read next Speed up a slow web app

Customers and the team

Show or hide the signals2 signals

  1. 04 One large customer slows everyone else down

    What you see
    A single customer’s activity makes the product slower for the rest.
    The fix it points to
    Limits on how much one customer can use at once, or moving that customer to its own database on its own capacity.

  2. 05 Releases slow down

    What you see
    Too many people work in the same part of the code, and changes wait for each other.
    The fix it points to
    The measured reason to split one module out of the monolith.

Read next Managing technical debt

Fix the signal you can measure, not the one you fear. A slow query needs an index, not a new architecture.

How we’d approach the early decisions

We plan the system before the screens. On a new build, we’d work through the decisions above with the product owner as a short written list, each with the choice made, the reason, and the trigger for revisiting it, before design starts. That list then guides the custom software development work and gives anyone who joins later the reasoning behind the structure.

Example decision list, made up to show the format and not taken from a client project:

  • Sign-in. Choice: email and a one-time code. Reason: no passwords to leak or reset. Revisit when: enterprise buyers ask for single sign-on.
  • Data separation. Choice: every record carries its customer’s ID and every query filters on it. Reason: one customer can never see another’s data. Revisit when: a customer needs its own database.
  • Background jobs. Choice: a queue for emails and reports. Reason: slow work never holds up a screen. Revisit when: the queue falls behind at peak.

For a first version, the same list is shorter but not skipped: sign-in, data separation, background jobs and backups belong in an MVP development build as much as in a mature product. If you want to plan the system before you commit to a bigger build, see product consulting.

02 FAQ

Questions, answered

When should a startup start thinking about scalability?
Before the first build, but only at the level of structure: a clean data model, slow work moved to background jobs, and an app that keeps no state on its own servers. Those choices cost little at the start and are expensive to change later. Heavier work such as microservices, sharding or several regions can wait until real traffic shows where the limits are.
Do you need microservices to build scalable software?
No. Most products scale a long way as one well-structured application, a modular monolith, running several copies behind a load balancer with a managed database. Microservices help when separate teams need to release separately or one part has very different load, but they add network calls, deployments and failure points. Split a service out when you have a measured reason.
What is the most common security mistake in new software?
Weak access control: users reaching records or actions that belong to someone else, often by changing an ID in a URL or an API call. Broken access control is the top category in the OWASP Top 10:2025, as it was in 2021. Prevent it by checking permissions on the server for every request, scoping every query to the signed-in user or customer, and testing it with a second account.
What can a non-technical founder check about security and scale?
Ask the team five questions. How do users sign in, and is that built on a proven service or library? How is one customer's data kept from another's? When did someone last restore a backup to check it works? How would we know the app was failing at 3am? What happens to the app if traffic doubles next month? Clear, specific answers are a good sign.