Choose your next move

Build, buy, extend—or change nothing?

Buy when an existing product fits the work. Consider a custom build when a specific requirement remains unmet and you can fund its development and ongoing care.

First checks

Prove the problem first
A disliked interface or hypothetical future feature is not yet a reason to own custom software.
Start with the smallest change
Test no purchase, process repair, configuration, and standard products before adding technical ownership.
Price the owner, not just the build
Updates, security, integrations, data recovery, support, and change requests need named owners.
Plan the exit before entry
Know how bookings, customers, money states, configuration, and operational knowledge can leave the route.

Choose the work you want to take on

Configure ready-made software

Use a supported product when its booking, payment and integration rules cover your needs. Budget for setup, subscriptions and staff training.

Compare ready-made software

Plan a custom booking system

Start with the exact gap, your users and the rules a developer must implement. Plansmith’s downloadable planner guides a coding agent through discovery and produces a build specification.

Explore the Plansmith booking planner

You still need to build, test, host and maintain the application.

Route-boundary checker

What has earned the right to be tested next?

Record what is proven about the requirement, current process, ownership, standard routes, integrations, extensions, maintenance, and exit. The result identifies a next evidence step, not a product or purchasing decision.

Requirements map

Current material problem

Ownership requirement

Hosted-route test

Self-hosted-route test

Integration route

Product-extension route

Maintenance ownership

Exit path

Your synthetic boundary result

Test one bounded integration next

Test whether one bounded integration closes the proven gap. Define the system of record, identifiers, retries, reconciliation, owner, and removal path.

Route in view: A bounded integration
Requirements: Complete synthetic map
Material problem: Proven gap
Ownership requirement: managed acceptable
Hosted route: Failed the must-have
Integration route: Next test

This checker stores nothing, runs no product test, and cannot approve a purchase, integration, extension, or custom build. A route that reaches a boundary still needs current product evidence, controlled testing, responsible owners, and human approval. This is a deterministic planning result, not a product verdict, purchase recommendation, project estimate, security review, or implementation authorization.

The least-complexity rule

Every extra layer creates another system the business must own.

The useful question is not whether software can be built. It is whether a simpler route has failed a material requirement, whether the proposed route closes that exact gap, and whether the business can operate, recover, change, secure, and eventually leave it.

The route-earning rule

Route earned = proven requirement gap + simpler routes tested + named operating owner + bounded failure and recovery + acceptable change cost + usable exit

A synthetic business may find that its current process is adequate, that a hosted plan passes the hard workflow, that one integration closes a bounded gap, or that every simpler route fails the same documented requirement. Only the last case earns a custom requirements brief—and still does not authorize development.

Choose your starting point

A custom booking system is not automatically more flexible, and hosted software is not automatically simpler. The least-complexity route is the one that meets the proven requirements while leaving the business with an understood owner, failure path, maintenance burden, and exit.

Find the next route to test without turning the result into a vendor recommendation.

I have never used booking software

Start with one real appointment or reservation workflow and check whether clearer rules, a form, or the current calendar already solves the problem.

Where this leads: Use the beginner guide first if booking, appointment, reservation, and calendar terms are still unfamiliar.

I need to choose a route

Use this guide to test no purchase, process repair, hosted software, self-hosting, integration, extension, and custom ownership in that order.

Where this leads: A route earns only the next controlled test; it is not yet a product recommendation or purchase approval.

I need to design or code the system

Use this page to decide whether a custom brief is justified and to define acceptance, ownership, recovery, maintenance, and exit boundaries.

Where this leads: Database, PHP, API, security, privacy, infrastructure, and implementation choices belong in a separate technical design review after the custom brief is earned.

Follow the complete six-step route decision

Write the workflow before naming a route
Describe who requests, approves, changes, fulfills, pays for, reports on, and recovers each booking. Include staff, locations, resources, time zones, messages, payments, integrations, exports, and exceptions.
Separate must-haves from preferences
A must-have prevents an unsafe or unusable workflow. A preference improves convenience. Record the exact failure and acceptance test so a preference cannot quietly become a custom-build requirement.
Test no purchase and current-process repair
Check whether clearer rules, a form, a shared calendar, staff training, configuration, or removing an unnecessary step solves the material problem without adding another system.
Test standard ownership routes
Use the hardest requirement to test hosted software and, only when control is truly required, a self-hosted route. Compare the complete workflow and exit—not a feature-list label.
Bound integration and extension
Name the system of record, identifiers, data direction, retries, failure visibility, support owner, maintenance surface, security responsibility, and removal path before connecting or extending anything.
Prepare a custom brief only after proven failures
A custom route begins with acceptance tests, ownership, recovery, security, maintenance, change, and exit requirements. Development starts only after separate approval, estimates, qualified review, and a controlled delivery plan.

Compare all eight decision axes

Requirements

What exact customer and staff transaction must succeed?

Evidence to collect: A written fixture, must-haves, disqualifiers, exceptions, and acceptance states.

Ownership

Who controls configuration, code, infrastructure, accounts, and operating decisions?

Evidence to collect: Named business, vendor, implementation, and technical owners with access boundaries.

Maintenance

Who handles updates, monitoring, backups, support, dependencies, and change requests?

Evidence to collect: Recurring tasks, response expectations, skills, access, time, and cost assumptions.

Integrations

Which system owns each record and what happens when a connection fails?

Evidence to collect: Identifiers, direction, retries, reconciliation, alerts, recovery, and removal tests.

Data portability

