The Custom Software Development Process: From Requirements to Reliable Software

A sound custom software development process begins with the businessproblem, not the code. It establishes what people need to achieve, howthe organisation works, which information and rules matter and whethercustom development is justified at all.

The process then reduces uncertainty in stages: discovery,requirements, prototyping, architecture, iterative delivery, testing,deployment and ongoing improvement. Each stage should produce evidencefor the next decision—not simply documents or code because a projectplan says they are due.

This matters because custom software can fit a business far betterthan a standard package, but the organisation also assumesresponsibility for the application's design, security, quality andlong-term ownership.

What is custom softwaredevelopment?

Custom software development is the creation of an application for thespecific requirements of an organisation or defined group of users. Itmay support a distinctive workflow, replace spreadsheets and legacysystems, connect existing products or create a new digital service.

Examples include:

• A manufacturer’s production-planning application.
• A specialist quotation and pricing system.
• A customer or supplier portal.
• A field-service and scheduling application.
• An approval and compliance workflow.
• A system connecting CRM, ERP and operational data.
• A new software product offered to customers.

Custom does not have to mean that every component is written fromscratch. A sensible solution can combine standard services, open-sourcecomponents, configurable platforms and purpose-built logic.

When is customdevelopment the right choice?

Developing software is expensive compared with adopting a simpleproduct that already meets the requirement. Custom development becomesmore attractive when:

• The process is genuinely distinctive.
• Existing systems force costly or risky workarounds.
• Integration is central to the operation.
• The required user experience creates business value.
• The organisation needs control over future changes.
• A standard product carries unnecessary complexity.
• The application itself is a commercial product.

Before approving development, compare at least four options:

OptionSuitable whenMain riskChange the processThe problem comes from unclear responsibilities or unnecessarystepsThe business may treat software as the answer to a managementissueBuy standard softwareRequirements are common and the organisation can adopt the product'smodelProcesses may be forced into an unsuitable structureConfigure or extend a platformMuch of the requirement can use existing services andcomponentsComplex configuration can create its own dependency and maintenanceburdenBuild custom softwareDistinctive requirements justify greater control andresponsibilityCost, delivery risk and long-term ownership

The discovery phase should be allowed to conclude that customsoftware is not worthwhile. The GOV.UKService Manual explicitly notes that stopping after discovery cansave time and money when research shows that proceeding is notjustified.

The customsoftware development process at a glance

The stages overlap in an iterative project, but each has a distinctpurpose.

StageMain questionTypical evidence1. DiscoveryIs there a worthwhile problem to solve?User research, process map, risks and options2. RequirementsWhat must the service achieve?Prioritised outcomes, rules, data and quality needs3. PrototypeWhich solution is usable and feasible?Tested workflows and technical experiments4. ArchitectureHow will it remain secure and maintainable?System boundaries, data model and integration design5. PlanningWhat is the smallest useful release?Delivery slices, estimates and decision points6. DevelopmentCan working increments be delivered reliably?Tested, reviewed and deployable software7. ValidationDoes it work for users and the business?Acceptance, security and operational evidence8. LaunchCan the organisation run it safely?Migration, training, monitoring and recovery plans9. Live operationIs it delivering value sustainably?Usage, outcomes, incidents and improvement backlog10. RetirementHow will users and data move safely?Exit, archive and decommissioning plan

The GOV.UK model describes a comparable lifecycle of discovery,alpha, beta, live and retirement. Its value is not the terminology butthe discipline of learning before building and continuing improvementafter launch. GOV.UK: Agiledelivery

Stage 1: Discover the realproblem

Discovery creates a shared understanding of users, processes,constraints and value. It should include the people who perform thework, not only managers and project sponsors.

Investigate:

• Who experiences the problem?
• What are they trying to achieve?
• How is the work completed today?
• Where do delays, errors and duplicate effort occur?
• Which exceptions consume disproportionate time?
• What information is created or changed?
• Which systems, spreadsheets and manual steps are involved?
• What would improve if the problem were solved?
• How will the organisation recognise success?

Observe real work where possible. A process described in a meetingoften differs from the process used on a busy Monday morning.

Produce a problem statement

A useful problem statement is specific without prescribing thesolution:

Service requests arrive through email, telephone and web forms. Staffre-enter information into two systems, ownership is unclear andcustomers cannot see progress.

“Build a service portal” is already a solution. Discovery shouldfirst test whether a portal addresses the causes and whether users willactually use it.

