How to Handle the 3 Types of Clients in Software Development

Good relationships with clients are the bread and butter of software development companies. You may have the most skilled programmers and designers on board, but that will mean nothing if you’re unable to deliver a satisfactory customer experience. 

This article will explore the nuances of working with different clients, as well as what software development companies can do to ensure their client relationships will last.

Why should you care?

First things first, why would a software development business want to retain old clients? 

Simply put, so that it won’t have to spend money acquiring new ones. According to Invesp, attracting a new customer costs five times as much as keeping an existing one. Of course, you should still invest in attracting new clients. But having a solid base of loyal customers is important for securing a reliable stream of income.

In other words, a software development company needs to please its client base in order to survive long-term. These clients, however, come in different types, with each having its own unique set of nuances. Let’s take a closer look at them.

The kinds of clients software development companies have to work with can be split into three major groups depending on their size.

We’ll start with the smallest one.

Financed Startups

You may think that having a freshly financed startup for a client can be a simple (if a slightly unambitious) way to earn some quick revenue. But startup clients frequently turn out a lot more risky and resource-intensive than one might expect. There are two major reasons for that.

Tight budget

Financed startups, unsurprisingly, have very tight budget restrictions. Everything hinges on the client’s agility – how fast they can acquire the money needed for development and in which amounts. Needless to say, if the startup’s agility is lacking, there’s a high probability of the project running out of budget.

In case the startup can secure the necessary resources in time, the development process may still be a challenge. The abovementioned budgetary limitations mean that there is very little wiggle room in terms of, say, experimenting with the project’s usability. This can severely restrict the potential improvements to the product.

Lack of experience 

Startups are often inexperienced as clients. They have to be familiarized with the process of requirement analysis, compiling the necessary documentation, working with BAs and PMs, and so on. Even if the startup does have a number of experienced specialists on board, the company as a whole will still require a degree of client training before the collaborative process can truly begin.

Client training, or partner training, is the process of acquainting your business partner with the ins and outs of software development (in our case, at least). This involves detailed explanations of the steps taken over the course of app development, which specialists are involved in it, how exactly resources are distributed, why certain documentation is necessary, and so on. 

It primarily means sharing general and specific knowledge. General knowledge refers to technical and domain expertise, teaching certain product principles and methodologies. Specific knowledge includes information on certain constraints and the specifics of working with a particular company.

It can also involve actually increasing the overall proficiency level of your client’s team – in other words, refresher courses. The burden of paying for the latter usually lies on the client alone, but there have been cases of developers investing in them to raise the collaboration’s chances of success. After all, this will not only help your client better understand what they are getting into, but will also prevent possible misunderstandings and misdirection in the long run. 

The main benefits of the training process for the client can be summed up as:

1. eliminating blind spots (in terms of features, product strategy, or things that may bring complications in the future);
2. receiving valuable domain insights from the development company’s experience of building similar products (UX/UI knowledge, for example);
3. improving communication – the training process involves planning and setting up communication channels, which requires special attention depending on the specifics of the client’s company (for example, a fully offshore team will communicate differently than a team that’s split between the client’s and the development company’s offices).

Dealing with investors

The subject of investors is often a tricky one for startups. If you want your project to succeed, the startup you’re working with must retain a good relationship with its investors all the way through. And you, as a developer, play a significant part in how that plays out.

You will very likely need to develop product decks for the startup’s upcoming investment rounds. Moreover, you’ll need to consider how investors view you, the development company. Some investors don’t want the startup to integrate with too many third parties, while others believe you don’t need to reinvent the wheel, seeing as collaborating with a development company is only natural.

Whether it’s one or the other, you will need to adjust your strategy depending on who funds your client. Because if your collaborator loses money, so do you.

Medium-Sized Companies

There are no official specifications of what is considered a medium-sized company. However, the general consensus is that its annual revenue is between 5 million to 100 million dollars, and the team size is between 50 and 250 employees. Medium-sized companies are more organized than startups, but still present some unique challenges.

Unpredictability

For starters, medium-sized companies are still somewhat new to working with software developers. So just like startups, they will need some training and guidance during the discovery phase. 

As a partial result of that, expect some project management problems on the client side. It’s often difficult to evaluate the projects of medium-sized companies, so setting realistic expectations from the start is very much necessary. 

Rigid payment models

Another nuance software developers should consider when working with medium-sized firms is that they tend to choose one-time payment models. The thing is, since that payment is usually made after the product is delivered, the developer has to ensure that it has all the necessary resources to complete the project in one go.

