Choosing a stack for a project

A stack is the set of technologies a service is made of: pages, language, API, sign-in, alerts, data and hosting, chosen by the main action.

From parts to a whole

You have learned how a server works, how static differs from dynamic, how PHP differs from Node.js, what an API looks like, how inquiries arrive and how sign-in is built. Now you can put it all into one decision for your project. That is called choosing a stack: the set of technologies a service is made of. There’s no right answer “in general”. There’s an answer that suits your project, and you can justify it.

How to reason

The order of reasoning matters more than any particular names, and it’s always the same.

1. The main action. What must the visitor do on the site: leave an inquiry, buy, book, read? Everything else serves it. It’s the very action from your brief.
2. The path of the data. What happens after the click: where does the data go, who receives it, who learns about it and how. For an inquiry it’s the visitor, the form, intake, storage, a notification and the owner. Each step of the path is a block that needs a tool.
3. The simplest suitable thing at each step. Not the most powerful, not the trendiest. If a ready-made file is enough, you need no database. If a form service is enough, you need no application. If it’s enough to send the inquiry by email, you need no account area.
4. What happens when it breaks. Every block fails one day, and the plan for that is made in advance, while things are calm.
5. Where the data sits and who sees it. The law isn’t a formality here.

The stack, block by block

Pages. Static or dynamic. For a small business site, a landing page or a blog, static is most often right: ready-made files served by nginx or by the host (remember how much faster, cheaper and safer that is). On a CMS (WordPress, Drupal) the pages are built from a database, and that is justified when several people who aren’t programmers change the content often. There’s a whole part ahead about CMSs and site generators.

Language and application. Needed only if there’s something dynamic: receiving inquiries, sign-in, an account area. You have seen how to choose: for a CMS site it’s PHP, for a chat Node.js, Go or Elixir, and otherwise the language in which it’s easiest to find people. If the only dynamic thing on the site is one form, it often pays better not to write an application but to plug in a form service or a cloud function.

API. For a list and an inquiry, plain REST with an OpenAPI description is enough. GraphQL is needed when a project has several different clients.

Sign-in. Begin with the question of whether it’s needed. If it is, then without passwords (a passkey, a link by email, sign in with Google or Apple), and fix the roles in advance.

Inquiries and notifications. Receiving, a webhook into a chat app, or an email. A signature, idempotency and a quick answer. Two channels are more dependable than one.

Data. A database is needed if something has to be stored and searched: inquiries, users, orders. If not, don’t start one. Databases are the next part.

Hosting and server. From cheap hosting with PHP to a virtual server (a VPS) and the cloud. For a small project one VPS with nginx is most often enough. The cloud, containers and Kubernetes (the part on infrastructure) are for when the project has grown.

Pick blocks for your main action, and the diagram will tell you what is missing and what is surplus:

The project’s main action: Main action

Blocks

Static file hosting (GitHub Pages, Cloudflare Pages, Netlify, any host) Web server (nginx) on a VPS (a VPS from Hetzner, DigitalOcean or similar) An application (Node.js, PHP…) (runs on the same VPS) Database (PostgreSQL on the same VPS, or managed) Sign-in (your own, or through Google or Apple) Form-handling service (instead of your own application) Webhook / notification (Slack, email) Email sending and newsletters (a transactional email service) CDN (serving files closer to people)

• Missing The main action “Main action” means taking data from the visitor: you need an application or a form service.

Roughly: £0 a month. An order of magnitude, not a price list: prices change, and many services have free tiers.

Check yourself: why is a diagram with only a “pages” block incomplete for a small business site with an inquiry form?

Someone has to receive the form’s data and tell the owner about it. You need at least an intake (an application or a form service) and a notification.

Law and place: what to consider

Wherever you work, three questions come up, and the law answers the first.

Where the data sits. The GDPR applies when you offer goods or services to people in the EU (Article 3), and the UK GDPR with the Data Protection Act 2018 does the same for people in the UK, wherever your server is. An inquiry with a name and a phone number is exactly such data. You need a contract with every service that handles it for you (a processor, under Article 28 of the GDPR). Sending the data outside the UK or the EEA is allowed only with a lawful transfer mechanism (Chapter V of the GDPR): an adequacy decision, such as the one for companies certified under the EU–US Data Privacy Framework, standard contractual clauses, or another safeguard. So a provider in your own region, or one on that list, makes the answer simple. Copies in other services (a chat app, say) are possible, but the privacy notice has to say so. For comparison, Russia’s law (152-FZ) is stricter than the GDPR: the first recording of Russian citizens’ personal data must be made in databases on Russian territory, which is why Russian projects pick a Russian host for the main database. This is general information, not legal advice. In the UK the Information Commissioner’s Office (ico.org.uk) explains the rules, and in the EU you can ask your national data protection authority.

The availability of outside services. The terms, prices and availability of services change quickly, and not at your wish: an API you depend on is retired, a payment provider leaves your country, a free plan ends. For every important block (email, forms, payments, hosting) it’s worth knowing a fallback in advance, and being able to switch in days, not months.

Hosts and CMSs. Cheap shared hosting with PHP is everywhere (WordPress is installed there in a couple of clicks), and there’s a large market of specialists for it. For a CMS project it’s a perfectly good option, not an “outdated” one.

Risks

For each block think about what happens when it fails, and write the plan in one line. Three typical ones:

• the application with the form is down: the pages stay available (they are static), the page shows a phone number and an email, and monitoring reports the failure;
• the notification channel is unavailable: the inquiry is duplicated by email;
• the server is lost: the backup of the database sits somewhere else and is refreshed every day, and the site is redeployed from the repository.

Practice

You’re on a site from the 2022 era, summing up the part. Put together, on one page, a diagram of your project’s server side: the main action, the path of the data from the visitor to the owner, seven blocks with a choice and a reason, where the personal data is kept, and three risks with a plan. “Not needed” for a block is as good an answer as the name of a tool. A good diagram is short and specific: you can set a task to a developer or an AI model from it.

What was wrong before

In the 2010s it was considered “modern” to assemble, for a small business site, a stack of ten technologies: an application, a database, a cache, a message queue, a search engine, containers. This was called “so that it scales later”. Then it turned out that the site never grew beyond a thousand visitors a month, and there was nobody to maintain ten components that could each break. At the other pole stood the “black box”: a CMS site with fifty plugins of unknown origin, where nobody knew what was stored where.

The lesson of both slants is the same: complexity has to be earned. Start simple, and keep an eye on the data’s path, on where personal data is kept, and on the plan for a failure.