How to Run a Custom Software Project? An Eight-Step Roadmap from Analysis to Maintenance

Custom software projects usually fail not for technical reasons, but because of unclear scopes, delayed decisions, and a lack of clarity on who approves what. In this article, we explain Cy Logic's eight-step process, the tangible output of each phase, and what is expected from the business side. Let us imagine a portal built for a real estate company to manage listings, customer enquiries, and sales processes as an example; this scenario is fictional and used solely to make the phases concrete.

1. Discovery

The goal is to define the problem in business language rather than software language. In our sample portal, the problem might be: "Listings are updated manually across three different sites, customer enquiries get lost on WhatsApp, and nobody knows which consultant talked to which customer." Output: a one-page problem definition, a stakeholder list, and success metrics.

2. Analysis

Current processes and data are examined: listing fields, enquiry sources, consultant authorities, and reporting needs. At this stage, a distinction is made between "must-haves" and "nice-to-haves." Output: a process map, data dictionary, and priority list.

3. Planning

Scope, schedule, and architecture are determined. The most critical decision here is the delivery format: instead of a big bang approach, phased delivery (listing management first, then enquiries, then sales processes) distributes risks. Output: a phased delivery plan, architectural schema, and integration list.

4. Design

The interface and data model are designed together. The data model also includes authorization rules: which consultant sees which customer, and which reports the manager can access. Output: a clickable prototype, database schema, and permission matrix.

-- Sample permission matrix row (conceptual)
-- role: consultant | resource: customer_enquiry | action: read | condition: assigned_consultant = user
-- role: manager | resource: customer_enquiry | action: read | condition: same branch
-- role: manager | resource: report | action: read | condition: none

5. Development

Modular and testable code is written. Two principles matter: each module must be deployable independently, and business rules (such as commission calculations) must live in a layer separate from the interface. Throughout development, the business side should see working software every two weeks; the "we will show it at the end" approach is the biggest risk.

6. Testing

Testing is performed at three levels: automated unit and integration tests, security checks (authorization policies, input validation, OWASP Top 10 topics), and acceptance testing with business users. Acceptance testing uses real scenarios: "A new enquiry came in, was assigned to a consultant, meeting notes were entered, and the sale was closed."

7. Deployment

Going live is handled in a controlled manner: a data migration rehearsal, a rollback plan, and intensive monitoring during the first week. The duration of running in parallel with the old system is decided in advance. Output: a deployment checklist and an operations manual.

8. Support and Growth

The release is not the end of the relationship, but the beginning. Monitoring, backups, security updates, and new feature requests are managed through a regular maintenance plan. A good practice is to evaluate usage data every quarter to see which screens are actually being used.

In a software project, the most expensive sentence is "that is not what we meant"; this sentence gets exponentially more expensive as the phases progress. It is cheapest to say during the prototyping phase.

Responsibilities of the Business Side

• Appointing a single project owner with decision-making authority.
• Reviewing and approving each phase's output within the designated timeframe.
• Sharing real data and existing documents (contract templates, price lists) on time.
• Involving end users in acceptance testing.

Integrations: Plan from the Start

Most custom software does not operate in isolation: accounting software, SMS and email services, payment infrastructure, and map services. If integration requirements regarding contracts, access credentials, and test environments are not listed during the discovery phase, they become the items that delay the launch date the most. Building a REST API and webhook-based, trackable integration layer (where every transfer is logged) reduces this risk.

Contract and Scope: How Do You Manage Uncertainty?

In custom software, scope changes as things are learned throughout the project; this is not a flaw, but its nature. The contract must acknowledge this. A practical model: analysis and design phases are carried out with a fixed scope and fixed price, while development phases are executed with phased deliveries (a defined feature set per delivery). The acceptance criteria for each delivery are written down; "we did not like it" is not an acceptance criterion, but "this scenario is not working" is.

Change Requests

When a new request arrives, three questions are asked: Is this within the scope of the current phase? If not, which phase will it be assigned to? Does it affect the current schedule? Change requests are not rejected; they are classified. When this classification is done in writing, the argument of "you said so / we did not ask for it" at the end of the project is eliminated.

Documentation: What and How Much?

It is not possible to document everything; it is possible to document the right things:

• Architectural Decisions: Why this database, why this authorization model; short decision records.
• Data Dictionary: The meaning of each table and critical column, personal data classification, and retention period.
• Operations Manual: Deployment, backing up, restoring, and troubleshooting frequently encountered issues.
• User Guide: Task-based rather than screen-based ("how to open a new enquiry").

The survival of the system if the development team changes depends on these four documents.

Testing Strategy: Which Test Goes Where?

Unit tests cover business rules (commission calculation, approval chain), integration tests cover database policies and API contracts, and end-to-end tests cover critical user flows. Automated testing of authorization policies is especially important: the rule "consultant A must not see consultant B's customer" must be verified in every release; without this test, security is left to coincidence.

// Example: authorization policy test (conceptual)
test('consultant sees only their own enquiries', async () => {
  const asConsultantA = clientFor(userA);
  const rows = await asConsultantA.from('enquiries').select('id');
  expect(rows.every((r) => r.assigned_to === userA.id)).toBe(true);
});

The First 30 Days Post-Launch

The first month after going live is the most educational period of the project. User questions, bug reports, and "actually it should work like this" requests intensify during this period. Recommendation: short weekly review meetings for this period, a prioritized improvement list, and a deployment setup where minor fixes can be published quickly. Major new features are not planned during this period, but rather after the system settles.

When Should Custom Software Not Be Built?

To be honest: if the needs are standard and a good off-the-shelf solution exists, custom software is the wrong decision. One of the outputs of the discovery phase can be this, and we will state it. Custom software makes sense for processes that differentiate you, not for tasks everyone does the same way.

At Cy Logic, every custom software project follows these eight phases; depending on the scale, the phases become shorter but are never skipped.