Seven questions to ask before you hire an agency
A short list of questions that show how an agency works, what it costs and whether it fits your team.
Read article: Seven questions to ask before you hire an agencyThe best tool depends on who edits the site, how often it changes and what it must connect to.

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.
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.
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.
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.
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.
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.