Skip to content

How we choose a website stack

The best tool depends on who edits the site, how often it changes and what it must connect to.

3 min readDaniel Okafor
Developer comparing code editor windows on two monitors in an office

Clients often ask which platform we recommend. The honest answer is that it depends. A site for a bakery and a site for a payments company should not use the same tools. We ask three questions before we pick anything.

Question 1: who edits the content?

If the owner edits the site every week, the editor matters more than anything else. A simple content tool with clear fields saves hours each month. If a developer makes every change, a custom build may be fine.

We ask who will publish, how often and on which devices. A marketing lead who writes on a phone needs a different editor than a designer who works on a laptop.

Question 2: what must the site connect to?

Forms, bookings, payments and customer lists all add complexity. Each connection is a point where something can break. We list every integration before we write a line of code.

  • Contact forms that send to an inbox or CRM
  • Booking calendars and payment pages
  • Analytics, consent tools and a newsletter sign-up
  • Any internal dashboard or member area

If the list is short, a static site is often the best choice. It loads fast, costs little to host and rarely breaks. If the list is long, we look for a stack with good support for each connection.

Question 3: how long should it last?

Some sites are for a campaign that runs six months. Others must run for five years with little attention. We pick tools that have active maintenance and a clear upgrade path.

We avoid tools that depend on a single plugin for a core feature. If that plugin stops being updated, the site is stuck.

The right stack is the one your team can still change in three years, when nobody remembers why it was chosen.

What we usually recommend

For a marketing site with a blog, we often use a static site generator with a simple content editor. It is fast, secure and easy to host. For a web app with logins, we use a framework with a strong community and a clear testing setup.

We write the decision down in a one-page note. It lists the choice, the reasons and the trade-offs. That note saves time when the team changes, and it keeps the next decision honest.

Once the stack is chosen, we write down the reasons in the project brief. When a later request does not fit the stack, the team can see the trade-off at once and decide with the facts in front of them.

All demo pages