Many different factors go into choosing the project’s engagement model. The most prominent ones, however, are the client’s budget limitations and whether they have a tech lead or a CTO on the team. Since startups and medium-sized companies are likely to be constricted in those regards, both generally choose very rigid engagement models. Though even they are far more flexible than our next kind of client.

Enterprise

The biggest client a development company can hope for – and potentially the most challenging one. Without further ado, let’s dive right into it.

Not always profitable

Enterprises are the most prestigious clients a software development vendor can have. Because of that, attracting clients of this caliber requires serious investments in marketing and a lot of resources along the entire RFX process. But the struggle may be worth it: enterprises offer the most ambitious and profitable projects, and serve as an amazing addition to any company’s portfolio.

At least, that’s the typical outlook. The fact of the matter is, getting an enterprise-grade client does not always equal getting a big project (or a profitable project, for that matter). A massive corporation may hire you for a tiny 2-months project with a team of 2 or 3 people. You probably won’t earn hundreds of thousands of dollars in those two months, but what you will earn is the right to add a huge industry name to your portfolio – and that’s worth a lot.  

It’s worth so much, in fact, that some companies are willing to operate at a loss simply because having a client of that size is likely to benefit them in the long run. Not that we advise you to do that.  

RFX and Tenders

A complex RFX process is necessary when working with enterprises. For example, RFI (Request For Information) will help the enterprise decide whether or not your company is a suitable partner for them: they will request certain information about your firm, and you’ll supply them with the appropriate documentation.

Another thing that will most definitely take place is an RFP – Request For Proposal. The client will ask your company about the exact specifics and costs of every part of the development process. A shortened version of that is an RFQ – Request For Quotation.

Finally, enterprises are likely to ask for an RFB – Request For Bid. This is done when they select a software development vendor through tender procedures. In this case, the developers need to provide the information on the exact price of the work the client wants to be done.

Actually, let’s talk a bit more about tenders. First of all, tender platforms are often paid, so it’s wise to anticipate these expenses. Secondly, tenders are often handled by a special team; searching for and preparing for tenders is a complex and expensive process, so if you wish to participate in one without a prior invitation, get ready to shell out a sum. 

Your submission will likely have to contain certain certification: both standardised stuff like the ISO and domain-specific ones like the HIPAA for Healthcare. Lacking these may seriously discourage your client from choosing your development company. The challenge with getting those is that they’re not always financially viable (for example, the ISO is a whole audit) – there’s no guarantee you will get your money’s worth out of them.

Tenders are also very strict when it comes to deadlines: send your submission a minute late and all the work you’ve put into collecting the necessary information and preparing a solution will have been for nothing. 

There’s also the issue of some enterprises holding ulterior motives when doing a tender. Sometimes a tender is organized not to actually hire a new vendor, but to threaten the current one into giving the client a cheaper deal. If you don’t pass, you’ll have no way of knowing why – you’ll have no feedback to bounce off of, no idea what you could improve. 

Though, to be fair, that’s the case with all kinds of tenders, not just ones that are held as a scare tactic.

Extensive documentation and compliances

Being a large corporation, the client dictates the terms of the deal and has high demands for the companies it chooses to collaborate with. Not every developer is capable of meeting the high standard imposed by such firms, and smaller vendors aren’t always prepared for that resource-wise.

Firstly, enterprise clients are extremely process-based, and as such, come with a long list of compliances. In order to work with a client of that size, developers need a strong balance sheet, a development team that’s very well prepared for interviews, and a guarantee that some of its key players will be secured for the entire duration of the project.

The latter can be complicated, as enterprise projects are often long-term, which means that the period of engagement tends to be much longer than that of any other project. On the other hand, lengthy collaborations allow development companies to scale organically, let them grow in terms of how they handle different processes and approaches, as well as help them foster a good business vision.

One more factor enterprises pay special attention to is the security policy. As a rule, corporations have their own set of requirements when it comes to the software and the tools used in development. It is indeed a safe approach. However, since third party developers need to get access to these tools directly from the client, it can result in a slow start and pushed-back deadlines. 

Because of all this, enterprises tend to be hesitant to adapt newer technologies, methodologies, and approaches. So if you’re dead set on convincing a client like that to switch to a more up-to-date solution, get ready to go against their many internal planning and security policies. Good luck with that (you’ll really need it). 

On a side note, large companies are likely to have their own quality assurance engineers and product teams. While not necessarily a disadvantage for the devs, it’s an important thing to keep in mind for process management purposes.

Branding and Reputation

