The Client's Role at a Bespoke Software Development Company

Bespoke Software Development: A Continuum 

An obvious statement, but one that needs to be emphasized: buying custom software is not like buying groceries. It is really tricky to find a provider that will take care of creating and maintaining your company's ideal software by developing it on a fixed schedule and for a fixed price. Buying groceries is much easier, you just have to choose the best bananas because, of course, they don't have the same complexity as software, while presenting a limited range of varieties, unlike a custom software application, which has the main characteristic of being built according to each specificity and need of a business.

Attempts to treat software projects in fixed terms can fail. Their efficiency and success are based on uninterrupted flow, since time invariably passes following technological innovation, which makes improvements and changes necessary. So, it seems equally obvious for a bespoke software development company to be aware that the service it offers is – as I personally like to call it – a continuum. Only with this mentality, it is possible to guarantee the quality and success of a product that is always up-to-date and efficient for what it is intended for. 

How does this continuum play out in practice? 

Of course, there are many requirements for rules and mutual consensus, as well as a strong sense of commitment to clients. And for these, the necessity to understand what their role is, especially regarding communication with bespoke software developers and other professionals engaged in the process. 

To continue my line of argumentation on this theme, I'd like to briefly approach the relationship between a bespoke software development company and the probable client's expectations related to it. First, let's put ourselves in your shoes as a client, taking into account the demand you may have for a mission-critical solution to some specific business-related problem. The principal aspect to be considered in this context is that we – the company – must be clear about the advertised capabilities of our service, guaranteeing that they meet your requirements. And this transparency should especially be focused on the process involving the SDLC (Software Development Life Cycle), its phases, and what each one of them entails for both parties.

According to my experience at FullStack Labs, this has to be the first thing communicated in a business-oriented, detailed, and didactic way, even when the client is still a potential one, as you are. The main reason is that it minimizes errors and misunderstandings during the establishment of agreements, especially considering the development of the application. With this in mind, we describe meticulously on our website how our scientifically and empirically based methodology works: that's our Playbook, with its proven phases and solutions to develop a new application or build new features for an existing one. You can give it a further read, but I'd like to briefly introduce its content below.

Phase 1. Design

The first phase of the process is to design and prototype your mission-critical application. This involves the following steps:

• Design Discovery: Establishes the goals and scope of your project and gathers the perfect design team. 

• Technical Discovery: A multi-part effort that aims to either understand and document an existing software stack or research, as well as recommend the best technologies and architecture for your project.

• User Experience Design: This step ensures that we'll be able to solve users' needs efficiently by creating an application that is easily used and understood. 

• User Interaction Design: After the previous steps are completed, it's time to work on the Visual Design by iterating on and selecting a style concept, then turning it into a style guide, to finally create high-quality mockups of each view of your application. 

• Prototype & Estimation: When the high-fidelity designs are ready, we create a clickable prototype to build a development estimate.

Phase 2. Develop

Then, we go to our methodic and scientific approach to building iOS, Android, and web applications, which consists of the following steps:

• Pre-Development Planning: At this point, our main goal is to ensure a smooth, effective, and efficient development process by pre-planning all the solutions for your project's scope, which includes assembling the development team, completing a design-to-development handoff, establishing project milestones, creating stories, and planning 2-week Sprints.

• Active Development: This step includes completing a two-week Sprint, conducting retrospectives at the end of each one of them, and launching version releases based on the project's milestones. 

• Launch: Once all the versions released have been completed and accepted by you and your staff, the application can go for beta testing and, sooner or later, it's time to launch it to the public (or internally).

Phase 3. Maintain 

After the application is launched, it can move into two different paths: the maintenance mode or ongoing active development. The first one is established by a Maintenance Agreement, while the second one has it plus Ongoing Active Development Agreements.

Maintenance Agreement

This is related to applications with limited planned future development, which means, the necessary actions to keep it running well, and involves:

• Error Monitoring & Bug Reporting
• Update Versions
• Performance Optimization
• Update Integrations & Dependencies

Ongoing Active Development Agreements

They're directed to clients who wish to continue adding features and making changes over time. That way, not only an Ongoing Development Agreement will be needed, but also a Maintenance Agreement, including the following: 

• Product Roadmaps
• Design New Features
• Develop New Features

