How to Build Successful Custom Software? | Real-World Experiences of a Developer

Introduction

Throughout my years of working in software design and development, many clients have contacted me and explained that their software projects had encountered problems after significant amounts of time and money had already been invested. Some came to me to investigate the cause of the problem and seek advice, while others wanted their existing software to be fixed, extended or even rewritten from scratch.

In many of these projects, the root causes could be traced back to issues that, if properly considered before the project began, could have prevented many of the problems that appeared later.

These experiences showed me that the success of a software project takes shape long before coding begins.

In this article, I do not intend to discuss software design principles, programming language selection or specific technologies. Instead, I want to share some of the experiences I have gained from real-world projects; experiences that show how certain decisions, oversights and even incorrect advice can change the direction of a software project.

The goal of this article is to understand that if we are going to build custom software, requirements, processes, design and early decisions can have a significant impact on the success or failure of the project.

Some of these experiences are included in this article. You can read more examples of real-world events and challenges in the Real-World Experiences section .

1. Why Do Software Projects Fail?

When we talk about the failure of a software project, we are not only referring to a project that was abandoned halfway through or never reached the implementation stage.

In my view, a software project can be considered unsuccessful when it ultimately fails to achieve the goal for which it was created — whether because it takes more time and money than expected, delivers inadequate quality, or fails to meet the customer's actual needs.

The most important causes of software project failure include:

• Misunderstanding the customer's actual needs
• Starting development without sufficient analysis
• Failing to clearly define the project scope and commitments
• Inadequate software design for future development
• Making changes without assessing their impact on other parts
• Inadequate training and support
• Misdiagnosing the causes of software problems
• Neglecting security, backup and preparedness for unexpected situations

In the following sections, we will examine the most important of these issues in greater detail, along with experiences from real-world projects.

2. Identifying Customer Needs and Thorough Analysis Before Development

One of the most important mistakes that can put a software project on the wrong path from the very beginning is starting development without fully understanding the customer's actual needs and business processes.

Customers usually know their own business better than anyone else, but they may not mention every detail of a process when explaining what they need. The developer's job is also more than simply carrying out the initial request; by asking the right questions, the developer should gain a better understanding of the actual problem and workflow.

2.1. When the Initial Request Is Not the Customer's Entire Need

In one of the projects I worked on during the early years of my professional career, the manager of a factory asked me to design a simple system for sending letters to the administrative department.

Before starting, I also suggested some ready-made software available on the market, but he believed their features went beyond his needs and that he only wanted a simple system.

I therefore designed the software based on that initial explanation, without fully reviewing and finalizing the complete correspondence process with him.

After installation, the first letter was sent, but a series of new questions immediately arose:

How should the administrative department respond? How should the manager view the response? How should the letter be signed? How should it be forwarded to another department and followed up?

That was when I realized that what initially appeared to be simply "sending a letter" was actually part of a complete correspondence process.

This experience taught me that what a customer initially describes is not always their complete actual need. Before starting development, the real workflow must be understood and the necessary questions must be asked.

2.2. When a Simple Form Is Not Just a Form

In another project, I was asked to design an online form for registering the details of customers purchasing card payment terminals and activating the devices.

At first glance, the project looked like nothing more than a form. However, examining the process showed that behind the form were information validation, matching the device and customer details, sending a one-time password, error handling, information security, as well as management and customer panels.

For this reason, I estimated the project would take longer than it initially appeared.

This experience showed that the apparent simplicity of a request does not necessarily mean that the project itself is simple. To estimate time and cost, the processes behind the request must also be understood.

You can read the details of this experience in The Experience: "When a Simple Form Took 20 Days" .

Summary of This Section

These two experiences demonstrate a common point from two different perspectives:

Before writing code, the real problem and the actual business process must be properly understood.

Sometimes an initial request represents only part of the customer's actual needs, while something that appears simple may contain significant complexity behind the scenes.

Therefore, thorough analysis before development is one of the most important stages in building custom software.

3. What Should Be Defined and Agreed Upon Before Starting a Software Project?

One of the most important tasks at the beginning of a software project is defining its overall framework and key details.

