When a Simple Form Took 20 Days

Sometimes, what a client sees is just a simple form. But behind that form, there may be many processes and layers of logic that determine the real time and complexity of the project.

One of my experiences in this area involved a project I developed for a company that manufactured payment terminals. The client asked me to design a form that would allow customers to enter their personal information and the details of the device they had purchased online and complete the device activation process.

After an initial review, I estimated that the project would take 20 working days. The company's technical specialist asked in surprise:

“Isn't 20 days too long for designing a simple form?”

In one sense, he was right. If the project had really been only about designing a simple form, 20 days would have been a long time. But what appeared to be a simple form on the surface actually involved a set of technical, security, and control processes behind the scenes.

The customer had to enter information such as full name, mobile number, national ID number, device serial number, and device identification code. The system had to validate the information, verify the relationship between the device serial number and identification code, and then match the customer's information against the information registered for that specific device.

If all these steps were completed successfully, a one-time password would be sent to the registered mobile number. The user had to enter this code, and after verification, the device activation code would be sent to them.

But designing this process was not limited to defining the main steps. Decisions also had to be made for the different situations that could occur at each stage.

If the device serial number was entered incorrectly, how many times should the user be allowed to try again? What should happen if the identification code did not match the device serial number? What should the system do if the SMS was not delivered or the user entered the one-time password incorrectly several times? If a serial number or account was blocked because of repeated failed attempts, how could it be reviewed and tracked?

Therefore, even for errors that might occur in what appeared to be a simple form, a specific scenario had to be designed—from the number of permitted retries to blocking, logging, and managing different system states.

There was also the issue of data security.

Confidential information related to the devices had to be stored securely, and access to that information had to be controlled. Therefore, information security and the way the data was stored and managed were also part of the project design.

As the project was examined further, it became clear that the activation form alone was not enough to meet the organization's needs. Two additional panels were required to manage the information and processes that had been registered.

In the management panel, the relevant staff member could manage registered information, enter new codes, check code statuses, and review incorrect or blocked cases.

Another panel was designed for customers. Each customer could log into their account, view the status of their purchased and activated devices, and access the features related to their account.

As a result, what initially looked like a simple form actually involved data entry, validation, error handling, authentication, SMS verification, status management, data security, data storage, and separate management and customer panels .

So the technical specialist's original question was completely reasonable:

“Isn't 20 days too long for designing a simple form?”

My answer was straightforward:

“If it were really just a form, yes. But this project was not just a form.”

The Lesson This Experience Taught Me

This experience made one important point clear to me once again:

A software interface may look simple without the underlying project being simple.

Before estimating the time and cost of a project, we need to carefully examine the processes behind it, its technical requirements, security, data, error scenarios, and required features.

What the customer sees may be just one page, while behind that page there may be dozens of software processes and layers of logic.

One common mistake in software project estimation is judging the complexity of a project based on what the user sees on the surface.

For this reason, before entering the development stage, the project's requirements, processes, and different scenarios should be reviewed and, as much as possible, clarified and finalized with the client.

Ultimately, what I took away from this experience was that the real time required for a project should not be estimated from its appearance; we must first understand what lies behind that appearance.