Can complete records and their relationships be understood elsewhere?

Evidence to collect: Export scope, stable identifiers, time and money meaning, custom fields, and rehearsal.

Failure handling

How does the business detect, contain, recover, and reconcile a failed booking journey?

Evidence to collect: Visible errors, stop conditions, continuity, rollback, recovery, and record comparison.

Security responsibility

Who protects identities, permissions, secrets, customer data, updates, and incident response?

Evidence to collect: Qualified review of the actual deployment, data, roles, vendors, and jurisdiction.

Change and exit

How expensive is the next change, and how can the business leave?

Evidence to collect: Change path, dependency map, documentation, export, migration, overlap, closure, and disposal plan.

Compare the seven build, buy, and extend routes

Buy or build nothing

No material workflow failure is established, or the value of changing is lower than the disruption.

Ownership: The business keeps the existing operating process and names its manual controls.
Failure boundary: Known gaps remain visible rather than being disguised as software work.
Exit boundary: No migration is created; revisit only when the workflow or failure cost changes.

Keep and configure the current process

A bounded rule, form, calendar, permission, training, or configuration change closes the proven gap.

Ownership: The existing process owner records the changed rule and maintains it.
Failure boundary: Test the original failure plus the next likely change or exception.
Exit boundary: Reverse the configuration or process change without losing booking records.

Buy hosted booking software

The quoted plan passes the must-haves and its managed-service boundary is acceptable.

Ownership: The vendor owns the hosted product; the business still owns configuration, users, data decisions, and continuity.
Failure boundary: Test customer and staff transactions, integrations, support, degraded service, and export.
Exit boundary: Verify usable records, contract terms, overlap, migration effort, and account closure before purchase.

Use WordPress or another self-hosted route

Hosting or site-level control is a real requirement and the business can own the extra technical surface.

Ownership: Hosting, application, extensions, updates, backups, security, monitoring, and recovery need explicit owners.
Failure boundary: Test dependency conflicts, update recovery, cache behavior, integrations, and restored transactions.
Exit boundary: Preserve portable data and configuration knowledge separately from a restorable site backup.

Integrate existing systems

A bounded connection closes one material gap without creating an ambiguous system of record.

Ownership: Each endpoint, credential, identifier, mapping, retry, alert, and reconciliation task has an owner.
Failure boundary: Test delay, duplication, partial success, stale data, rejected records, credential expiry, and replay.
Exit boundary: Disconnect safely, reconcile remaining records, revoke access, and retain the required history.

Extend an existing product

A supported extension point closes the gap while the base product remains the appropriate system of record.

Ownership: The extension's code or configuration, compatibility, updates, tests, and support need a continuing owner.
Failure boundary: Test base-product updates, extension errors, permission boundaries, data writes, and safe disablement.
Exit boundary: Remove the extension without stranding essential data or breaking the base booking workflow.

Commission a custom build

Every materially simpler route has failed the same documented must-have and custom ownership is justified.

Ownership: Product decisions, delivery, code, infrastructure, security, operations, support, recovery, documentation, and succession all need owners.
Failure boundary: Test the complete booking lifecycle, abuse cases, dependencies, degraded service, recovery, reconciliation, and operational handoff.
Exit boundary: Require source, documentation, access, data portability, dependency inventory, transition support, and closure terms before development.

Handle route changes and red flags

A requirement changes

Return to the transaction

Rewrite the fixture, must-have, disqualifier, and acceptance state before comparing routes again.

A standard product changes

Retest the dated plan

A new feature, removed feature, plan limit, integration, term, or ownership change can reopen a route that previously failed or disqualify one that passed.

An integration becomes critical

Treat it as operated infrastructure

Recheck system-of-record ownership, credentials, monitoring, retries, reconciliation, recovery, support, security, and removal.

The team or technical owner changes

Reopen the ownership gate

A self-hosted, extended, integrated, or custom route can become unsafe when knowledge, access, maintenance time, or incident responsibility disappears.

Data or regulatory scope changes

Stop for qualified review

New sensitive data, payment, identity, health, child, retention, accessibility, security, privacy, or jurisdictional obligations can change every route boundary.

Exit becomes harder

Measure lock-in before adding dependence

Recheck export completeness, relationships, documentation, contract terms, dependency removal, overlap, migration, access revocation, and disposal.

“We can build it” replaces the requirements

Technical possibility does not establish operating value, safe ownership, delivery scope, maintenance, or acceptance.

A feature-list gap becomes custom scope

First prove the exact transaction fails on simpler routes; a missing label or demo impression is not enough.

The build price excludes ownership

Hosting, dependencies, monitoring, support, security, recovery, changes, documentation, and succession continue after launch.

An integration has no system of record

When ownership, identifiers, failure visibility, retries, reconciliation, and removal are unclear, the connector creates rather than closes risk.

There is no credible exit

A route is not ready when the business cannot recover understandable records, revoke access, transfer knowledge, and keep operating during migration.

Use one hard workflow to eliminate routes fairly.

Choose the most decision-sensitive customer or staff transaction. Give each plausible route the same fixture and record the first material boundary it cannot cross.

Write one complete fixture with start state, actors, booking rules, money, messages, integrations, expected records, changes, failures, recovery, and exit.
Test routes from least to most ownership: nothing, current process, hosted, self-hosted when required, bounded integration, bounded extension, then a custom brief.
Record pass, fail, unknown, workaround, owner, evidence, limitation, and the exact trigger for reconsidering the route.