Once the customer's needs and business processes have been properly examined, we need to determine exactly what is going to be built, what outputs must be delivered, what each party is responsible for, what the project schedule and delivery date will be, and how the cost will be calculated and paid.

The clearer these matters are before development begins, the lower the likelihood of disputes, unexpected changes and later problems.

3.1. The Project Scope Must Be Clear

From the beginning, it should be clear which features are included in the project and which items fall outside the original agreement.

During the project, requests may arise for new features, additional reports, integration with other systems or a mobile version. Each of these may represent a new feature or even a separate project.

Therefore, it should be clear what is part of the project and what constitutes a new request.

3.2. The Timeline and Delivery Date Must Be Defined

The project timeline should be determined based on the amount of work, complexity, implementation stages and the commitments of both parties.

Simply stating a general timeframe such as "around three months" without defining the project stages can lead to disputes later, especially when it is unclear at which stage a delay occurred and what caused it.

It is better for the project schedule to be defined based on specific stages and commitments.

3.3. Cost and Payment Terms Must Be Clear

From the beginning, it should be clear exactly which features and services the project fee covers, at which stages payments will be made, and how requests for new features will affect the cost.

Project changes can affect both the time and cost of implementation; therefore, the way changes are handled should be defined from the start.

3.4. The Responsibilities of Both Parties Must Be Defined

A software project is not limited to the developer's responsibilities.

The client may also be responsible for tasks such as providing accurate information, approving processes, responding to questions, testing and approving delivered components.

If these responsibilities are not clearly defined, delays in providing information or making decisions can bring the project to a halt and ultimately lead to disputes.

3.5. Software Rights and Ownership Must Be Defined from the Beginning

One issue that can sometimes cause disputes after a project is completed is ownership of the software and source code.

A client may assume that by paying the project fee and receiving the software, the source code is automatically theirs as well. In practice, this should be clearly defined from the beginning.

Before starting the project, it is better to agree on matters such as:

• Who owns the software?
• Will the source code also be provided to the client?
• What rights does the client have to use or develop the software?
• Can the software be transferred to another person or organization?
• If the source code is delivered, who will be responsible for its development and maintenance?

In one project where I encountered this issue, the client requested the source code and discovered that the matter had been clearly addressed in the contract, and that source-code delivery was not part of the original project commitments.

You can read the details of this experience in The Experience: "When the Client Requested the Source Code After Project Delivery" .

This experience showed that simply having a contract is not enough; both parties should carefully review its terms before signing and clearly understand the rights and commitments they are accepting.

3.6. Delivery Conditions and Post-Delivery Commitments Must Be Clear

It should be clear exactly what is meant by "project delivery."

Does installing the software mean the project is complete? Is user training part of the commitments? Should the client test and approve the features? How will issues be handled after delivery?

The support arrangements and responsibilities of both parties after delivery should also be defined from the beginning.

Therefore, delivery stages, approval procedures and post-delivery commitments should be defined from the start.

3.7. Ultimately, What Should Be Defined Before the Project Starts?

In summary, before starting a project, it is better to reach agreement on:

• The customer's actual problem and needs
• The project scope and features
• The main processes and algorithms
• The timeline and delivery stages
• The cost and payment terms
• The responsibilities of the client and developer
• Software ownership and the status of the source code
• Delivery and support conditions
• How changes and new features will be managed

These points are not intended to define every detail of a software project from day one. Rather, they help us start the project with sufficient understanding and agreement.

In other words, before coding begins, we should reach agreement about the project itself, the responsibilities and the rights of both parties, not merely about the idea behind it.

4. Designing and Approving the Algorithm Before Coding

Even after the project's actual requirements have been defined, we should not immediately move into programming.

The next stage is to turn those requirements into a clear process and algorithm. At this stage, it should be precisely defined what steps the software will follow and what logic it will use.

For example, if a client says:

"I want a check management software."

This description is not enough to start development.

We need to determine how checks will be registered, how returned checks will be handled, how transfers will be recorded, how due dates will be tracked, and how records and reports will be made available to users.

Until these questions have been answered, starting development is premature.

Code is essentially the result of decisions that have already been made.

If the process is not designed correctly, even software that is technically written without errors may fail to meet the client's actual needs.

