THE DESIGN QUESTION
Which architecture choices will shape operating cost, ownership, and the effort required to change the service later?
Two teams can receive the same feature list and propose very different systems.
One may recommend extending an existing platform. Another may propose a custom application with several external services. Both approaches could support the initial screens, yet differ substantially in operating cost, ownership, and the effort required to change them later.
A feature list rarely resolves those differences.
Before development gathers momentum, the consequential architecture decisions need to be made visible. This does not require designing every detail in advance. It requires identifying which choices are expensive to reverse and giving the implementation team a coherent basis for proceeding.
Consider a specialist advisory business creating a subscription service. Customers will submit information, receive analysis, and work with advisers through a digital portal. The early design decisions extend well beyond the portal itself.
Define what the system must own
Start by identifying the responsibilities that belong to the new system.
The subscription service may need to manage customer access, collect inputs, produce an analysis, support adviser review, and publish a result. Billing, appointment scheduling, and general customer records may already be handled elsewhere.
Decide which system is responsible for each part and where the authoritative record belongs.
If both the portal and the CRM independently maintain subscription status, disagreements become possible. If every component assumes another component sends the customer notification, an important step can disappear between them.
Clear boundaries give teams something concrete to implement: responsibilities, records, interfaces, and expected behavior when a neighboring system is unavailable.
Choose what to build and what to buy
Not every capability deserves custom development.
A standard billing or scheduling service may provide what the business needs with less initial work. The analysis method or adviser workflow, however, may be central to the business’s distinctive service.
Evaluate each choice against the actual requirements.
What can the purchased service support? Which limitations would force the business to change its offering? What customization and integration work remains? Who will maintain that work?
Compare the total arrangement, including licensing, implementation, support, and the cost of working around restrictions. A low subscription price can be misleading if it requires substantial manual intervention. Custom development also creates an ongoing responsibility, even when the initial build is affordable.
The useful question is which combination best supports the service and its economics.
Place boundaries around likely sources of change
Some parts of the system will change more often than others.
The advisory business may revise its analysis method, introduce a different subscription tier, or switch an AI provider. Those changes should not necessarily require rebuilding customer access and billing.
Identify the dependencies most likely to change and decide how tightly other components should depend on them.
For example, the portal could request an analysis through a defined interface rather than embedding one provider’s request format throughout the application. That separation has a cost, so it should address a credible need.
Future flexibility is selective. Designing for every imaginable replacement can add complexity that the business never benefits from.
Understand what it would take to leave
Vendor dependence extends beyond whether data can be downloaded.
The business may accumulate customer records, analysis history, configuration, workflow rules, and integrations inside a platform. Moving away could require reconstructing several of these elements.
Before making a substantial commitment, examine:
- Which data and configuration can be exported in a usable form.
- Whether the business controls the accounts and credentials it needs.
- Which workflows depend on proprietary features.
- What would need rebuilding if the service changed or ended.
- Which contractual or licensing conditions affect transition.
A vendor can still be the right choice when switching would be difficult. The important point is to understand that dependence and decide whether its benefits justify it.
Estimate the cost of running the service
Development cost is only one part of the architecture decision.
The subscription service may incur costs for model calls, storage, document processing, third-party services, adviser review, and customer support. Some costs follow customer numbers; others follow the amount or complexity of work each customer submits.
Estimate cost per customer or case under plausible usage patterns. Include demanding cases and peak periods, not only the average demonstration.
Consider what the service promises. Fast responses, long history retention, and extensive customization can each create additional demands.
These estimates help the business make connected decisions about pricing, usage allowances, service levels, and the design itself. They also reveal where apparent automation savings may be offset by review or support work.
Give development a clear basis for decisions
The implementation team needs enough clarity to make consistent choices as details emerge.
A useful architecture brief can describe:
- The business requirements and constraints that drive the design.
- System responsibilities and the authoritative records.
- Major interfaces and failure behavior.
- Build-versus-buy decisions and their reasons.
- Expected operating costs and usage assumptions.
- Important uncertainties, decision owners, and conditions for reconsideration.
Record consequential decisions as the work progresses. The purpose is to preserve the reasoning, so that a later team can distinguish an intentional trade-off from an accidental limitation.
Architecture should evolve with implementation evidence. Clear decisions make that evolution more deliberate.
At CultureTech, we help clients connect commercial requirements with solution and software architecture, examine consequential trade-offs, and review critical implementation decisions. This gives development a clearer direction while preserving the ability to adapt as the service takes shape.