So, our Playbook presents how this continuum process works and is part of a strategy to ensure clear communication with you, even when you're still a potential client. We believe that this first impression is responsible for starting to build our partnership.

The client as a team member

Once this first impression becomes interesting to a potential client and they become our partner, we properly enter into the execution of the phases described above. Thus, based on Agile methodologies, we have as a first principle for this process that managers, designers, developers, and you work as closely as possible with each other, making you a real team member. That's the only way to ensure the parties' awareness of the whole scenario and its problems in an effort to solve them together.

Since FullStack Labs is a bespoke software development company that works with nearshore and offshore models, in other words, has as their staff bespoke software developers around the world – especially in Latin America – the whole communication happens online, which isn't a complex matter nowadays. Our operations are based on tactics that have been functioning since we first entered the market, and are constantly improving with each new experience.

Client collaboration over contract negotiation

It's no secret that the first step in creating effective collaboration between client and company is related to commitment and flexibility, which are established within the negotiation contract. As I have already touched on, software projects must be a change-oriented process, and their success involves regular feedback from the client, which demands clear and continuous communication. Therefore, a contract that specifies an invariable schedule, terms, and costs usually becomes meaningless before the project is even finished. 

Hence, software projects demand requirements and consensus that should be based on a constant state of flux. Major changes during the process aren't uncommon. A logical contract must be flexible, adaptable, and focused on continuous communication. This way, the main responsibility of the client's role is to give feedback on a regular basis to the bespoke software developers and other professionals involved. The key to success is an intense collaboration with the client and a contract that governs it, rather than trying to detail everything in fixed terms. 

Bespoke Software Development: The changing process

While working on a software development project, especially when it comes to a bespoke one, the ability to respond to changes often determines its success or failure. In this scenario, creating plans invariably means considering a continuum of revisions in business and technology. Consequently, the course of a software project can not be planned very far in the future and strongly depends on communication, which is the master key to achieving flexibility and adaptability. Regarding this, let's first understand the concept of bespoke software development.

Bespoke, Custom, Tailor-Made

The adjective "bespoke" has as its main synonym "custom," but we can go beyond that. "Bespoke" is surely the past and the participle adjective of the verb "bespeak" and, besides being used in English to refer to software development, is also common to distinguish tailor-made suits from ready-made ones. A suit isn't as simple as a commodity, nor as complex as software, but to sew one up, communication between tailor and client is imperative. That's because it involves many aspects, such as: the fashion variables of the present time; the occasion for which it is intended; as well as the specific fabric, buttons, and threads. Last and most importantly, the client's body measurements. Suppose the client's body is the business; the occasion corresponds to the mission-critical solution needed; the fabric, buttons, and threads are the programming languages and methodologies that suit the project scope; and the fashion variables are the design patterns established for the software functionality. Voilá, the process of sewing a bespoke suit isn't that far from developing bespoke software.

Most likely there will be some changes to the first suit's draft during its confection. And those revisions will surely happen because of the new demands of the client. Then, they should be promptly communicated to the tailor. Taking new measurements of the body and adjusting one or other details after the first ready model will also be necessary. And it's mandatory that the client speak up about the developing product, so, as a final result, the tailor delivers the perfect suit. They both must work as a team in a process that is a continuum. 

Suitably software for a specific business's needs follows the same line of reasoning. And this line is only a progressive one through constant and effective communication from the parties involved. In this context, it's the present that really matters, what it's up to today. First of all, the business's environment and needs are likely to change, making the requirements shift. Second, clients are given to alter them once the application's prototypes are ready. Last but not least, even if we're sure that they aren't likely to be changed, since we can't make plans much in advance, we won't be very good at estimating how long it will take to develop them completely. Once again, I would like to highlight that, as a bespoke software development company, we need the client's feedback on a regular basis.

Responding to changes to the previous plan

As I've been pointing out throughout this article, there's no such thing as a status quo in bespoke software development. This brings some challenges to be overcome, or at least comprehended since we're talking about a continuum. Let's suppose that, during the process of creating the application, the team decides to organize a project-wide view in a chart in order to give the impression of control over it by tracking collaborative and individual tasks, and crossing them off once completed. This way, they and the client could compare actual dates with planned ones and would realize possible discrepancies, believing that this measure will help plan the forward steps.