For this reason, I prefer to define the business process first and, after reviewing and approving it, move on to design and coding.

In larger and more complex projects, tools such as Use Cases, Activity Diagrams and Flowcharts can also be used to examine and document processes. The purpose here is not to teach these diagrams; the main point is that the software's logic and process should be defined before coding begins and reviewed and approved by the responsible people within the organization.

A Real Experience: When the Software Was Correct but the User Did Not Accept It

In one project, after about a year of use, the client said that the software was not what they had expected.

After investigation, it became clear that the software's algorithm and workflow had been approved by the company's management and technical specialist before implementation, and the software had been developed exactly according to that approved process.

It later became clear that one of the company's employees had been accustomed to traditional, paper-based methods for years and was resistant to changing the way they worked and using the new software.

This experience showed me that the success of a project does not depend only on building the right software; users must also accept the change in their way of working and be prepared to use the new system.

You can read more about this experience in The Experience: "When the Client Said, This Isn't What We Wanted" .

Why Is Algorithm Approval Important?

A developer specializes in designing and implementing software, but confirming that the designed process matches the organization's way of working and actual needs is the client's responsibility.

The developer translates the agreed process into software. Therefore, before coding begins, the algorithm and core logic of the system should be reviewed and approved by the responsible people.

Changing the Algorithm Means Changing the Project

If the software does not behave according to the approved algorithm, that is a defect and should be corrected.

However, if the process itself changes later, we are no longer dealing with a simple correction. Changing the algorithm may affect the database, forms, calculations, reports and different parts of the system, and therefore change the project's time and cost.

Documentation: The Project's Memory

Requirements, algorithms, changes and important approvals should preferably be documented.

Software projects may take months and involve different people. Human memory is not always a reliable reference for past decisions, but documentation can make it clear:

What was requested, what was agreed upon, and what was ultimately implemented.

For this reason, one principle I follow in software projects is:

Before code is written, we should agree on the logic and process that the code is going to implement.

5. Designing Software for Future Changes and Development

One common mistake in software projects is designing the system only around today's needs, without considering possible changes in the future.

Of course, designing for the future does not mean implementing every possible feature years in advance. It means that the software structure should remain reasonably capable of being extended and changed.

Software may work perfectly at the time of delivery, but a few months later, after a business process changes, the number of users increases or a new feature is required, it may become clear that the structure was not suitable for further development. In such situations, a simple change can lead to modifications across multiple parts of the system and considerable rework.

One of my experiences in this area involved designing a system for managing a sales network and calculating sales commissions for an insurance company. In this project, in addition to registering sales agents and their network structure, the software was responsible for calculating commissions on direct sales and sales generated by sub-agents across several levels.

From the beginning, it was clear that the commission model might change after the network became operational. Therefore, before development began, I held several meetings with the company's managers to examine not only current requirements but also possible scenarios for future changes.

As a result, the software was designed so that different versions of the commission plan could be managed and historical calculations for previous periods would not be lost when the rules changed. The expected growth in the number of sales agents and the volume of calculations was also considered in the system design.

Over approximately one year, the commission plan changed several times, and the software was extended accordingly. If the system had been designed only around the rules that existed on the first day, each change could have required significant time and cost.

This experience taught me that analyzing software is not simply about asking:

"What features do we need today?"

We should also reasonably ask:

"If our needs change in the future, how capable will this software be of changing with them?"

Of course, it is impossible to predict every future change, and trying to build software that is prepared for every possible situation can itself create unnecessary complexity and cost. The goal is not overengineering; the goal is to ensure that today's technical decisions do not unnecessarily limit tomorrow's reasonable changes.

You can read the details of this experience in The Experience: "When Today's Requirements Were Not Enough for a Year" .

In projects where the volume of information also increases over time, data growth can affect software performance. This should also be considered during system design and development.

In this area, you can also read "When Software Slows Down as Data Grows" .

6. Deployment, Training and Support: The End of Coding Is Not the End of the Project

Software development does not end with delivering the code and installing the application. Proper deployment, user training and post-launch support are also part of the project's success.

Software does not run in a vacuum. The server, network, database, system configuration, user access levels and dependent services can all affect software performance.

