How we choose a tech stack for a project

The question is not 'what is best?'

Debates about the best language or framework rarely help a real project. The right choice depends on who will build and maintain the system, what it needs to do, and what it will cost to run for years, not on what is popular this month.

We work through the questions below, roughly in order, before choosing technology for a new product.

Start with constraints

• People: who will maintain this in two years, and what do they already know well?
• Users: what devices and connections will they use? A product for budget phones on mobile data has different needs from an internal tool used on office desktops.
• Data: how sensitive is it, and are there regulatory or contractual requirements?
• Scale: what traffic is realistic in the first year, not in the most optimistic pitch?
• Budget: what can the project afford to spend on hosting and operations every month?

Writing these down often settles the decision before any technology is named.

Prefer proven technology

Mature tools have well-understood failure modes, extensive documentation, and answers to most questions already written somewhere. New tools may be faster or more elegant, but every new component adds learning time, operational risk and a dependency that might be abandoned.

A useful rule is to allow only a small number of new technologies per project, and only where they solve a real problem that the familiar option cannot. This website is a good example: it is built with Django, a framework that has been in production use for many years, and Bootstrap for layout. Neither is novel, and that is the point. They let us spend our time on content and product rather than infrastructure.

Choose server rendering until you need more

Many products are mostly pages, forms and lists. Server-rendered HTML handles these well: pages load quickly on slow devices, work without JavaScript, and are easy for search engines to read. Interactive components can be added where they bring real value.

A full single-page application makes sense when the product behaves like a desktop application, with rich, constant interaction. Choosing it by default adds a build pipeline, a separate API, and extra weight for every visitor.

Keep future changes cheap

No initial decision will be perfect, so design for change:

• Separate presentation, business logic and data access, so one can change without rewriting the others.
• Use a mainstream relational database unless there is a clear reason not to. Relational databases handle a very wide range of products well, including financial records that need strong consistency.
• Keep configuration and secrets in the environment, so the same code runs in development and production.
• Write automated tests around the parts that are expensive to get wrong, such as payments and calculations.

Count the operating cost, not just the build cost

Building a product is a few months; running it is years. Factor in hosting, monitoring, backups, security updates and the time needed to upgrade dependencies. A slightly slower option that a small team can operate calmly usually beats a faster one that needs constant attention.

If you are planning an education or fintech product and want a second opinion on these trade-offs, you can reach us through the Contact page.