The four back-end decisions we make early: CMS, database, hosting, and APIs

Why back-end decisions compound

Front-end decisions are visible. Back-end decisions aren't. Users see the interface but not the system underneath. Teams making their first digital product often spend most of their planning time on what the user sees and almost none on what sits behind it.

This asymmetry creates a problem, because back-end decisions compound faster than front-end decisions. Change the visual design of a page after launch: a few days of design work. Change the CMS the site runs on: rebuild every content workflow, retrain the team that publishes, potentially migrate historical content. Change your hosting provider: schedule downtime, test migration, handle edge cases that don't appear until production. Change the payment API: rewire every integration point, re-certify the checkout, requalify with the provider. The upfront cost of picking well is substantially lower than the cost of changing later.

From our project work across years of digital product development, the teams that get the best outcomes are the ones that make back-end infrastructure choices deliberately at the start. Four decisions account for most of the leverage: CMS type, database, hosting, and third-party APIs. This article covers how we approach each.

The broader topic of full tech stack selection is covered separately in our article on choosing the right technology stack for a digital project. This piece focuses specifically on the back-end layer.

Decision 1: CMS (Custom vs Open-source)

The Content Management System shapes how the business team publishes, edits, and maintains content. The decision between custom-built and open-source CMS comes down to how standard the business's needs are.

Custom CMS

What it is: a CMS built for this specific product, using technologies the development team chooses (commonly Node.js, PHP, Golang, or similar server-side languages paired with a database like MySQL or PostgreSQL).

Custom fits when:

- The business has unique workflows that standard CMS platforms don't support well. If your team's publishing process, approval chain, or content model is unusual, a custom system can match it exactly.

- Security or compliance requirements go beyond what public frameworks offer. Public CMS platforms are large targets precisely because they're widely used. A bespoke system reduces exposure to common attack patterns.

- The product will live long enough to justify higher upfront cost. Custom CMS pays back over years, not months.

- The dashboard and reporting need to map directly to business-specific KPIs. A custom back-end can produce reports that off-the-shelf solutions would require workarounds to generate.

Custom doesn't fit when: the needs are standard, the timeline is short, or the team can't commit to maintaining a bespoke codebase.

Open-source CMS

What it is: a CMS built on a widely-used open-source platform. WordPress is the most common example; others include open-source commerce platforms, Drupal, and more specialized options depending on the product type.

Open-source fits when:

- The business has standard-shape needs (content pages, blog, product catalogue, standard user flows).

- Fast time-to-launch matters more than perfect fit.

- The internal team can rely on community resources, plugins, and established patterns.

- Budget is a primary constraint.

- The product is likely to evolve incrementally rather than require unique features no plugin addresses.

