A web application that runs smoothly today says little about next year. Growth rarely announces itself: a large new client, a campaign that takes off, an integration that doubles your data traffic. Whether your application can handle that is decided long before it happens, by choices your supplier made at the start of the project.
You don’t need to be able to make those choices yourself. You do need to be able to check whether they were made. That’s what this framework is for: the questions you ask, the answers that build trust and the signals that point to risk.
Scalability is decided at the start
How expensive growth becomes later is fixed in the architecture: the way an application is divided up and how those parts work together. An application that’s well structured grows with you without needing to be rebuilt from scratch. In an application where everything is tangled together, every growth spurt means renovating while the traffic keeps flowing.
More technology isn’t automatically better. Microservices, where a system is split into separate services that can scale independently, sound impressive, but the maintenance burden they bring only pays off at real scale. For most organisations, a well-structured application built as a single whole is the wiser starting point; our article on microservices explains that trade-off in more detail. Be wary, then, of both the supplier who never mentions growth and the one who proposes the heaviest technology straight away.
The questions that sharpen the conversation
You don’t need a technical background to have this conversation. These questions force concrete answers:
- What has to change in the system if the number of users grows tenfold?
- Where does the first bottleneck sit, and what shows that?
- How do you test the load before the application goes live?
- What do you measure once the application is running, and who steps in when something’s off?
- Which results do you cache temporarily, so the system doesn’t have to recalculate every request from scratch?
Answers that build trust
A good partner answers these questions without hesitation and names trade-offs rather than guarantees. The first bottleneck, for instance, often sits in the database. A strong answer explains how it’s set up to handle that and what the next step is once the pressure builds: spreading read traffic across multiple copies, caching frequently requested data, running heavy calculations outside peak hours.
Pay attention, too, to how the supplier talks about measurement. Load tests, which simulate peak traffic before users encounter it, are part of delivery. Monitoring should then keep showing how the system performs, on an ongoing basis. And perhaps the best answer you can get is that something isn’t needed for your situation yet. A supplier who dares to leave things out isn’t selling you technology you don’t need.
Signals that point to risk
Some answers deserve a follow-up question. “We’ll deal with that when it happens” usually means there’s no measurement plan. Scalability as a sales term, without a testing approach or measurements behind it, is a promise without proof. And without monitoring after go-live, your users become the first alarm bell.
The opposite is a signal too. An architecture so complex that only its builder still understands it makes you dependent, and actually slows growth down. Scalability isn’t a matter of piling on as much technology as possible, but of choices that fit where your organisation stands now and where it wants to go.
Have a project coming up, or wondering whether your current application can handle the next growth spurt? Hold these questions against the proposal on the table; the answers will quickly tell you who you’re dealing with. And if you’d like to see how we approach this ourselves, take a look at web applications and portals: that’s where you’ll find how we develop applications that grow with your organisation.