Buy the boring part.
Choose what to build at the business capability level: own the decisions that distinguish the service, and rent what does not.
A custom application can contain an impressive amount of work nobody needed to commission.
Appointment reminders. Document signatures. A perfectly adequate address book, rebuilt with the preferred shade of blue. Each feature looks reasonable in isolation. Together they create a maintenance obligation for capabilities customers probably assumed already existed.
Our default: own the decisions and workflows that distinguish the business. Buy the ordinary services around them when they fit. Custom software should earn its place by doing work the business cannot sensibly obtain elsewhere.
The useful unit of this decision is a business capability. “Build or buy the portal” is too coarse. A portal might combine a distinctive eligibility decision with ordinary scheduling and document delivery. Those parts do not need the same answer.
Describe the work before shopping
Write down what a capability must accomplish without naming a product or drawing a screen.
“Let customers arrange a visit after their equipment passes eligibility review” gives a vendor something to demonstrate. “We need a bespoke booking experience” mostly gives a designer something to invoice.
For each capability, identify the business owner, the required outcome, and the exceptions that change how work proceeds. Separate legal or contractual requirements from habits. An established habit may deserve preservation, but it should survive a question about why it exists.
Then identify where the business makes a decision its customers value. That could be deciding which repair is appropriate or matching a specialist to a difficult job. Keep control of that logic and the information needed to explain it. Control does not require writing the calendar underneath it.
An exception has consequences
Consider a fictional equipment-service company. It needs to book visits, but certain installations require a site assessment before anyone can promise a repair appointment.
That is a meaningful exception. A booking product that lets customers bypass the assessment could commit the company to work it cannot safely perform. Ask the vendor to demonstrate the restriction, including a customer opening an old booking link. A sales representative saying “our platform is flexible” does not answer the question.
If the product can enforce eligibility through supported configuration, use it. If it cannot, consider keeping the assessment decision in a small custom workflow and handing eligible customers to the scheduling service. Confirm that the handoff cannot bypass the restriction before choosing that arrangement.
Compare this with wanting the calendar to use a different animation. That preference might improve the experience, but it does not carry the same consequence. Document the user problem and test whether the supplied interface causes it. “Our brand deserves better” is a suspiciously convenient justification for rebuilding a date picker.
A distinctive interface can matter when it materially changes how customers complete the work. Make that case directly. Don’t dress a preference up as a business constraint.
Count friction on both sides
A subscription does not remove operational work. Someone must administer access, handle vendor incidents, and keep the service configured as the business changes. Staff may need to copy information between systems or resolve cases the product cannot represent.
Try the normal journey and a difficult exception with the people who will operate it. Watch where they leave the product. An affordable license attached to a permanent spreadsheet cleanup job deserves a less flattering evaluation.
Custom development has its own friction: ongoing ownership, support, security maintenance, and the queue for changes. Put those obligations beside the vendor’s limitations. Do not compare a real vendor quote with an imaginary finished application that nobody has to maintain.
Exit deserves its own test. Ask for a sample export containing the relationships and history the business needs, not merely a contact list. Check who owns the records, what happens at termination, and whether attachments remain usable. Describe how staff would continue working during a move. “We can export CSV” is the beginning of that conversation.
The decision memo
Use a short memo for each capability, rather than a verdict on the whole application:
Capability and owner: What work must happen, and who accepts it?
Required behavior: Normal journey, consequential exceptions, and unacceptable outcomes.
Keep under business control: The decision or workflow that makes this service meaningfully different.
Options examined: Buy, configure, combine, or build. Record what each option demonstrated and what remains unknown.
Ongoing friction: Operator workarounds, administration, support obligations, and who handles them.
Exit: Records and history required, export test, contractual restrictions, and transition approach.
Decision and reconsideration trigger: Chosen boundary, accepted compromises, owner, and the change that would justify reviewing it.
Accept an ordinary scheduling screen if it handles the work properly. Spend the custom development budget on the assessment process the scheduling vendor cannot supply. Let somebody else maintain the reminder settings.