Users, on the other hand, also need to understand the rules according to which the software was designed and how they should use it. Many restrictions and requirements built into software are not intended to make users' work more difficult; they are there to prevent future errors.

For example, the system may require a national identification number to be entered. If a user asks to remove this requirement for the sake of speed, the process may initially become easier. However, the likelihood of registering the same customer multiple times and creating inconsistencies in data and reports may increase later.

Therefore, software simplicity does not mean that training is unnecessary.

When the User Says, "The Software Has a Bug"

One common mistake when a problem occurs is to immediately attribute it to the software code without investigation.

The cause may instead be incorrect data entry, improper use of the system, server configuration, network problems, access permissions or communication with another service.

In such situations, not every problem should be solved by changing the code. The actual cause should first be identified, and then the appropriate solution should be selected.

One of my experiences in this area involved a project where the software had to communicate with another server through an API. For a period of time, the connection did not work, and both sides believed the problem was caused by the other side. A step-by-step investigation showed that the problem was actually caused by the server-side configuration.

You can read the details of this experience in "When the Client Gets Caught Between the Developer and the Server Administrator" .

This experience taught me that when dealing with technical problems, finding someone to blame is not important; finding the actual cause is.

I also had another experience where a client believed the software was making incorrect financial calculations. After investigation, it became clear that incorrect information had already been entered manually into the system. The software was actually performing the calculations correctly and had even exposed errors that existed in the previous process.

You can read the details of this experience in "When the Problem Isn't the Software, but Everyone Thinks It's a Bug" .

Sometimes software does not create a problem; it exposes a problem that already existed.

Support Is Not Just Bug Fixing

Proper support means that every reported problem is first investigated to determine where it originated.

For example:

• Was the information entered correctly?
• Has the user received the necessary training?
• Are access permissions correct?
• Are the server and network operating properly?
• Is communication with other services working?
• Is the problem related to configuration or infrastructure?
• And finally, does the software actually need to be changed?

The answer may be a code change, but sometimes the right solution is user training, configuration changes or modifying the business process.

Therefore, a software project does not end when programming ends. Proper deployment, user training and appropriate support help ensure that the software continues to serve the purpose for which it was designed in the real-world environment.

7. Post-Delivery Changes and Development: Why Is Every Small Change Not Simple?

After software is installed and used in the real world, new requests will usually arise. This is natural because sometimes it is only after working with the system that users discover what changes or additional features they actually need.

The problem begins when we assume that adding every new feature simply means writing a few lines of code.

Software is a collection of interconnected components, and changing one part may affect other areas such as the database, calculations, reports or related processes.

Therefore, before implementing any change, it is better to determine:

• What exact problem does this change solve?
• Which parts of the system will it affect?
• Is it compatible with the current software structure?
• Will previous data or calculations be affected?
• Will related components need to be tested again after the change?

Not Every New Request Is a Bug Fix

One issue that should preferably be agreed upon from the beginning is the difference between bug fixing and new development.

If the software was delivered according to the approved requirements and the client later decides to add a new feature or process, this is normally a development request rather than a bug fix.

For example, if the software was agreed to support issuing one type of invoice and the client requests another type several months later, that is a new requirement.

Being clear about this helps prevent later disputes over time and cost.

An Experience with Previous Client Software

Some clients who have approached me to build new software have described their previous system with a sentence similar to this:

"Whenever we change something, something else breaks."

In some of these projects, numerous changes had been made without considering the relationships between different parts of the system. As a result, every new change could create additional problems and make the software more difficult to maintain.

This experience shows that software development is not simply about adding new features; the impact of each change on the entire system must also be considered.

You can read the details of one of these experiences in "When a Small Change Alters the Entire Software Structure" .

More Features Do Not Necessarily Mean Better Software

It is sometimes assumed that the more features are added to software, the better the software becomes.

However, adding numerous features without considering actual needs can make software more complex and harder to maintain.

Even a seemingly small change, such as modifying a formula, may affect several other reports or calculations. Therefore, before implementing a change, the developer should examine its dependencies and test the related components afterward.

Changes Should Not Be Prevented; They Should Be Controlled

Business needs do not remain constant. Processes change, users develop new requirements, and business conditions may also change.

