In a well-governed SAP project, a custom development is requested only after the team understands the business requirement and confirms that the required outcome cannot be met acceptably through standard process, configuration or an approved existing capability. The request is then documented, reviewed for value and architecture fit, translated into functional and technical design, estimated and approved before build. The completed development is tested against agreed acceptance criteria and moved through controlled release and transport processes.
Why “custom” needs governance
Custom development can solve genuine business needs, but every extension also creates something the organization must understand, test, secure, support and potentially adapt during future upgrades. SAP's clean-core guidance emphasizes minimizing unnecessary modifications and using released extension approaches so the core remains easier to maintain and upgrade.
That does not mean “never customize.” It means the project should know why an extension exists, who owns the requirement, what alternative was considered, and how the solution will remain supportable.
Step 1: define the business requirement
The functional consultant or business analyst should first capture the outcome, not a preconceived technical solution. Who needs the capability? What business event triggers it? What data is required? What should happen when the happy path fails? Which controls, approvals or audit evidence matter?
This is where earlier project disciplines such as Fit-Gap analysis and solution design decisions matter. A vague requirement creates vague development and difficult testing.
Step 2: prove the gap and choose the extension approach
The team reviews whether standard SAP process, configuration, workflow, analytics or another existing capability can satisfy the need. For S/4HANA environments, SAP distinguishes extensibility options such as key-user extensibility, developer extensibility and side-by-side extensibility, with clean-core principles guiding where extensions should live.
The right choice depends on the requirement, deployment model, released APIs or extension points, lifecycle expectations, security and operations. The decision should be architectural, not simply based on which developer happens to be available.
Step 3: document functional intent
Once an extension is justified, the functional specification or equivalent design artifact describes the expected behavior in business terms. Useful content includes process context, triggering conditions, inputs, outputs, validations, error behavior, authorizations, integration dependencies and acceptance criteria.
The goal is shared understanding. A developer should not have to guess what “correct” means, and a tester should be able to derive scenarios from the agreed requirement.
Step 4: technical design, estimate and approval
The technical team evaluates feasibility and defines the implementation approach. Depending on the extension, this may involve released APIs, BAdIs, ABAP Cloud development, workflows, forms, integration services, BTP side-by-side applications or other supported mechanisms. The team estimates effort and identifies dependencies and technical risks.
Governance then confirms priority, budget or capacity, architecture alignment and ownership. Small developments may use lightweight approval; high-impact extensions can require architecture or design-board review.
Step 5: build, review and unit test
During build, functional and technical teams collaborate rather than handing a document over the wall. Functional and technical collaboration is especially important when edge cases or technical constraints emerge.
Developers perform the relevant technical checks and unit tests; functional consultants validate the business behavior. Security, performance and error handling should be considered according to risk rather than added only after defects appear.
Step 6: integrate, test and release
A custom object is not complete because its unit test passes. It must work inside the end-to-end business process. System integration testing may need to prove upstream data, downstream postings, interfaces, roles and exception behavior. User acceptance testing validates that the business outcome is fit for use.
Release should follow the project's transport and deployment governance. The development identifier, specification, test evidence and approved release should remain traceable so support teams can later understand why the object exists and how it behaves.
Common weak patterns
- Solution before requirement: asking for a specific program before defining the business outcome.
- No standard-fit check: rebuilding functionality already available through configuration or supported extensibility.
- Missing acceptance criteria: making testing subjective.
- Functional/technical handoff gaps: letting assumptions replace active design collaboration.
- No lifecycle owner: delivering an extension without knowing who supports it after go-live.
Consultant thinking: every custom object creates a future obligation
The question is not only “Can we build it?” It is “Should we own this for the life of the solution?” A strong consultant makes the business value, clean-core impact, support model and testing burden visible before approval. That turns development governance into a business decision rather than a coding queue.
Key takeaway
Custom developments should be requested through evidence and governance. Define the business need, test standard fit, choose an appropriate extension approach, document expected behavior, design and estimate it, then build and test against traceable acceptance criteria. The result should solve a real gap without creating unnecessary long-term complexity.