Detailed Analysis of Edtech App Development When As A Client You Have Bountiful Thoughts

Imagination has no limit, the technology has,

Business has,

and

Development has.

Let’s face it – There are different types of industries with different types of niches with different types of processes, and a mobile application or a website is to be made addressing a specific problem out of these. Have a look at Our Work.

It is always the development firm which has to walk on a tightrope between meeting the required criteria of the clients and the business, technological, and developmental limitations.

Read one such client-vendor case study here.

Clients are important for any development firm, but it is more important to make the client understand if there are any developmental constraints rather than nodding at every note of the clients and at the end deceiving them by delivering the app back to them without their desired functionality. Now, what happens is it acts as a spoiler to the client-vendor relationship.

Unrealistic Requirements:

—————
“Hey, I have come up with something unique. I want my edtech app to support unlimited media uploads at the same time.”

“Buddy, I feel no need to add multiple media uploads because nobody is going to have more than 20 or let’s exceed it to 30 supporting media for a single answer.”

“But hey, that would make my app unique and this feature does not exist, so there are more chances that my app will get noticed.”

“Frankly, there is no use of such a functionality.”

(Want to know what it led to? Here make your way through this interesting case study)

What Happens When Client Wants Uniqueness In Edtech Mobile App Development

And it just goes on and on.

Innovation in requirements and functionalities is welcomed, but then the thought should add a value to the operation. Every vendor would love to extend their capabilities when it comes to trying out something neoteric in their scope of work.

Many times there is no need of a certain functionality at the launch time, but then the need can be created inorganically. For example Tinder is a dating application. The basic operation of the app is to match two people who swipe right on each other’s profile.

Some of the clients come up with such application and website development requirements which are innately unforeseen in nature. Such ideas are conceived hypothetically and bringing it into the real-time would take more time than what it takes usually while developing a clone application. Thus, when such requirements are conveyed, it is imperative to include a buffer time to analyze about the idea and see its feasibility in the real-time.

Here, Tinder included who viewed your profile and who liked your profile. These features would have not been needed if at all they were to be launched in the initial version of the Tinder. So, when there is some unique functionality, it can be planned and can be added in the subsequent version of the app.

Upgradation to Be Done:

—————

This is one of the most common development scenarios. When the application or the website is half created by another development firm, major time goes into understanding the business concept and analyzing the codes written. Then the budget and the time for the development is fixed.

The clients have a fixed time frame in their minds about the launch of their app/web so they might seem to be in good hurry to get the application done. Most of the projects are in the fixed-time and fixed-price engagement model based. When the time of the development is less and the upgradation is to be done, it takes number of resources to be exhausted for more hours on a daily basis. They are to be paid extra without charging the client a lot. Thus, the vendor has to compromise on the monetary aspect.

Another scenario to this issue is when the application or the website to be upgraded is poorly done in the first place. Now, the entire working of the application has to start from the scratch here. The time given for the development is half of the usual time and this has its effect on the budget frame.

So, more of the resources are utilized for a longer duration of time to meet the comprehensive end goal within a shorter duration of time.

Read about one such client-vendor case here.

Native Vs. Hybrid:

—————

It is pretty much obvious that native development consumes a lot of time as compared to that of the hybrid application. There are times when abandoned hybrid applications meet the native application development firm and then is when the problem actually starts to strike. Natively developed application is but an intrinsic solution as there are more options to extend the functionality for the application development.

When the application is built using hybrid technology by the previous development firm and then that website or application is to be converted into native application, that too in fixed price and fixed cost engagement model, then surely it overloads the application development vendor.

Extending Requirement and Engagement Models:

—————
Before commencing any project, it is ensured that the scope of the project is beforehand clarified. On the basis of the scope of the project, engagement models are recommended to the clients:

Fixed Time and Cost Engagement Model: Herein the project requirements are made clear and the requirements are well-defined from the initialization of the project.

Dedicated Team Engagement Model: Herein a dedicated development team is allocated for the development of the project. In this course of time, the team cannot be assigned another project.

Time and Resource-based Engagement Model: Herein the client pays for the utilization of the resources for the particular amount of time.

Now, every engagement models have their own loopholes when we talk in terms of extended requirements.

When the project is taken on fixed time and cost basis, the entire scope of work is to be pre-determined. But what happens is the clients want to add more functionality in the middle of the development process. Now, they take the fixed time and fixed cost model so seriously that they forget that the project is a fixed priced model.

With a dedicated engagement model, the project can go on for years and yet not get concluded. All these times that particular team works only for that project and the entire team gets bugged. The company cannot take any other project as they have an entire team blocked for the previous project.

Cherry Picking Clients:

—————
“You see my project idea is something unique, before assigning you my project, I want you to provide me with some examples.”

“OK. On the basis of your requirement, we will analyze the entire project and propose you with the wireframes.”

“Yes. That would be great.”