Open-source doesn't fit when: the business needs patterns the platform wasn't designed for and would require extensive custom plugin development anyway (at which point you're paying custom cost with open-source constraints).

The decision in practice

Most projects fall clearly into one bucket or the other. Projects that feel like they need both (standard CMS foundation with significant customization) are often candidates for a hybrid: open-source core with custom extensions for the specific parts that need them.

Decision 2: Database

The database holds the data the product depends on. Choosing the right one starts with understanding the shape of the data: is it structured (rows and columns, like orders and customers), semi-structured (JSON documents, like product configurations), or unstructured (files, images, media)?

Relational databases (MySQL, PostgreSQL, SQL Server) fit structured data with clear relationships. If the business logic involves transactions, inventory, accounts, or anything that benefits from referential integrity and ACID guarantees, a relational database is usually the right foundation. This covers most e-commerce, CRM, and business application use cases.

Document databases (MongoDB and others) fit semi-structured data where the shape varies between records. Useful when the product needs flexibility in what fields exist on different items, or when the data model is still evolving.

Search-optimized databases (like Elasticsearch) complement primary databases when fast text search or complex filtering is a core feature. Typically added alongside a relational or document database, not as the only data store.

The practical guidance: default to a relational database unless there's a specific reason to use something else. Most projects' data fits a relational model cleanly, and relational databases have decades of tooling, talent, and operational knowledge around them. Choosing a less common database creates hiring and maintenance friction that has to be justified by a real need the relational database can't serve.

Scale considerations matter here too. A database choice that works for 1,000 users may not work for 100,000. Planning for expected scale at the start is cheaper than migrating under load later.

Decision 3: Hosting (Shared vs Cloud)

Where the product actually runs. This decision has the most visible impact on performance, reliability, and cost.

Shared hosting

What it is: the product shares a server (and its resources) with other sites. The hosting provider manages the server; you manage the application.

Shared hosting fits when:

- The product is content-focused and traffic is predictable.

- Tech stack needs are limited (typically PHP, MySQL, static assets).

- Cost predictability matters more than flexibility.

- The team doesn't have DevOps capacity.

Shared hosting doesn't fit when: the product needs to scale with traffic, runs on a stack the shared host doesn't support, or requires custom server configuration.

Cloud hosting

What it is: computing resources delivered as services, typically from a major cloud provider. You rent the resources the product actually uses and scale up or down as load changes.

Cloud hosting fits when:

- The product needs to scale with traffic (especially products with traffic spikes around launches or campaigns).

- The tech stack includes Node.js, Golang, Vue, or other modern frameworks that shared hosts often don't support cleanly.

- The business expects to grow substantially within the product's lifetime.

- Integration with cloud-native services (object storage, queues, managed databases, CDNs) adds value.

Cloud hosting doesn't fit when: the product is small and static, budget is very constrained, or the team lacks the skills to manage cloud configuration.

In practice

Many businesses use a hybrid approach. A marketing site on shared or managed hosting, a web application on cloud infrastructure. The decision isn't always "one or the other" for the whole business, and the right answer often depends on the specific product, not the company.

The underlying question is stability and flexibility now versus in two to three years. Over-provisioning for scale the business will never need wastes money. Under-provisioning for scale the business will reach creates a painful migration later. Cloud's main structural benefit is that it lets the infrastructure match actual demand rather than being guessed at upfront.

Decision 4: Third-party APIs (ownership and dependency risk)

Modern digital products rarely run in isolation. They connect to payment processors, shipping services, email providers, analytics platforms, authentication services, and many others. Each integration is a dependency.

Two types of API integrations

Internal services: APIs built by the client's own IT team, usually for existing business systems the new product needs to connect to (ERP, CRM, existing databases). Integration here is about collaborating with the client's internal team from project start to define data structure and integration patterns. Success depends on the relationship with the client's IT function, not on vendor evaluation.

External vendors: APIs from third-party service providers. Payment gateways, shipping APIs, email services, etc. These integrations are where vendor evaluation matters.

How we evaluate external APIs

Vendor evaluation is different from feature evaluation. It's not just "does this do what we need?" It's "can we depend on this company to keep doing what we need?"

The factors that matter:

- Documentation quality: Good documentation signals a vendor that invests in their developer ecosystem. Bad documentation is a predictor of future integration pain.

- Uptime track record: Public status pages or third-party monitoring data. A provider that goes down frequently will take your product down with it.

- Security posture: Compliance certifications, security history, data handling practices. Particularly important for anything touching payments, health, or regulated data.

- Pricing structure: Both current pricing and pricing trajectory. APIs that raise prices dramatically (or change pricing models) mid-integration cost meaningful money to switch off.

- Community and ecosystem: Is the API widely used? Are there libraries and integrations in the languages your team uses? An obscure API creates long-term hiring and support friction.

- Stability of the provider: Is this a viable company? Has it been around long enough to trust, and is it profitable or well-funded enough to keep operating? Small vendors with shaky finances are dependency risks.

The dependency-risk principle

Every external API is a bet that the vendor will remain stable. When vendors raise prices, get acquired, or shut down, your product has to migrate. The cost of migration is real and usually higher than anyone estimates.

The practical response: prefer vendors with longer track records and broader ecosystems for critical dependencies (payments, auth). For less critical integrations, optimization for cost or features is reasonable. But always know what the migration path looks like before committing.

Ownership vs rental: the underlying framing

The four decisions above come down to a strategic question that underlies all of them: where does the business want to own, and where does it want to rent?

Ownership means custom CMS, owned hosting, fewer external API dependencies. Higher upfront cost, more control, less dependency risk, more maintenance responsibility.

Rental means open-source CMS with plugins, shared or managed cloud hosting, third-party APIs for most non-core functions. Lower upfront cost, less control, more dependency risk, less maintenance responsibility.

Neither is universally better. The right mix depends on what's actually core to the business. A business whose competitive advantage is the quality of its e-commerce experience should probably own more of its e-commerce infrastructure. A business for whom the website is a support function can rent more freely.

The mistake to avoid is treating this as purely a technology decision. It's a strategic decision about dependency and control. Making it explicitly, not by default, is where good infrastructure choices come from.

Back-end red flags

Signs that back-end decisions are going wrong, or have gone wrong:

The CMS workflow fights the business. The team uses the CMS despite its design, not because of it. Publishing takes twice as long as it should because the tool requires workarounds.

Hosting can't scale to realistic 12-to-24-month growth. Performance degrades under expected load, and the path to handle more traffic is "move everything to a different host."

APIs with concerning uptime history or unreliable documentation. If the vendor's documentation is wrong or outdated, their API probably is too.

No migration plan for any critical third-party dependency. If the vendor disappears or changes pricing, you should know roughly what switching would cost before you sign on.

Custom back-end with no one able to maintain it. Bespoke systems are valuable only if the team can keep running them. Custom systems inherited by people who don't understand them are worse than standard systems.

These signs are worth catching early. Most of them are expensive to fix after launch and cheap to fix before.

The core takeaway

Back-end infrastructure doesn't sell the product. Users never see it. But it determines whether the product works reliably, scales with the business, and stays affordable to maintain over years.

The four decisions (CMS type, database, hosting, third-party APIs) compound more than front-end choices do. Changing them after launch is expensive. Making them deliberately at the start is cheap.

Every recommendation we make traces back to a simple principle: match the technology to the user, the business horizon, and the integration load. If those three factors are genuinely understood before the stack is chosen, the back-end decisions almost always follow.