To many organizations pursuing a website redesign, all websites are considered custom websites. However, if you investigate this space more deeply, you'll find that custom is a term that takes on additional meaning within the tech industry.

The vast majority of websites rely on someone else to do the heavy lifting of creating the actual application that forms the basis of the site. And for good reason; it's not economical to maintain custom software for most organizations. If you've read our reviews of CMS and Headless websites, both of those solutions essentially outsource the intensive step of creating the base application. In those instances, the organization simply chooses a pre-built platform and contracts with a firm like THOR to weave everything together with a great user experience.

Custom websites, on the other hand, don't rely on any content management or predetermined solutions. Instead, they require a development team to build the entire application by setting up a database, managing users, securing the application, building a search experience, putting together a pleasant interface, and more. In some instances, every aspect of the site is created from scratch in an effort to truly align the platform with the needs of the site. In other cases, custom websites can borrow from the headless approach by utilizing software-as-a-service (SaaS) solutions. Sites of this sort blur the line between purely custom solutions and headless solutions. 

The most obvious advantage of this approach is that an organization gets exactly what they want. However, this bold approach can present a double edge sword. Custom websites can be risky projects. Many developers attempting to build a custom site aren't technically oriented and can quickly find themselves in over their heads, faced with deeply technical puzzles they aren't prepared to solve. In addition, the prices for these projects tend to be very high, with long term maintenance overhead. For these reasons it's almost always the wrong answer to build from scratch. But never say never. There are a couple use cases in which it makes sense.

When to Go Custom

If there's one test for determining whether or not to go custom it's to ask yourself: Will your users create more of your site's content than you will? Custom sites tend to feel more like applications than typical page-based web experiences where consumption is the focus. The big social sites YouTube, Twitter and Facebook leverage this idea. Newer web-native applications like Figma, Notion, and Airtable take it a step further by putting desktop-like interactivity in the browser.

When considering building something of this scale, there are conversations every team should be having:‍

- Product Market Fit - This concept comes from the world of startups but the idea makes sense for any custom website project. Ask yourself: Have we figured out a way to present our product (concept) so that people are interested in buying it (consuming it)—and can you prove it with sales (metrics)? If you haven't figured that out, it likely makes far more sense to concentrate on sales or a conceptual website that validates the idea before allocating serious capital into building one from scratch.

- Technical Debt - This is a fancy word for maintenance but it's important to understand the nuance. Regular CMS / Headless websites have maintenance cycles that merely upgrade the core components, with only minor refactoring of the custom code that sits on top. When you build an application from scratch, each aspect of the application requires maintenance. And if the application is built without an eye for the future, this becomes a substantial stumbling block defined as a technical debt that your organization will forever be paying down. One simple principle to follow is to be careful regarding how many features you ask for. Make sure you need them or consider outsourcing them to a SaaS solution.‍

- Iteration - With a consumption-based, page-oriented website, evolving the site through an iterative process is a well known best practice. In a traditional cycle such as this the process typically has an endpoint after which there may be long periods without development. With a custom application, iteration continues for the life of the application, whether it is desired or not. Market dynamics and technical decisions force the hand of site owners to evolve constantly. For this reason, budgeting for a custom website project requires you to think of duration in years, not weeks and months.

Even if you've resolved all of those questions listed above a custom website still might feel too risky an endeavor. THOR always recommends that our clients evaluate how much of the concept is really custom and whether it could be adequately handled by the broad universe of SaaS solutions. It's more than likely that you will be able fit your concept into a constellation of services rather than a completely custom build. The following section outlines some of our favorite SaaS-based technical solutions which avoid a lot of the prickly parts of building a custom app.

Technologies to Consider

One of the most important technical decisions custom website builds have to wrestle with is what tools they will use to build the site. With traditional CMS websites, those decisions are made for you by the platform. Custom websites require picking all of those items. THOR has some recommendations for what you should be looking for with the caveat that this space is vast and almost every vendor will have different preferences:

- Data: Hasura (a GraphQL server with a Postgres relational DB). The biggest database decision you'll face is what type to use. There are many kinds but the most common is probably the right answer: a relational (SQL) database. Postgres is the best in class solution. If you can think through your data model as columns on a spreadsheet and see where each data entry is a row that fills in a column, that mental image maps very closely to how a relational DB works. Hasura simplifies a lot of decisions for would-be custom site builders by hosting the Postgresql database and wrapping an easily customizable GraphQL server around it. You may also hear about NoSQL databases (specifically MongoDB and their Atlas product, which is similar to Hasura). That type of structure makes querying for information difficult and THOR does not recommend it.

- Back-end: Cloudflare Workers (serverless functions that work only when needed). It's helpful to think of your new site like a restaurant, with the backend acting like a waiter relaying requests from the users of your website to the database in the kitchen. The business logic of an application is what lives in the backend of your website. Think of it as the recipes and the chef who creates the dishes for your patrons. THOR is a big fan of serverless functions, which take the backend of a custom application and spread it into separately hosted functions. The huge benefit of this approach is a simple maintenance model with lower hosting costs given that the functions are only used when needed. Cloudflare's latest offering drops the cost and ups the speed of these functions to compete with any true backend, and positions them ahead of the more traditional AWS Lambda serverless offering.

- Front-end: Next.js (React-based Javascript framework). The idea of Next.js is ingenious: It provides a component-based front-end architecture based on React that natively supports serverless Javascript functions, effectively fusing the front and backends of an application into one codebase. The framework itself allows developers to move quickly, using best-in-class React component-based interfaces and Node.js based serverless functions for interactive areas of the site. THOR has used Next with great success and highly recommends it for all types of projects, even Headless CMS work.

OK, I Really Do Want to Go Custom - How Do I Budget?

If you’re still reading, and still are pursuing a custom solution - bravo. You must have a very intriguing project on your hands. THOR recommends an extensive discovery and architecture phase with every project but with a custom build these steps are absolutely essential. Discovery in this instance consists of interviews with internal stakeholders and the development of rich personas that reflect your customer base followed by interviews with those individuals. This process is required to determine if all project priorities are aligned and if product market fit is within reach. 

Architecture should be dual tracked to include design of reusable components that will work across your project's lifespan and a deep, technical architecture phase that provides a birds-eye view of the tools the application can take advantage of.

Discovery and architecture pricing typically falls in the $40-60K range. Expect the custom application to require at least 800-1000 hours to build. That puts budgets for this type of work well into the six-figures. It's also a good idea to assume a healthy maintenance budget of approximately 20% of the original cost annually. 

THOR offers its services in many different roles on projects like this. We are able to perform all activities and complete the full custom development of a site. In some cases, our expertise is best suited to augmenting your existing team to carry out the design and architecture phases of the project.If you are early in the evaluation process for a project of this sort, contact us to discuss ways in which we can customize solutions to work with your team and budget.