Identify uncertainty andrisk

Create a risk list early. Include uncertain business rules, poorsource data, difficult integrations, adoption concerns, legalobligations, security exposure and dependency on a single expert.

The highest-risk assumptions should shape the prototype and earlydelivery plan.

Stage 2: Define andprioritise requirements

Requirements should describe outcomes and constraints clearly enoughto guide design and testing. They do not need to predict every screenbefore learning begins.

Capture several types of requirement.

Functional requirements

These describe what users and the system need to do:

• Create and assign a request.
• Validate the customer's service entitlement.
• Route an exception to a supervisor.
• Notify the customer of a material status change.
• Record who approved a decision and when.

Data requirements

Define important entities, relationships, ownership and qualityrules. Decide which system is authoritative for each key item.

For example, the new application may display customer details fromthe CRM but own the service request and its status history.

Business rules

Record calculations, validations, approvals, permissions andexceptions as explicit rules. Give important rules an owner and testexamples.

Non-functional requirements

These include accessibility, security, privacy, availability,performance, retention, audit, recovery, hosting and support. Theyinfluence architecture and cost, so they cannot wait until the end.

Prioritise by outcome andrisk

Separate the minimum useful release from later improvements. Arequirement is not essential merely because an influential personrequested it.

For each item, ask:

• Which user or business outcome does it support?
• What happens if it is deferred?
• Does another requirement depend on it?
• Does it reduce a major risk or uncertainty?
• How will acceptance be tested?

Stage 3: Prototype theuncertain parts

A prototype is a learning tool, not proof that the application isnearly finished.

Prototype the difficult workflow, unfamiliar technology or riskiestintegration—not just the attractive dashboard. The GOV.UK alpha guidancerecommends trying different solutions and testing ideas based on whatdiscovery revealed. GOV.UK:How the alpha phase works

Different questions require different prototypes:

• Paper sketches for process and screen flow.
• Clickable designs for usability.
• A small coded interface for interaction and accessibility.
• A technical spike for integration, performance or deployment.
• A data-migration experiment using representative records.

Do not build production security and scalability into a disposablevisual prototype. Equally, do not mistake a convincing visual prototypefor evidence that integrations, permissions and data migration willwork.

Test prototypes withrepresentative users

Ask users to complete realistic tasks without being coached. Observewhere they hesitate, misinterpret information or choose an unexpectedroute.

Good questions include:

• What would you do next?
• What information is missing?
• Why did you choose that action?
• What mistake might someone make here?
• How would this work when the normal process fails?

Stage 4: Designthe architecture and data model

Architecture translates the requirement into maintainable systemboundaries and responsibilities.

Decide:

• Which capabilities belong inside the application?
• Which systems remain sources of truth?
• How will components communicate?
• Where will business rules run?
• How will identity and permissions work?
• How will data be validated and audited?
• What happens when an external system is unavailable?
• How will the application be built, configured and deployed?
• How will it be monitored, backed up and restored?

Prefer the simplest architecture that meets the known requirements. Adistributed collection of services is not automatically more scalable ormaintainable than a well-structured application.

Plan integrations asproducts, not cables

For every integration, specify ownership, interface, authentication,data mapping, frequency, error handling, retry, reconciliation andmonitoring.

Legacy software may require supported file exchange, database access,middleware or a local agent when no API exists. Avoid direct writes toanother product's database unless explicitly supported by its owner.

Make security part of thelifecycle

Security should influence requirements, design, development, testingand operation. The NIST Secure SoftwareDevelopment Framework provides high-level practices that can beincorporated into different software-development lifecycles. For webapplications, the OWASPApplication Security Verification Standard provides a basis forspecifying and testing technical security controls.

Define relevant controls before implementation so that they can bedesigned and tested rather than added hurriedly before launch.

Stage 5: Plan usefuldelivery increments

Break the application into end-to-end operational slices. Each sliceshould support a meaningful user outcome across interface, logic anddata.

A poor sequence might deliver:

1. All database tables.
2. All APIs.
3. All screens.
4. Testing at the end.

A better first slice might allow one team to receive, assign, updateand complete a basic service request. Later slices can add customeraccess, advanced routing and management reporting.

This provides earlier feedback and reduces the amount of unfinishedwork.

Estimate uncertainty, notjust effort

Early estimates should be ranges with stated assumptions. A precisedate based on unclear requirements is not more reliable because itappears in a spreadsheet.