Well, that's not what happens in practice. Once the chart loses its previous proposal quickly, since we can't work with a wide view, and even if we could, that wouldn't contribute deeply to producing high-quality results. That's because as the team gains knowledge about the system and the client gains new needs by following the application's development, certain tasks change from the previous plan, becoming obsolete. In the same way, new tasks will be discovered and added to the process. So, the previous plan will undergo changes in shape, not just in dates, making us realize that a better strategy would be to create detailed plans for the next 2 weeks using Agile principles, which means conceiving 2-week Sprints.

In our Playbook, these detailed plans are explained in Phase 2. Develop – Step 2. Active Development. Previously there was Step 1., which consisted of preparing our development plan by assembling the team, scheduling a dev handoff meeting to set up the design aspects, establishing milestones, creating stories, and Sprint planning. Each of the stories created – we could also call them tickets – has an assigned bespoke software developer and describes how a feature should perform in order to be accepted by the Quality Assurance team. The stories are also grouped into 2-week Sprints – a time period that actually obeys the idea of the bespoke software development process as a continuum – and we try to plan as many of them as possible at the beginning of the project. However, the first couple of them are more detailed since we are only able to be accurate in such a short period of time. So, we can already notice that our starting plan to create bespoke software takes into account the upcoming changes that surely will happen. Once again, I highlight that fixed terms don't always work; a continuum should be planned to adapt to changes, and those must be communicated on a regular basis by the client. 

Considering my latest arguments, we can realize that the best planning strategy is to make detailed schemes for the next 2 weeks, very rough ones for the next 3 months, and crude ones beyond that. We should be strongly aware that the requirements we'll be working on for the next 3 months are surely going to change, which means we can have only a vague idea of what the system or application will do after a year. Consequently, this decreasing resolution of plans means that we are only investing in a detailed plan for those tasks that are immediate. Once the detailed plan – for the 2-week Sprint – is made, it's hard to change since the team will have a lot of momentum (drive to work) and commitment. Anyway, since the plan only governs a couple of weeks' worth of time, the rest of it remains flexible. These are the main principles of Agile practices. 

Efficient interaction with the best professionals 

As I've already mentioned, the physical presence of the client in any part of the bespoke software development process isn't imperative nowadays – but constant imparting is. Although the difference in languages and time zones is a key source of communication failures between customers and developers. FullStack Labs works hard to attenuate issues related to that by having contingents and contracted professionals from the USA and Latin America, which means cultures and time zones really close to the clients' reality. Taking this into account, the outsourcing process through the offshore and nearshore models with which we work can be applied to greatly reduce communication issues, considering that having a staff outside the company means achieving impartial technical opinions as well as more business-focused relationships that probably won't cause significant discomfort on the client's part to express their opinion and suggest adjustments. That's a viable solution that creates a scenario in which communication issues from both parties can be reduced.

We can assure you that our teams will fully understand your needs and express them correctly throughout the whole process. In this context, we expect clients to have a unique experience by providing them with high-quality code and exceptional service by avoiding communication problems and giving away an optimal collaborative online environment to ensure the delivery of the best possible product. FSL's solid commitment is to look for the most qualified bespoke software developers.

However, based on our experience, we can tell you that the main communication problems between the parties appear when clients present continuous changes in the system or application requirements. This wouldn't be a problem except for one potential negative scenario: the clients' lack of interest in the development process. A feasible solution to this issue, encouraged by our company's culture, would be the polite intervention of the bespoke software developers by suggesting various ideas for the project to be carried out. They would be based on experiences and judgments that have worked out in previous projects. This action can be ensured precisely because of our goal to always gather the best professionals through a meticulous selection process composed of curriculum analysis, coding challenges, interviews, and the effort to recruit the most suitable professionals for each project based on their profiles.

But once again, I highlight that the client's role is a fundamental piece in the whole project breakdown because only they know the true needs and requirements to achieve a complete solution. Due to this, communication between the parties must generate security and trust, building a relationship that ensures an agile exchange of ideas and facilitating the continuum, a flow of creation based on constant changes informed in the clearest way possible. So, regular feedback from the client will allow the bespoke software developers to implement requirements in an optimal and efficient way, motivating both sides. 

For sure, the need for bananas is much simpler. Basically, the customer has to choose between the existing varieties except for the trading aspects. Nevertheless, a Cavendish banana, for example, doesn't have the same power to impact business and change people's lives as technology.