After some days…………….
“Hey, I like what you did, but I also want to evaluate how would a different functionality for the same operation look like. Can you design these wireframes as well? Then we can decide out of these two.”

“OK. Mail us your ‘new’ requirements.”

After some days…………….
“Hey, I like what you sent but…..”

And this goes on to the choosy clients. Not obviously blaming the clients, but when flawless wireframes are presented, it is expected that the clients stick to their requirements and not change it every now and then.

Initially the requirement gathering is done by the business development executives, then the same is communicated to the business analyst, who evaluates the entire concept and forms a complete business model.

Then, the feasibility is validated and ultimately the wire-framing is done. All these efforts and resources are used for the prototyping at the company’s cost. When there are critical issues or the client is dissatisfied with the prototypes, then re-work can be done, but just to have more choices, the clients should not ask prototypes for every new requirement.

Analysis Process is a Never-ending Process:

—————

The mobile/ website development process is a rough road. You do not know what could come up next and when could a standstill-like situation could arise.

That is why it is extremely significant that both the client and the vendor take ample of time in the analysis stage and creates back up for the problems that could possibly arise in the middle of the development phase.

In the development phase, when the problem arises, the vendor seeks advice from the clients and it is upon the clients to respond in the least time possible. This mostly happens when the industry is new to the clients and they have to take more time to research and come to a conclusion.

It is therefore expected from the clients to be technically sound so that whenever the project passes through the mid-development crisis, quick modifications can be made.

Apart from this, when the changes to be made are very significant, the entire project is to be re-analyzed, process flow has to be formed, and then again the development has to be started.

This consequently consumes a lot of time and the resources of the vendors stay idle for that time-duration.

The Requirements are Too Ambiguous:

—————

Two business models are combined in one, but which has to be primary that is not mentioned.

“I want a messenger app. I like whatsapp. I like snapchat. I want a combination of both.”

This cannot work.

Why?

Because while whatsapp is purely a chatting application, Snapchat is a platform to send and receive snaps and instant replies. There is no message history saved in Snapchat while any messenger/ chatting application has to have the messages saved.

When the client is not clear about what he actually wants to make out of both the existing platforms, it creates ambiguity. In most cases, when two applications are merged, it cannot be known which one is supposed to be primary in the application.

If the client wants a messenger, then whatsapp has to be the primary application and the Snapchat features such as screenshot, image disappear can be included. However, if the clients wants an image sharing app, then Snapchat has to be the primary application and the whatsapp feature such as chat storage, audio calling, video calling, etc, can be added.

This is how it completely depends on what function does the client want as most of the clients take decisions after they are charmed by the revenue model of the big-shot businesses.

Feature Stuffing:

—————
The audience likes feature-rich applications.

For example give them an app like whatsapp and they will commend media sharing feature, variety of emoticons, voice note, audio call, video call, and story adding/viewing feature.

Planning for advanced features and its launch time way ahead, is a smart move for the businesses, but equally smart is to have a proper reasoning for the inclusion of the features.

Give them an app like Instagram, add a chat module into it and here, the voice note feature becomes vague.

Unnecessary feature stuffing is as bad as having an inexperienced UI/UX designer; ultimately both don’t work! Many times there are hot client-vendor arguments. Even though the development firm gets to earn extra when a client proposes for extra features other than the necessities, but then it disturbs the user’s navigation path while diverting from the main functionality.

The clients should aim at attracting the users with the mobile application’s basic functionality. This is how they can plan the next step of their revenue if the basic version of the application gets accepted by the users. Thus, adding any feature that is irrelevant can affect on the user’s business.

Even if the users don’t mind using the feature, it is not aligned in your business’ basic functionality.

Cloning a Business Completely:

—————
“Tell us your requirement.”

“I want to get an app like Uber build.”

“Ok, tell us what you need.”

“I want an app exactly like Uber.”

“Err, ok. Do you have something in mind how your ride-sharing will be different from Uber?”

“Yes, I want an Uber clone application.”

These are the most common instances that happen. Not many clients know that when it is said, ‘Clone Business’, it means that you clone the business model, the functionality, but then you have to solve an issue that the existing business does not solve.

For example, when Uber was launched, it paraded with the flag of professional on-demand ride experience. Taking a cue from Uber’s business model, Lyft cloned the model, but then it focused on making the ride-sharing experience more friendlier than Uber and so the business.

Similarly, when Ola started in India, it cloned the entire business model along with the functionality and features of Uber, but then it collaborated with the affordable three-sitter ride services and made it real big in India.

Your takeaway-home message is you should not clone a business completely. If there is already a successful business running, why would people choose you over it if you are any indifferent?

The Verdict

—————
Effective Communication is the Key.

Effective communication is indeed an important factor in deciding the success of a project. Along with planning for the analysis, strategies, and development of the project, communication planning can prove to be an effective tool in order to overcome the challenges and contribute to a more successful project.

Learn more about mid-development crisis here.