Large companies are very brand-sensitive, meaning they are extremely strict about you following their brand book to a T. In terms of app design this means using specific fonts, colours, shading, illustrations, implementing (or avoiding) particular terminology, and many other specifics that need to be approved by the enterprise representatives.

Another crucial aspect is the development company’s reputation, or its digital footprint. Enterprises put great emphasis on public opinions, so working with a developer that has a less than ideal online image is a no-go. And here comes the catch: the younger the company, the cleaner its digital footprint; but the younger the company, the less enterprises want to collaborate with it. 

Companies that combine impeccable reputation with an extensive track record are hard to come by, which makes them a valuable partner for enterprises. So young startups may want to consider teaming up with a larger developer to up their chances of securing a client like that.

Might still require training

The client being an enterprise doesn’t mean that its product team will have any experience in software development. Enterprises consist of many departments, and the project manager assigned to your collaboration won’t always be an especially tech-savvy individual. 

This means that you might still need to spend a significant amount of time explaining all the processes and expenditures to your client. In addition, you should probably allocate some resources to onboarding. Here’s why. 

One commonality that enterprises share is the amount of horizontal and vertical staff movement. As a result, the team on the client side is very likely to change over the course of the project, which means that you will need to invest in helping the old product owners make handovers to the new staff members. So if you don’t want to be blindsided by the extra costs, you’d better prepare for this possibility. 

While we’re on the topic of personnel, let’s not forget about how frequently enterprise clients practice dedicated teams and outstaffing. This is especially commonplace in regions where hiring local candidates is challenging – for instance, Scandinavian companies tend to struggle with this. 

As a rule, enterprises have the internal team and the external team (or specially allocated external professionals) collaborate. If your company is willing to supply remote specialists for the project, you need to concern yourself with preventing the employees’ burnout. That’s where strong project and people management can be of great help.

Furthermore, it’s critical to maintain a warm relationship with the client. That doesn’t just mean following their every order: you must show initiative and actively demonstrate your expertise. How else will you prove you’re worth the money and shouldn’t be swapped for a more qualified team?

As far as the product itself is concerned, sometimes big brands have a software solution idea, but don’t know how it can be realised. That’s when developers must help them conjure a clear product vision, make design suggestions, build a prototype to let the client see the app in action, and so on. 

Often enterprises lack software development experience, so it’s important to not blindly follow their directions, but explain the why and hows of the process and help polish the product idea to perfection.

Lack of flexibility

One more thing to consider is the development approach enterprises tend to employ. Corporations usually prefer the Waterfall method as opposed to Agile: they don’t intend to continuously improve the product; instead you follow a clear predetermined plan with zero deviations. 

There have been some attempts to adapt the Agile methodology to enterprise-grade development. The SAFe approach is an example of that: it allows companies to retain the bureaucracy of the Waterfall model, but makes the development process a bit more flexible. If you wish to collaborate with enterprise clients, your team should be well acquainted with this methodology’s specifics.

This is the flipside of the long-term planning enterprises do. Their plans and predictions go years ahead, so even the smallest change is likely to cause a massive chain reaction. This means that the plans will have to be readjusted, which is often a lengthy process in itself. Add to that needing to get the approvals from the entire management board, and you end up with a very tedious situation.

Location matters

Enterprises are far more likely to partner with developers that:

1. work in a similar time zone;
2. have the same accounting and administrative procedures as the client.

This makes getting such clients and working with them extremely difficult for companies located in faraway countries, especially if the firm itself is relatively small. 

Additionally, if you ever try to seek legal action against an enterprise as a small development company, you might want to reconsider doing that: their legal team will always be better than yours, regardless of who is actually in the wrong.

That said, not all is lost for smaller development teams. There are multiple ways to ease the process of acquiring and working with clients of all sizes. Let’s look at a couple of them individually.

General Practices

It’s good to discuss some general principles software development startups should keep in mind when working with all kinds of clients.

Always Clarify

First, remember that software development should never be a guessing game. Always ask the client to clarify whenever you’re unsure about a requirement, ask for more detail, ask how exactly they want their ideas implemented. This will help avoid unpleasant surprises for both you and your customer. 

Some businesses believe that after they hire a software developer, they can just sit back and wait for their dream application to come. But building a custom solution is always a collaborative effort. If your client has that mindset, explain that without their continuous direction, the end product will be unlikely to meet the expectations.

Sort Out Your Priorities

When you begin working with a client, nailing down the exact requirements for their project is crucial. These can be divided into two categories: 

• Functional requirements. These refer to the features and functions of the final product that are visible to the user. 
• Nonfunctional requirements. These requirements are pretty much invisible to the user, but are integral for the product to perform its functions. For example, security, performance, storage, accessibility, among many others, fall into this category. 