Therefore, the goal is not to prevent change; changes should be made consciously and in a controlled manner.

For every new request, it is better to first clarify the need, assess its impact on the software, estimate the required time and cost, and then decide whether to implement it.

If the change is approved, it should preferably be documented and, after development, the related components should be tested.

Ultimately, one point should not be forgotten:

Every small change is not necessarily a simple change.

Before implementing any change, ask:

"What problem does this change solve, and which parts of the system will it affect?"

Proper development means changing the software without sacrificing parts that were already working correctly.

8. Security, Backup and Preparedness for Unexpected Events

Professional software is not designed only for normal conditions.

A server may fail, information may be damaged, the network may become unavailable, or a security attack may affect system performance.

Experience has taught me that the true quality of a system and the quality of its support are sometimes revealed when an unexpected event occurs.

Backup Should Not Be Left Until the Day of the Incident

In one project, a customer's database developed a serious problem and access to the information became extremely difficult. Investigation showed that backups had also not been taken for some time.

After considerable technical investigation and effort, the problem was resolved and the recoverable data was restored to the system.

This experience taught an important lesson:

Backups should be created while the data is healthy, not when access to the original data has already been lost.

You can read the details of this experience in "When Having a Backup Is Not Enough" .

A backup is not simply a copy of a file or database. It should be clear how frequently backups are created, where they are stored, how long they are retained, and how they will be restored if a problem occurs.

Most importantly, the recovery process itself should be tested. Having a backup that cannot actually be used during an incident does not solve the problem.

Security Is Not Limited to Coding

In another project, the organization faced malicious attacks that caused a severe decrease in network performance and also affected the software's operation.

From the user's perspective, the software had become slow, but the source of the problem was in the network infrastructure.

After investigation and the necessary measures, the problem was resolved.

This experience showed that system security is not limited to secure coding.

The server, network, operating system, access configuration and the way information is stored and maintained are also part of system security.

More Access Is Not Always Better

Users sometimes request additional permissions because they believe that fewer restrictions will allow them to work faster.

However, every additional permission also creates more responsibility and greater risk.

User access levels should be determined based on their actual responsibilities, not simply on convenience.

What Happens If the System Goes Down Tomorrow?

This simple question should be asked from the design and deployment stages:

• What will we do if the server becomes unavailable?
• What happens if the database is damaged?
• If information is accidentally deleted, can it be recovered?
• If the network fails, which parts of the system will be affected?
• How recent is the latest usable version of the data?

Security is not only about preventing incidents; being prepared to recover after an incident is also part of security.

For this reason, security, backup and recovery should be considered from the beginning of the project, rather than after the project is complete.

Conclusion: Where Does Successful Software Begin?

When we talk about the success of a software project, we usually focus on programming quality, features and the technologies used. However, years of experience in software design and development have taught me that:

The success of a project is determined long before the first line of code is written.

Successful software is the result of a series of sound decisions, from understanding the actual business problem and needs and analyzing processes, to design, development, deployment and support. Even after delivery, user training, change management, security and backup can affect its success.

Software may work correctly from a technical perspective, but if it does not address the customer's actual needs or users cannot use it properly, it cannot be considered a successful project. Success is not measured only by the number of features or the amount of code written; what matters is whether the software can solve the real business problem correctly, reliably and in a usable way.

Throughout my years of work, I have seen that many project problems have not originated in coding, but in incorrectly defined requirements, poorly designed processes, changes made without proper assessment, inadequate training or infrastructure problems. That is why project success does not depend solely on technical knowledge. The client has business knowledge and experience, while the developer has the technical knowledge and experience required to turn those needs into software.

Transparency, documentation and mutual commitment are the foundation of trust between the client and the project developer.

If I were to summarize all the experiences discussed in this article in one sentence:

Successful software is not built through good coding alone; the problem must first be properly understood, requirements and processes must be analyzed and designed correctly, and the software must then be developed in a way that makes it usable, reliable and ready for future changes and development.

Therefore, when starting a software project, we should not only ask:

"What software do you want?"

We should ask:

"What problem are you facing, how do you work, and exactly what change is this software expected to make to your business?"

In my view, that question is the starting point of a successful software project.