Custom software is appropriate when existing alternatives do not adequately support business processes, rules or integrations. Development involves understanding the domain, modeling states and permissions, defining contracts, anticipating failures and making the product maintainable after delivery.
Engineering converts operational needs into verifiable requirements, architectural decisions and usable increments. Functional behavior matters alongside security, reliability, evolvability, performance and operability. Their relative importance depends on the system’s criticality and context.
Explore the approachActivities, depth and support are defined by the agreed scope and the conditions of the environment.
Not every problem requires new software. Market products can serve standardized processes if integration, data, security and operational needs are met. Extending a platform may address configuration gaps. Custom development becomes relevant for particular rules, specific experiences, complex integrations or control over critical components. Compare licensing, lock-in, maintenance, autonomy and migration options.
| Approach | When it fits | Trade-off |
|---|---|---|
| Adopt a product | A product fits the essential rules | Licensing, vendor dependence and migration |
| Extend a platform | The foundation works; configuration or process is limiting | Measure the cause before adding capacity |
| Integrate | Useful systems need to share data | Contracts, failures and data ownership |
| Build | Specific rules require autonomy | Maintenance, ownership and evolution |
A reference path adapted to each project.
A reference path adapted to each project.
Requirements start with processes and decisions. Identify entities, roles, rules, exceptions and project boundaries. Use cases should describe expected outcomes and invalid situations, not only screens. Align domain language: an “approved order” may mean different things to different teams.
Define responsibilities, interfaces, persistence, integrations and nonfunctional requirements. Evaluate transactions, concurrency, consistency, data growth and deployment. Modular monoliths, distributed services and queues have different testing, observability and operational costs.
Smaller releases validate rules with users before incorrect assumptions spread. Work includes implementation, code review, dependency management, database migrations and continuous integration. Agile delivery still needs documentation and traceability.
Match test levels to risks: units for isolated logic, integration for contracts and persistence, end-to-end tests for critical journeys and security or load checks when necessary. Representative environments and controlled data reduce production surprises.
Assess configuration, secrets, data migration, compatibility, monitoring and rollback. Automated deployment still requires decisions on change windows, communication and contingency. Gradual releases or feature flags can reduce exposure where appropriate.
Telemetry, incidents and user feedback inform the backlog. Maintenance includes corrections, dependency updates, performance reviews and changing business rules. Establish ownership and a process for prioritizing changes.
A system can perform its main function and still be unsuitable for operations. Performance describes times and volumes under specified conditions; availability depends on architecture and operations; security involves identity, authorization, data and updates; observability explains production behavior. Define measurable scenarios rather than vague promises of speed or unlimited scale.
New development does not always require a full rewrite. Isolating modules, exposing APIs, documenting contracts and gradually replacing capabilities can allow operations to continue during modernization.
Consider hidden dependencies, data quality, migration sequencing and the cost of running old and new implementations together. Architecture should support replacement and testing without multiplying services or abstractions without evidence of benefit.
Under review → rejected if approval rules are not met.
A transition only happens when its condition is valid. Tests also cover rejected paths.
Depending on the contract, a system also needs behavior specifications, configuration and deployment instructions, interface documentation, decision history, migration scripts, access controls, relevant tests and operating guidance. Their absence makes onboarding harder and concentrates critical knowledge in the original team.
Specific systems and components can be built from agreed requirements, workflows, integrations and acceptance criteria. Features and priorities are defined during project planning.
It generally covers discovery, modeling, architecture, incremental construction, testing, deployment and evolution. Stages can overlap or change according to size, criticality and product maturity.
Testing is planned around system risks and interfaces. It may include automated unit and integration tests, critical flow validation and necessary security and performance checks.
Architecture can be sized and evolved for agreed volumes and usage. Scalability depends on infrastructure, data, concurrency, cost and observability; unlimited capacity cannot be guaranteed generically.
Maintenance and evolution can be contracted, including fault correction, component updates and prioritized improvements.