Update forecasts as prototypes, integrations and data analysis reduceuncertainty. Make scope, cost and schedule trade-offs visible to theproduct owner.

Agree decision points

At the end of discovery, prototype and early delivery, decide whetherto:

• Continue.
• Change the proposed approach.
• Reduce or expand scope.
• Buy or configure instead of build.
• Pause for missing information.
• Stop the project.

Stopping weak work early is successful governance.

Stage 6: Develop inshort, controlled cycles

Iterative development does not mean building without a plan. It meansdelivering small increments, reviewing evidence and adjusting the planwhile preserving engineering discipline.

A healthy development cycle includes:

• A clear objective for the increment.
• Small, reviewable changes.
• Automated checks and tests.
• Peer review.
• Integration with the main codebase frequently.
• Deployment to a representative test environment.
• Demonstration to users and stakeholders.
• Updates to requirements and documentation.

Keep business logic consistent across interfaces, imports and APIs.Important rules should not be scattered through individual screens.

Maintain a reliabledelivery pipeline

Automate repeatable build, test and deployment steps where practical.Keep environment-specific configuration and secrets outside source code.Record application versions and database changes so releases can bereproduced and diagnosed.

The goal is not automation for its own sake. It is to reduceavoidable variation and make smaller releases safer.

Stage 7: Test the completeservice

Testing should show that the application works technically andoperationally.

Include:

• Unit and component testing.
• API and integration testing.
• End-to-end process testing.
• Permission and separation-of-duty testing.
• Boundary values and invalid data.
• Integration failure and recovery.
• Data migration and reconciliation.
• Security verification.
• Accessibility testing.
• Performance with representative volumes.
• Backup and restoration.
• User acceptance testing.

Accessibility is easier to achieve when designed and testedthroughout delivery. The W3C recommends using the latest WCAG 2 version;WCAG 2.2covers requirements for making web content more accessible to peoplewith disabilities.

Derive tests fromrequirements

Every significant rule should have examples that demonstrate expectedbehaviour.

If discounts above 15% need management approval, test:

• A discount below the threshold.
• A discount exactly at the threshold.
• A discount above it.
• An authorised and unauthorised requester.
• Approval, rejection and cancellation.
• Audit and notification behaviour.

This makes requirements executable and exposes ambiguity beforeproduction.

Stage 8:Prepare data, users and operations for launch

Software is not ready because the code compiles and the test suitepasses.

Before launch, prepare:

• Cleansed and reconciled migration data.
• User accounts, roles and access approval.
• Training and task-based guidance.
• Support routes and escalation.
• Monitoring and alert ownership.
• Backup and recovery procedures.
• An incident plan.
• A deployment and rollback plan.
• Communication with affected teams and customers.
• A decision on how the old system will be retained or retired.

Use rehearsals for migration and high-risk operational procedures.Record timings and discrepancies rather than assuming the final cutoverwill behave differently.

Choose a suitable rollout

Options include:

• Pilot with one team or location.
• Phased release by capability.
• Parallel running for a limited period.
• Controlled migration by customer or record group.
• A single cutover when coexistence is impractical.

The right approach depends on the cost of failure, integrationconstraints and whether old and new systems can operate consistentlytogether.

Stage 9: Run andimprove the live application

The live phase is part of the development process. GOV.UK describesit as supporting the service sustainably while continuing to iterate andimprove it. GOV.UK:How the live phase works

Measure outcomes, not only availability and ticket counts:

• Are users completing the process?
• Has error or rework reduced?
• Where do users abandon or leave the system?
• Which exceptions are growing?
• Are integrations reconciling correctly?
• Is the application producing the intended business benefit?

Maintain a prioritised backlog that includes defects, securityupdates, operational improvements, accessibility and technical debt—notonly new features.

Assign a product owner who can make decisions after launch. Withoutactive ownership, custom software gradually reflects the loudest requestrather than a coherent product direction.

Stage 10: Plan eventualretirement

Every custom application will eventually be replaced, consolidated orretired.

Plan for:

• Complete data export in documented formats.
• Retention and deletion obligations.
• Transfer of users and integrations.
• Read-only access to historical records where required.
• Removal of credentials, infrastructure and unused accounts.
• Archiving source code, configuration and documentation.
• Communication and support during transition.

An exit route designed from the beginning improves data portabilityand reduces future dependency.

Who should be involved?

The exact team depends on the application, but the responsibilitiescommonly include:

• Product owner: owns outcomes, priorities andacceptance.
• Business analyst: investigates processes, data andrules.
• User researcher or UX designer: represents userneeds and tests usability.
• Software developers: design and implement theapplication.
• Technical architect: guides system boundaries andquality attributes.
• Test specialist: develops risk-based testcoverage.
• Security and privacy specialists: assess relevantcontrols and obligations.
• Operations or platform engineer: owns reliabledeployment and operation.
• Data and integration specialists: handle migrationand system connections.
• Representative users: validate real work ratherthan imagined workflows.

One person may cover several roles in a small team, but none of theresponsibilities disappears.

Common process failures

Starting with a preferredsolution

A supplier demonstrates its platform before understanding thebusiness. Requirements then become a justification for that choice.

Treating agile as “norequirements”

Iterative delivery changes how requirements are explored and refined.It does not eliminate the need to understand outcomes, data, rules andconstraints.

Building the easy screensfirst

The project looks busy while difficult integrations and exceptionworkflows remain unresolved.

Leavingsecurity and accessibility until testing

Late discovery of architectural problems creates expensive rework andpressure to accept risk.

Underestimating migration

Real data exposes duplicate identities, missing values and historicalbehaviours that were invisible in the proposed data model.

Launching without ownership

Users receive software, but nobody has authority and budget toimprove, support or eventually retire it.

HowSevenlake aims to support a different development process

Conventional custom projects repeatedly build similar foundations:forms, data handling, permissions, navigation, imports, APIs andworkflow infrastructure. This work is necessary, but much of it is notunique to the business problem.

Sevenlake is exploring a metadata-first platform for ERP, CRM andcustom operational applications. The intended model is that developersand consultants would define more of the application through structuredmetadata and reusable platform services, with AI assisting creation andcustomisation from business requirements.

The planned direction includes:

• Metadata-driven application definitions.
• User interfaces generated or rendered from metadata.
• Reusable and composable modules and templates.
• AI-assisted creation and customisation.
• Extensibility for developers.
• Data import, export and API-based interoperability.
• A goal of cloud or self-hosted deployment choice.
• An open-source core and future community participation.

This would not remove discovery, architecture, validation or skilleddevelopment. Those are the activities that make custom software fit thebusiness. The aim is to reduce repeated infrastructure work and keeprequirements, data, rules and interfaces within a more structuredapplication model.

Sevenlake is currently at the vision and architecture stage, movingtowards a proof of concept. It is not yet a production-ready developmentplatform, and its runtime, SDK, modules and marketplace remain plannedrather than available.

Frequently asked questions

Whatare the stages of the custom software development process?

The main stages are discovery, requirements, prototyping,architecture, planning, iterative development, testing, launch, liveimprovement and eventual retirement. They overlap, but each shouldanswer a different decision question.

How long doescustom software development take?

There is no reliable universal duration. Timescale depends on scope,uncertainty, user availability, integrations, migration, security andquality requirements. Discovery and prototypes should reduce uncertaintybefore the organisation commits to a full delivery forecast.

How much does customsoftware cost?

Cost depends on the team, duration, platform, integrations andoperational responsibilities. Include discovery, design, migration,testing, hosting, support, security, updates and eventualreplacement—not only programming.

Shouldrequirements be completed before development begins?

The core problem, outcomes, constraints and high-risk requirementsmust be understood before substantial development. Detail can then berefined iteratively as prototypes and working software produceevidence.

What isthe difference between a prototype and an MVP?

A prototype tests an idea and may be disposable. A minimum viableproduct is a live product intended to deliver value to real users. AnMVP still needs appropriate security, accessibility, support, monitoringand recoverability.

Who owns custom softwareafter launch?

The commissioning organisation needs clear product, technical andoperational ownership. A supplier may provide support, but the businessshould retain authority over priorities, data, access, contracts and theexit route.

Build evidence beforebuilding scale

The best custom software development process does not attempt toremove every uncertainty at the beginning. It identifies the importantuncertainties and addresses them in the right order.

Understand the problem before selecting the solution. Prototype theriskiest workflows. Deliver useful end-to-end increments. Buildsecurity, accessibility and operations into the process. Measureoutcomes after launch and preserve a route to change or retire theapplication later.

Sevenlake is being developed around the idea that skilled developersshould work closer to the business requirement while reusing more of thecommon application foundation. If that direction interests you, explore Sevenlake fordevelopers, view the publicroadmap or follow developmenton GitHub.