Time and budget constraints often put restrictions on what requirements can realistically be implemented. Because of that, they’re commonly split into the following types:

• Must-have requirements are necessary for the product to perform its basic functions.
• Should-have requirements preferably expand the software’s functionality, but aren’t integral to its operation. 
• Could-have requirements are less important, but can serve as nice additions to the app’s feature list.
• A wish list includes potentially fun and/or innovative additions that are usually unrelated to the core objective of the product. 

Sorting the client’s requirements into these categories will help both parties better understand what the final result should look like. It will also allow you to build a more effective roadmap and help allocate the company’s resources in a more productive manner.

Keep the Client Up to Date 

The bigger the project, the more important its communication channels are – not just within the team, but in client-developer relationships as well. A consistent flow of relevant information is extremely important to ensure that the development process doesn’t get off track.

Keep the messages specific and concise, don’t waste the client’s time with unnecessary chatter. Consider which method of communication will be the most effective: sometimes it’s much quicker to make a direct call than to write a massive email explaining everything in detail. Plus, live communication tends to bring better results. 

Acknowledge the receipt of messages and tasks and inform the client whenever you deal with them. If the completion of a certain task has to be postponed, try to give the client a heads-up as soon as possible – don’t leave them wondering what’s going on.

These points may seem small and insignificant, but they play an important role in raising the quality of your client relationships in the grand scheme of things. Plus, they simply keep the development process more organized.

Partnership

The main problems that small development companies face can be summed up as follows:

1. lack of resources;
2. lack of experience;
3. lack of credibility.

All of these can be mitigated by means of a partnership. According to Forbes, the most successful startups of 2020 were those that focused on partnerships and customer support. This McKinsey Digital survey also states that 75% of startups see partnerships with bigger companies as important.

Now what advantages does a partnership entail?

First of all, partnering with a bigger company means you won’t need a sales team anymore. The bigger partner will take on all customer-related duties: customer acquisition and customer care will all be carried out by a more experienced party. So, all client communications and project management will be the partner’s responsibility.

This includes collecting the necessary documentation that enterprise-grade clients are so meticulous about. Not every startup is equipped to deal with all the rules, paperwork, compliances, as well as the legal and banking infrastructures, all of which cannot be ignored on larger projects. The partner can take over these responsibilities as well, thus letting the development team focus on building up its tech expertise.

This flows right into the next point on how your developers will be able to cultivate their skills much more efficiently. Not just because the team will have more time available to do so, but also because the partner will provide them with more opportunities for that: courses, technologies, consultations, and so on.

Similarly, the partner will provide the company with the monetary resources it wouldn’t be able to get otherwise, thus preventing overheads. Big projects don’t always get all the funding right off the bat: sometimes you get paid off only after delivering a certain part of the project. This is not always feasible for smaller companies with limited budgets.

Finally, the partner company can provide bonuses for developers in the form of various team building activities, corporate outings, merch, and other benefits. 

Affiliation

An affiliation usually comes as a result of a quality partnership. A larger firm can buy a development company’s shares, so even tiny teams get the chance to capitalize on their work. This doesn’t mean that the company is completely absorbed into the larger corporation – it can still remain as its own separate entity within a group of other companies.

One of the biggest benefits affiliations give is the opportunity to incorporate into the larger IT ecosystem. Networking with high-profile clients and corporations will be a lot easier for businesses with a well-established brand behind their back. It also opens the doors to many worldwide tech conferences, expos, and events.

Aside from that, the company will be able to focus on perfecting a specific technological stack and honing the team’s internal processes. This combination of boosted professional growth and access to more sophisticated clients means a lot more interesting and challenging projects for the development team.

Of course, it comes with all the previously mentioned partnership benefits.

Each type of client presents its own set of challenges; and the bigger the client company is, the higher the stakes will be. There are several ways a development vendor can mitigate the risks involved while providing high quality customer service.

Asking for clarifications whenever possible, carefully analyzing and sorting requirements by priority level, and keeping everyone up to date on all the happenings in the project are all invaluable practices in ensuring the end product won’t leave your client disappointed.

A great way to streamline the process of working with clients is securing a partnership or an affiliation with a bigger company, which is a growing trend worldwide. They allow startups to monetize a part of their success by selling shares, boost developers’ industry connections, and give them a chance to work on exciting and meaningful projects while preventing overheads.
If you are interested in forming a partnership with an experienced tech company that will guide your startup to success or want to learn more about the subject at hand, feel free to contact us.