The first-year estimate hides the hardest questions
A team needs a customer portal. One proposal is to license a platform and configure it. Another is to build a custom application. The conversation quickly becomes a comparison between subscription fees and development hours.
That comparison is useful, but it is incomplete. Both options create ongoing obligations, and both can become expensive to change. A purchased platform can accumulate custom rules and external dependencies. A custom application can depend on a small team, poorly documented behavior, or infrastructure nobody has time to maintain.
The question I want answered early is what it would take to change direction. Understanding the cost of leaving makes the present choice easier to assess. It reveals where the team is buying useful capability and where it is accepting a commitment that deserves more thought.
Describe the workflow before comparing products
A feature list is a weak basis for this decision. Two platforms may both advertise approvals, reporting, and integrations while handling the actual workflow very differently.
For a portal, I would describe the sequence: a customer submits a request, an operator checks the supporting information, another team approves an exception, and the customer sees a final result. I would include the ordinary corrections and interruptions. Can someone amend a request? Can the operator return it for clarification? What happens to an approval already in progress?
This description gives each option the same test. The purchased platform should demonstrate the sequence using representative data. The custom proposal should explain which behaviors are straightforward and which require new design. Neither option should receive credit for a checkbox that conceals the difficult part of the work.
Ask for an export before asking for a discount
Data portability is more than a CSV of the main records. The application may also contain attachments, relationships, timestamps, comments, approval history, and identifiers used by other systems.
I would ask to see a representative export and then attempt to reconstruct a meaningful record from it. Does the export preserve relationships? Are attachments accessible independently? Can the team distinguish a current value from a historical change? Is the identifier stable enough to reconcile with another system?
A file that opens successfully does not prove a viable migration. The team needs to understand which meaning survives the export and which meaning would need to be rebuilt. That work can uncover a dependency before it becomes central to the business.
Customization creates its own platform
Buying software does not eliminate engineering. It changes where engineering happens.
A collection of workflow rules, plugins, calculated fields, templates, and integration scripts can become an application in its own right. Someone still needs to explain it, test changes, and recover when a configuration produces the wrong behavior. If those responsibilities are spread across several administrative screens, the maintenance burden may be less visible without being smaller.
I would distinguish configuration that expresses the team's workflow from customization that fights the product's assumptions. Renaming a field or choosing an approval threshold may be ordinary configuration. Building a parallel state machine because the platform cannot represent the required exception is a different commitment.
That distinction helps the team recognize when the purchase is still providing value and when it is becoming a difficult development environment.
Building creates an ownership obligation
Custom software offers control over the workflow and data model. It also creates a direct responsibility for operation, support, upgrades, and continuity.
A credible build proposal should include those costs. Who handles dependency updates? Who investigates a failed background job? Can another engineer understand the deployment and data model? What happens if the original developer leaves? How much work is required before a new integration can be added safely?
These are practical delivery questions rather than reasons to avoid building. A small, focused application with clear boundaries may be easier to operate than a large platform stretched beyond its intended use. The team should still choose it with a realistic maintenance plan.
I would also separate the distinctive workflow from commodity capabilities. The business may need custom case handling without needing custom authentication, file storage, or email transport. The most useful answer can combine purchased foundations with a deliberately narrow custom layer.
Review three plausible futures
Instead of trying to predict every requirement, I like to compare a few concrete scenarios:
- Usage doubles while the workflow stays mostly the same.
- A new business unit needs a meaningful variation.
- The team must replace the platform or transfer maintenance.
For each scenario, estimate the work, responsibility, and dependencies. Exact numbers may be unavailable. A clear range and an explanation of the uncertainty are still better than treating future effort as zero.
This exercise also gives the decision an explicit review trigger. If pricing, workflow complexity, or staffing changes beyond the assumptions, the team knows when to revisit the choice. It does not need to wait until frustration becomes an emergency.
Choose the commitment you can operate
I do not expect every system to be easy to replace. Some commitments are worth making because they provide substantial value. The useful discipline is to understand the commitment before it hardens.
A good build-versus-buy decision identifies the workflow, proves the critical fit, tests the portability of the data, and names the people who will operate the result. The cost of leaving then becomes a decision input instead of a surprise. That is a much stronger foundation than comparing a subscription invoice with the first development estimate.