50+ Questions to Ask Your Development Shop

WARNING: This is a very long post, but the goal is to provide a helpful reference resource for companies seeking outsourced development. My desire is to protect them and their investments. Hopefully, you find this beneficial.

Over the past few weeks, I've been blessed to have had the opportunity to work as an advisor to a handful of companies looking for development shops. These companies have great ideas, and they are looking for the right company to execute and turn those ideas into products.

Unfortunately, development shops aren't what they used to be. Ten years ago, there were only a relatively small number of shops and, for the most part, they were all equally good. However, the really good shops have been bought out by larger companies, and they've been replaced by shops that, more often than not, I've found to be grossly inadequate. With the rise in leetcoding and initiatives like 100 Days of Coding, along with No Code, Low Code, and Pro Code platforms, it seems like everyone believes they are a developer these days. (Personally, I would argue that just because you can write code, it doesn't mean you're a developer. But I digress.)

With all of that said, I've witnessed way too many companies burnt by development shops over the years. And it seems that the number of disastrous experiences continues to increase. Therefore, as one who has run multiple development shops over the past 30 years years, both internal for large companies and as an entrepreneur running three successful development companies, I wanted to provide a list of questions that you should ask a potential development shop before giving them your project. I hope this helps.

NOTE: For clarification below, I will use the term "Client" to refer to the company hiring the development shop (e.g., you), and I will use the term "Provider" to refer to the development shop (e.g., the company performing the development work).

Before You Begin

Before you begin asking questions, you need to make sure that you are clear in your understanding of what engaging a development shop entails.

~ 1. Ask for an MSA upfront.

An MSA (Master Services Agreement) is a contract that outlines the expectations of both the Client and Provider. In other words, it defines the relationship. Note that I'm not saying that the MSA has to be signed and executed. I'm simply recommending that the Client requests a copy of the Provider's MSA as the Client performs their due diligence. The Client should engage a few Providers and compare their MSAs, and the Client should be thoroughly informed of what's specified in each provider's MSA. Furthermore, I'm not just talking about the legal content. I'm also talking about processes, SLAs, and commitments from both parties. The MSA establishes the relationship and articulates the shared responsibilities between both parties, ensuring a successful project and positive outcome for everyone.

~ 2. Understand what you're seeking.

There is a huge difference between outsourcing and staff augmentation, and I've seen a number of projects fail because Clients make incorrect assumptions about the engagement. Let me compare.

Staff Augmentation

In this scenario, the Client hires dedicated development resources who sit directly under the direction of the Client. In other words, the development resources are, in a way, on loan from the Provider. The resources attend the Client's meetings, follow the Client's processes, use the Client's tools, and, if the Client has office space, the resources are filling seats. This, of course, assumes that the Client already has a development team in-house and they are simply looking to add temporary resources to augment the work. In staff augmentation, the hourly rates are typically higher because the resources are fully dedicated to the Client's project—they don't work on anything else except what the Client dictates.

Outsourcing

When outsourcing a project, the Client provides the requirements (either for a feature set or an entire project) and agrees to timelines and costs with the Provider but then leaves it up to the Provider to execute and deliver. In other words, the Client has no say whatsoever in how the Provider accomplishes the work. To put it plainly, the Client does not get to dictate what methodology the Provider uses, the development cycle, the tooling (except for framework and environment specifics), how the Provider tracks features or bugs, etc. Additionally, the Provider's resources do not sit in the Client's office unless agreed upon by both parties. The reason for all of this is simple. The Provider has a responsibility to perform. The Provider is on the hook to deliver the Client's project on time and within budget, and the Provider is liable for breach of contract if they don't.

The Provider is also responsible for time management of their resources. This means a few things. First, the rates are typically lower than staff augmentation because the resources may be split across multiple projects. Don't miss this. When a Provider says the Client gets dedicated resources, it doesn't mean the resources are not working on other projects. It simply means that the Provider isn't switching out different developers during the lifespan of the project/cycle/milestone/etc. The Provider often has multiple projects at one time. The reason for this is simple...to manage risks. The Provider cannot simply put all effort into a single project due to the potential that the Client leaves or fails to pay. As the old adage goes, "Don't pull all of your eggs in a single basket." The bottom line is that the Provider manages the resources, and their only commitment to the Client is to deliver what was agreed upon in the agreed-upon timeframe and at the agreed-upon price.

~ 3. Understand the language.

Rest assured, the Client will hear all kinds of techno jargon. Providers will throw out terms like "cloud," "PWA," and "AI," and the list goes on and on (even in greater technical detail). Providers want to sound impressive, but Clients should not be fooled. Along with the questions below, I've added a short explanation for the purpose. However, the Client should make sure they know what they are asking, and they should have a clear understanding of the answers.

If you are a Client looking for some help (as a fractional or virtual CTO or simply an advisor) in identifying the right Provider, let me know. I'd be happy to work with you.

~ 4. Remain objective.

The questions below are meant to be objective. During the initial discovery, the Client shouldn't be worried about architecture designs and UI/UX. Both come during whiteboard sessions and scoping calls. The point of the questions below is to identify the right Provider for the Client based on the Client's overarching needs. For example, it is important to ensure that the Provider develops in a preferred language/framework or that the Provider is experienced in the desired cloud. Additionally, it's important to ensure that the Client and Provider are aligned on billing expectations and SLAs. Architecture and UI change often. Things like codebases, processes, and clouds should not.

The Questions

These questions are by no means exhaustive. However, they begin the conversation in the right direction. Depending on how the Provider answers, the Client can determine which questions are appropriate for follow-up.

Team Composition

~ 1. How many developers are full-time employees?

Do not ask, "How many developers do you have?" Some Providers use contract developers or even outsource some of their own work to third parties. Clients should make sure they understand how many folks are legitimate employees of the Provider, as this can greatly affect the quality and timeliness of the product delivery.

~ 2. Where are your developers located?

Remote developers are not a big deal. As a matter of fact, many developers perform better when working remotely as they find it easier to get "in the zone." However, the Client should be aware of where developers live because time zones affect availability, and the Client doesn't want to encounter an emergency situation but cannot connect to developers because either they're still sleeping or they've left the office for the day.

~ 3. Can you send me some profiles of the developers I'll be working with?

This question may come later in the engagement (before actual work is performed), but Providers should be able to provide a one-page document of each developer on their team. The one-pager should have a picture, a brief bio, a list of capabilities, and some previous "wins." This isn't a resume, and don't expect previous customers or projects to be listed. Just the basic details.

Web/Service Frameworks

~ 4. Which (frontend and backend) frameworks does your team offer?

I won't go into which are better or worse. What's important here is for the Client to understand if the frameworks align with their goals or not. Some frameworks are great for POCs and prototypes but not for the long term. Other frameworks require more complexity, so there may be some extra time required before the Client "sees something." The Client should be aware of their own needs and ensure that the framework aligns with them. (If you need help, reach out.)

~ 5. Of the frameworks listed above, what is the proficiency across your team?

Many Providers will throw out all sorts of languages—some they know well, others they've dabbled in. The Client needs to ensure that the chosen framework isn't one the Provider has seen some videos on, is playing with, or wants to use the Client's project as a learning experiment. (Personally, I've seen all three done multiple times to the Client's detriment.)

~ 6. For backend frameworks, would they differ across application layers (services, business logic (BLL), and data access/abstraction (DAL))? If so, why?

Way too often, Providers will split the work across their teams based on the experience(s) of their individual developers. This is especially true for many offshore development shops. The result is that the Client is left with an application using multiple frameworks/languages, which creates unnecessary code bloat (in simple terms, too much junk that isn't needed), introduces security and performance risks, and increases overhead in management, maintenance, and hosting. Standardizing on one (or maybe two) frameworks reduces costs, timelines, and bugs because the application layers can share code, including tests. It also tightens security and potentially improves overall performance.

~ 7. Depending on the chosen frameworks for frontend and backend, how does this affect timelines?

Timelines are affected by team proficiency and code complexity. Again, some frameworks are simple but aren't good long-term. Others require more initial wiring before the Client has something they can touch and feel. Furthermore, regardless of the complexity of the framework, developers may require more time if it's a framework with which they are unfamiliar.

~ 8. Depending on the chosen frameworks for frontend and backend, how does this affect costs?

This is a question that pertains to both human resources and hosting resources. As the previous question, costs can be affected by the complexity of the code and the developers' experience with it. Furthermore, some frameworks require more compute and memory resources, which can increase hosting costs. The Client doesn't want to minimize development costs with a simple framework only to find out later that the hosting costs are astronomical because the framework does scale.

Mobile Frameworks

~ 9. Which mobile frameworks does your team offer?

Like web and service frameworks, there are quite a number to choose from, and they all have their pros and cons. To compare them here is outside of scope, but the important thing is for the Client to understand which ones the Provider offers and make sure that they align with the Client's long-term objectives.

~ 10. Do you traditionally build native, transpiled, or PWA for mobile? What's your preference and why?

If you know the difference between the three, this may sound like a redundant question from the previous one. However, functionally, the outcome can be quite different, and depending on the Provider's proficiency and preference, the Client may be forced to accept certain limitations. The Client will always have the fullest flexibility when having a completely native application. However, native apps can be incredibly costly, and most of the time, they aren't necessary.

~ 11. Of the previous two questions, what is the proficiency across your team?

Like the web and service questions above, the Client should understand the proficiency across the Provider's team as it affects costs and timelines.

~ 12. How do you submit apps to the marketplace?

There are a few ways to submit apps to the mobile marketplaces. Honestly, there's not too much difference between them. However, it is important that the Client is aware of the process and its restrictions. This is especially true if there's a potential that the Client may use a different Provider (or bring development in-house) later. The Client doesn't want to get locked into a Provider's custom process or platform.

~ 13. Is the app submitted under my developer account or yours?

Unless asked (because Clients don't know to), Providers often submit applications to the marketplace under their own developer accounts. The reason for this is simple...free marketing. However, this is bad for many reasons (which are outside the scope of this post). Compared to actual development costs, developer accounts on marketplaces are a drop in the bucket ($500/year). Clients should opt to use their own developer accounts and require Providers to do so.

Authentication

~ 14. What provider do you recommend for authentication and why?

There are many authentication services (providers) out there. They all have various features and levels of security. Which authentication service a Provider uses isn't necessarily as important as long as they actually use one. A Client does not want a Provider to roll their own authentication mechanism (e.g., simply storing usernames and passwords in a database). The reason for this is that the Client could be held liable in the instance of a security breach. The Client may feel like their app is not very important and doesn't store any "really important" data. But, what the Client doesn't realize is that if they store usernames and passwords in a database, they store the most important data of all—someone's identity. Clients should make sure that Providers use a third-party authentication service.

~ 15. What is your familiarity and proficiency in app-based RBAC? How would you recommend managing it?

RBAC stands for role-based access and control, and basic apps may not require it. However, if a Client's app involves users who can manage the permissions of other users within the application, then this is a question that must be considered. Once again, the scope of RBAC is outside the intent of this document. However, Clients should be aware of and consider the implications and requirements of handling RBAC responsibly.

~ 16. Is my authentication an organization under your tenant, or would you create my own tenant?

Some authentication services allow someone to create multiple organizations under the same tenant. This is helpful if a company owns multiple applications. However, when outsourcing, a Client should not allow a Provider to create an organization under the Provider's tenant. Instead, the Client should require the Provider to set up a separate tenant in which the Client's identities are stored exclusively. (Not only do organizations sharing a tenant have security and legal risks, but the Client should consider who in the Provider's team has access to the identities and the impact on the Client should those identities be leaked.)

~ 17. Do I have access to my organization (tenant)? If so, how?

Let me be clear...the Client should always be able to have the ability to access identities of their applications. (I'm not advocating unmonitored access to production environments, but the Client should be able to access the identities if they need to.) Clients do not want to find themselves in a situation where, for whatever reason, the Provider is inaccessible, and the Client cannot access identity services.

~ 18. How simple would it be to switch providers, and what would be the process?

Depending on the authentication service, it may not be that difficult to move identities (except for requiring users to recreate passwords). However, the Client must know the implications of doing so. This includes code changes, possibly network (DNS) changes, functional changes within the application, etc.

Data

~ 19. What do you typically recommend for a data repository (e.g., database) and why?

This is simply a discovery question. There are no right or wrong answers. It simply communicates to the Client the preference(s) of the Provider and their reasons. Some things to consider based on the database, however, are scale (including performance, replication, and consistency), security/encryption, licensing, and underlying hardware costs.

~ 20. What is your team's proficiency in structure and non-structured data?

Again, there are not necessarily any right or wrong answers, and the expectation is not that the Provider is recommending one or the other. The goal of this question is to ensure that the Provider has sufficient knowledge of both to make the right decision on which one(s) to use when the time comes.

~ 21. What is your process for designing schemas or ERMs (entity relationships)?

The Provider hasn't necessarily captured any requirements yet. However, it's important for the Client to know how the Provider captures data requirements and how they design databases. Answers to this question inform the Client what tools, libraries, and validation mechanisms the Provider uses to ensure a solid design.

~ 22. What is your experience with data compression and optimization?

Unoptimized data increases costs as it requires more compute resources and increases network traffic. Beyond that, slow application performance negatively affects the user experience. The ideal Provider will at least have some experience in compressing data and optimizing it, along with things like database queries.

~ 23. What is your experience with data warehousing?

For some Clients, this may not be required. However, if a Client's app involves constant calculations and reporting, having a data warehouse would be ideal. Therefore, in those cases, the Client will want to identify a Provider who has experience building data warehouses and analytics cubes (depending on the data repository).

~ 24. Is my data in a shared environment or a fenced environment?

While the terms may differ based on who you talk to, the concepts are the same. There are essentially three types of environments (same for hosting): shared, fenced, and dedicated. The price increases (along with security) from left to right. A shared environment is one where your application or, in this case, your data resides within an environment with others. A fenced (separated, segmented, etc.) environment is where the database shares the hardware with other customers, but the environment is totally separate, hence fenced off. A dedicated environment is one in which physical hardware is separate. Depending on security and compliance, most Clients can leverage fenced environments. Additionally, even web hosting can potentially take advantage of shared environments (especially for development and testing). However, Clients should never allow their data to be in a shared environment unless they are fully aware of and accept the risks. Given that most Providers are leveraging cloud services, this shouldn't be an issue, but Clients must perform their due diligence and verify.

~ 25. Where would my data sit, and do I have access to it (e.g., do I have the database passwords)?

As a follow-up to the previous question, Clients should know if their database is in a cloud (public or private), in the Provider's data center, or on a server in a closet or under a desk (yes, I still see this happening today). An application can always be rewritten; however, a Client's data is the most valuable and cannot be reproduced if lost or stolen. Clients must ensure that the database is being stored securely and reliably. Furthermore, like authentication, Clients should have the ability to not only access their data, but have the ability to request an export of it at any time. (Normally, access and export SLAs are identified in the MSA or an SOW.)

~ 26. How do you manage data backups?

As stated in the previous question, data is king. Clients should always ensure that their data is being backed up. If the Provider is managing the database, then the Client should know how the Provider is managing and storing backups. Furthermore, the Client should know the RPO and RTO of the Provider and, if possible, provide their own in accordance with their business needs. Finally, if a Provider is managing backups, Clients need to have documentation stating how the Provider discards backups, especially in the case the Client leaves for another Provider.

Social (optional)

~ 27. What is your team's experience and proficiency in social platform integration?

This may not be a requirement for all apps, but should a Client require integration with Social Media platforms, the Provider should have experience in implementing the connectivity.

~ 28. Who owns and manages the keys? Would my app be connected via your developer account or mine?

Clients should be aware that connecting an app to a social platform requires what is known as an API key. This is essentially a really long password (simplifying this for the purpose of staying out of the weeds) that identifies an application against a platform. Providers should use API keys that are owned by the Client. This is especially true for mobile apps that connect directly to a social platform. Consider a situation where the Provider is no longer in business, or the Client changes Providers. If the Provider uses their own key, then updating it in a web app may take some time, but not a terribly big deal. However, if such a case happens and the Client needs to update a mobile app, this could mean the app is broken for a few days (if not weeks) while waiting for the marketplace to allow the app update to be distributed. Again, Clients should always require Providers to use keys owned by the Client.

Hosting

~ 29. Where would my app be hosted? In a public cloud, private cloud, or in your dedicated environment?

Like the database, Clients need to make sure that their web application is stored in a reliable and secure setting. Again, I've witnessed too many occurrences where a Client's web application is sitting on a machine under a desk or in a standard back-office closet at the Provider's office location (or worse, in their home, if remote).

~ 30. If it's in a cloud (public or private), who owns the environment, you or me?

This is not a terribly big deal; however, it is worth discussing. There are a lot of pros and cons to both—too many to list here. The important things for a Client to note are making sure that their environments and data are separate from other clients, that they are able to access their environments, and that their apps/data can be exported or moved at any time.

~ 31. What are the typical costs for hosting?

First, this is not an architecture question, and the Client should not expect a detailed report of the costs. Every application is different, and, therefore, they all have different costs. Instead, the Provider should be able to communicate some reasonable ballparks for an initial launch, considering a specific number of users (e.g., 100, 1,000, or 5,000 users). If the Provider has the right level of experience, identifying these costs for some basic implementations (all apps need a hosting environment and a database) should be very straightforward. The goal of this question is two-fold: to ensure that the Provider has the necessary experience and to protect the Client against unnecessary products and services.

~ 32. What do you offer in terms of management and ongoing support? Can you speak to how you do this with other customers?

Does the Provider offer any level of support or maintenance of the environment, especially if the Provider owns the environment? The Client should have this information. Ideally, this information is documented in the MSA or an SOW. The Client should avoid a situation where a Provider finishes a project, "pitches it over the fence," then runs, and, now, the Client is left with something they can't maintain or support, or worse, doesn't work.

~ 33. What type of passwords do I have access to? Am I able to log in to the hosting environments?

I simply cannot say it enough. Clients should retain all passwords and API keys for their applications, along with access to their environments (unless the Provider is what's known as a managed provider and is being paid to maintain the application environment). It's that simple.

~ 34. What is your SLA for uptime?

A service-level agreement for application availability should be provided to the Client from the Provider (this is typically part of the SOW). The SLA identifies the intended availability of the application and its underlying services (e.g., 24x7x365, normal business hours, etc.) The Client must understand that a higher SLA requires more infrastructure and, therefore, can increase costs dramatically. The Provider must know how to architect a solution that can meet the Client's SLA requirements. In situations like this, if the Client requires high availability of the application(s), the Client may wish to hire an architect experienced with designing mission-critical applications (such as myself) who can verify the Provider's proposed architecture.

Testing / QA

~ 35. Please describe your testing process. Is it automated or manual?

In today's market, automation should be used where possible. This certainly includes testing. Why manual testing is possible, it's time-consuming and error-prone. Furthermore, many Providers skip it and merely assume the application works (or the Client becomes the Quality Assurance team). Asking this question also differentiates between a quality development shop and simply a group of coders. While I'll defer the details, a Client should select a Provider who has experience writing automated tests (and will do so as part of the product delivery).

~ 36. What types of testing do you typically perform? Unit testing, integration testing, performance/load/stress testing?

As you can see, there are a handful of various levels of testing. I would recommend that Clients become familiar with the basic premise of each. However, a solid Provider will offer all modes of testing and allow the Client to choose the level and frequency of reach. Again, this question warrants a longer explanation, but that's outside this post's scope.

~ 37. What tools do you use for the types of testing (in the previous question) that you conduct?

Clients may not be familiar with all of the tools (there are a lot—some good and some not so much). That's okay. The point of this question is to ensure that a Provider knows exactly what they're talking about and not simply rambling off buzzwords. A solid Provider will know which tools they are using because they use them often. They will also be able to describe how they work, along with their benefits.

~ 38. Do you offer a guarantee on code coverage in unit testing and integration testing? If so, what is it, and do you offer reports after each cycle to validate coverage?

Clients should expect code coverage for unit tests and integration tests. Most companies offer a range of 60%-80%, with the latter being ideal but the former being sufficient. Clients should not expect anything less than 60% coverage in either testing scenario. A quality Provider will offer 80% coverage but often excel beyond that. Note that Clients should have this requirement in either the MSA or SOW. Do not assume that all Providers offer this or that it's included in the price.

~ 39. Do you offer a guarantee on performance testing against specific thresholds? If so, what is it, and do you offer on-demand reports to validate?

Performance testing (including load and stress) shouldn't be done all the time; however, they should be done on a regular basis. Furthermore, because these types of tests can affect application performance and, thus, the user experience, they should be planned accordingly. Clients should discuss a strategy with the Provider, including the thresholds for which to test (which should be documented in the SOW), and the Provider should supply a report of the outcomes. Finally, should the tests fail, the Client and Provider should discuss steps to improve performance.

Architecture

~ 40. Which architectural design patterns are you familiar with?

There are a number of design patterns that can be implemented when building solid applications. Many developers are familiar with some. Great developers are familiar with most. Only a few developers are familiar with all. Clients should have a conversation with Providers to determine their familiarity, as greater familiarity offers greater flexibility when designing and implementing architectures.

~ 41. Which design patterns have you used previously, and for what purpose?

Taking the previous question a step further, Clients should ask Providers which patterns they've actually used in production. Additionally, Providers should be able to articulate which ones they've used and why they used them versus other patterns. A Client may not be well-versed in design patterns, but rest assured that if a Provider isn't, the Client will easily be able to discern it.

~ 42. Do you deploy using IaC or manually?

Infrastructure as Code (IaC) is the process of using automation to deploy environment resources. Without getting into the weeds, it is recommended that Clients find Providers who are familiar with if not actually implementing, IaC deployments. Ideally, the Provider is already leveraging IaC when possible. Leveraging IaC deployments reduces human error, tightens security, and improves the efficiency of deploying environments. Additionally, should the Client need to switch Providers, they are stuck relying on the Provider to stand up a new environment. Instead, the new Provider can simply execute some code (okay, perhaps I'm simplifying too much, but in theory), and the new environment can configured quite quickly. IaC reduces the guesswork in environment configuration and change management.

~ 43. Do you provide any documentation on the deployed architecture? If so, what?

Architecture documentation is just as important as a user manual. A Client should require the Provider to deliver documentation on how the application is constructed and what types of services are being used. Architecture documentation often includes diagrams, data flow and interservice connectivity, IP addresses, service names and descriptions, firewalls, etc. The documentation should be as clear and concise as possible so that, if a Client needs to choose another Provider, the new Provider can pick up immediately.

Source Code

~ 44. Who owns the source code, and where does it sit?

This almost seems like a no-brainer, but folks would be surprised. I see a lot of sketchy deals going on where clauses exist that state the Provider retains the intellectual property of the application. In other words, the Client owns the data, but the Provider owns the application and source code. A Client should be aware of this and know exactly what they're paying for and what they own. Furthermore, the source should reside in a source code repository at all times. This ensures that, if a developer's machine breaks or the developer is no longer available, the Client has not lost their investment. (While the Provider could pay or perform some type of restitution, the Client cannot recover lost time and potential loss of business/revenue/reputation.)

~ 45. Who has access to the source code?

This is not a question of whether the Client has access to the source code (see next question). Instead, this is a question to understand who among the Provider's team (and, potentially, contract workers) has access. I've witnessed many situations where the Provider has outsourced the development; then, the third party uses the code for another project that they're building for an entirely different provider. Not only can this hurt the Client's intellectual property and threaten security, but there have been some cases where one Client sues another because the source code is exactly the same due to their mutually exclusive Providers using the same third party for development. Clients should protect themselves against these types of risks and know exactly who within the Provider's team has access to what.

~ 46. How do I access the source code?

This may sound like a broken record at this point, but Clients should have access to their source code (at least to what they've paid for). As long as the Client has paid for the work, then they should have access to it at all times. Furthermore, they should have access to everything they've paid for. It is common that Providers may only replicate code changes into a Client's repo once the Client has paid for the work—that's normal in order to protect the Provider's investment. However, once the work has been paid for, the Client should maintain full access at all times. Clients should not have to wait until the project has been completed to have access to the project's source code.

~ 47. Is there a tiered ownership, meaning do I own it after a specific sprint, milestone, etc? Or do I own all of it as it's developed, whether the cycle has been completed or not?

Again, and almost in line with the previous question. The Client should know when incremental changes to their source code are being replicated. This is often outlined in the MSA or SOW. The replication (syncing, merging, etc.) could also be performed after payments. However, some Providers require payments upon reaching a certain milestone or delivering the full product (e.g., 50% upfront, 50% upon completion). This creates a huge risk for the Client, and I don't recommend it. Clients should establish some type of schedule or cadence for when source code is updated and available. (For my companies, I have billed on a weekly basis with terms of NET 15. While a bit more overhead for myself and my customers, I find that this best protects my team, our investment of time and energy, and our client's monetary investment.)

~ 48. Is there any shared ownership?

Again, this may seem like a strange question, but it must be asked. Providers will often create libraries that they use for different Clients. There's nothing wrong with this as it speeds up development, the code is typically well battle-tested, and it can reduce development costs for the Client. The problem is however, I've seen too many MSAs state that any proprietary code remains the property of the Provider. What this means is that should the Client move to another Provider, part of their code is nontransferable. Therefore, the Client will essentially be left with an app with reduced, if not missing, functionality. In some cases, there isn't necessarily anything wrong with this. However, the Client must be aware of cases where the code is shared and then plan accordingly.

~ 49. Are there any hard dependencies of the source code?

This is both a licensing and a platform question. In terms of licensing, certain libraries that a Provider may use involve licenses. In some cases, that license is transferrable, meaning that, as long as the Client doesn't alter the code (e.g., conduct additional development), the Client isn't required to purchase another license (the Provider's license is sufficient). In other cases, the license only covers the Provider and can be used while the Provider oversees/maintains the project. So, in the latter case, if the Client chooses another Provider, they'll be required to purchase their own license for usage regardless of whether any additional development is performed. Again, nothing here is necessarily good or bad. The Client simply needs to be aware.

In terms of platform, this question is especially relevant today, where No Code, Low Code, and Pro Code platforms are heavily used. What many Providers sell as "custom applications" today are nothing more than applications built on these types of platforms. Not only do they potentially limit the functionality of the Client's application, but, much worse, they limit the Client's ability to move elsewhere. In some cases, these types of platforms are fine (I use some of them for specific projects). However, the Client must still be aware in case the Provider is using such a platform so that they can plan accordingly and pivot earlier than later.

~ 50. What type of documentation do you provide for the source code?

Just like architecture, the source code must be adequately documented. Having comments on every single line is overkill. However, the documentation should still be sufficient for another developer to quickly asses the intent and function of code within the application. Often source code documentation includes a few things: 1) inline comments to explain code that may seem a bit confusing or is satisfying an edge case, 2) a wiki to describe the code holistically, 3) API schema for services, 4) what's required and how to execute the code. The MSA or SOW should outline expectations for source code documentation.

Process

~ 51. What development process do you typically follow and why?

There are many processes for development, and many Providers have their own preferences. Some providers may have their own or use multiple. The goal in asking this question is simply to understand the Provider's process and to level set the Client's expectations. For example, if the Provider says they leverage 4- or 6-week sprints, it's unreasonable for the Client to expect to see changes within a week. On the other hand, if a Provider says they leverage 4- or 6-week sprints, it's completely reasonable for the Client to expect changes in 4 or 6 weeks, respectively. Again, it's all about setting expectations.

A few notes on this one... First, there are many arguments for which development process (methodology) is better. The completely honest answer is there is none. They all work equally well based on the team. I've seen teams run Waterfall extremely well and efficiently; I've witnessed teams who have absolutely butchered Agile. The Client should not get hung up on the process, but the deliverable. In other words, the Client isn't paying the Provider based on which process they're running. The Client is paying the Provider to produce results. As long as the Provider does that within the agreed-upon price and timelines, the Client should not be concerned with which process was used.

Second, as stated above in Outsourcing but worth stating again, hardly ever does the Client have the opportunity to dictate which process the Provider uses. The Client may dictate timelines and delivery dates but not the process. Once again, the Client must realize that they are paying the Provider to produce. The Provider's responsibility is to deliver, otherwise they are liable for breach of contract.

~ 52. How often do I receive deliverables?

Unlike the source code, this question is about working code. In other words, this question sets the expectations for the Client around when the Provider will deliver updates to the application. It's important to note that the Client decides when the updates should be deployed (pushed to production), but the Provider can deliver updates in a regular cadence. For example, a Client has contracted a Provider to build an application for accountants here in the US. The Provider's delivery schedule may be every two weeks. However, the Client may wish to forego any updates to production between January and May (US tax season). Delivery and deployment are not the same thing. The Client and Provider must identify expectations.

~ 53. How do you typically conduct discovery and define SOWs?

This question helps to set expectations between the Client and Provider. Every Provider is different, and, in most cases, the Provider gets to dictate the discovery process while collaborating with the Client to draft the SOW. As stated a few times already, the Provider is on the hook the perform. Therefore, they know their team, and they've optimized their process. When a Client tries to control the discovery process, they do so to their detriment. Clients should ask the question so that they can determine if the Provider is the right fit. Once again, the Provider doesn't change their Process, but the Client may have to adjust to work with the Provider.

~ 54. How would I submit feature requests and bugs?

This is a question for not only process but also clarity and clear communication. From experience, sending feature requests and alerting of bugs via text, email, and carrier pigeon are the worst possible solutions. Solid Providers will have a well-maintained (groomed) backlog of requirements and bugs. Furthermore, they will have a mechanism for Clients to submit feature requests and bugs, AND for Clients to track their progress. This may mean that a Provider provides the Client with access to the tracking system. In other cases, the Provider may have another platform. Regardless, the Client should have visibility (even if it's just a weekly report) into the progress of development (STRONG NOTE: this does not mean the Client micromanaging development, just visibility), and the Client should have a way to submit feature requests and bugs via an alternative to emails.

~ 55. What is your process for submitting change requests?

To be clear, there is a difference between submitting features and change requests. The former is regarding NET new functionality; the latter is changing pre-existing functionality. Some Providers have a different process, and the Client should not assume that it's the same. The Client should make sure that they fully understand the RFC (request for change) process so that their expectations are met. Often, the process for submitting features and changes is outlined in the MSA or SOW, but they're not required to be, as they could differ based on the Client, project, or situation.

~ 56. How do you communicate when features are implemented and bugs are fixed?

In some cases, the Client may need to update their users when a new feature is released, or a bug is fixed, especially if either affects the user experience (positively or negatively). So, it's important that the Client and Provider establish clear communication on the front end so that the Client is protected. As stated above, most of the time and unless agreed upon otherwise, the Client will dictate when updates are released. Therefore, the Client will know what's being pushed out. But, this is not always the case, and one should never assume. Ideally, a Provider should (not required, but best practices) provide a release manifest so that the Client knows what new functionality has been implemented and what bugs have been fixed.

~ 57. Am I charged for bug fixes?

This is a very important question and can often catch Clients unaware. Technically speaking, the bug exists because of the Provider (whether intended or not). Unfortunately, there are some providers who still charge hourly rates for fixing bugs. Personally, I feel this is a bad practice, but nonetheless, it still happens. The Client should be aware of the Provider's support for bugs and negotiate a period of unconditional fixes. As an example (and what I typically recommend), the Client should negotiate a 30-60 day "warranty" on NET new functionality or change requests. This means that if the Client discovers a bug in new updates to the application (new feature or where a requested change has been made), the Provider fixes it (and continues to work on it until it is fixed) at no charge. However, if either the warranty period has expired or a bug is found in another part of the application that is not currently being worked on, the Client pays the Provider at the standard hourly rate. I find that this approach protects both parties.

~ 58. What is the turnaround time SLA for bug fixes?

This question is extremely important for Clients. Way too often, (bad) Providers focus on delivering a functional app so that they can get their remaining payment and move on to the next project. In working with such Providers, a Client may find a bug and alert the Provider of it. However, regardless of the fact that an hourly rate has been established for support and bug fixes, the Provider will move the bug to the bottom of their queue. In other words, such Providers deprioritize bugs of past work in favor of new work and larger contracts (an SOW is typically larger than the standard hourly rate as it contains some margin for developmental unknowns). In these cases, the Client is waiting for days, if not weeks or months, for an update or fix. Clients must establish and document an SLA for turnaround times when fixing bugs.

~ 59. Does your process include CI/CD? If so, please describe your process and what that includes.

This is a standard question, and there's not much to it. While there are a lot of details around CI/CD, the important thing is for Clients to choose Providers who are well-versed in CI/CD mechanics. As stated above, manual testing and deployments are subject to human error. Automating deployments reduces errors, tightens security, and improves delivery timelines. There really isn't much to a right or wrong answer here. Again, the important thing is to ensure that the Client chooses a Provider who is conducting CI/CD deployments.

~ 60. Do you have development/staging environments where I can test the application and any changes before they are rolled out?

This is quite important for web applications, but it's extremely important for mobile apps. The Provider should allow the Client to test the application (and any future changes or bug fixes) in a separate environment before the updated application is deployed to production. If a CI/CD pipeline is available (see previous question), then doing this is quite easy. If such a pipeline is not available, then Providers often shy away from providing such environments because it detracts from development.

Word of caution. Having such environments is important for web apps but critical for mobile apps. The reason is that the Client needs to test their applications before they are released. If a web application is released to production with a bug, then theoretically (assuming the right procedures are in place), it is very easy for the Provider to roll out another update with the correction. However, if a mobile app is released to production and a bug is found, the Client may have to wait a few days for the marketplaces to deploy the release to user devices. Clients should require development and/or staging environments for testing and acceptance of changes.

Costing

~ 61. How do I pay for development? Is it per month, per sprint/cycle, per milestone, per release, etc? Please describe.

Clients should understand how they pay and when they pay. These costs can be outlined in the MSA but are often included in each SOW as they can change based on the scope of the project and required timelines.

~ 62. What quality guarantee do I get?

This is not a question of a "money back guarantee," but rather establishing how the Provider ensures their work. Clients should protect themselves from buying a lemon. In other words (and again, I've seen this too many times), Clients will purchase development, and as soon as the project is delivered and the Provider collects payment, the Provider is unresponsive to any assistance or bugs, etc. Providers should document (either in theMSA or SOW) their quality guarantee.

~ 63. Please provide a general hourly rate (fee sheet) for your development roles.

Yes, a Client can ask for this. No, this is not too much for a Provider to provide. In many cases, a Provider will inflate their costs in order to float folks sitting on their bench being unproductive. The Client isn't responsible for the Provider's poor planning and HR costs. The Client should ask for a fee schedule and do the math for the project. Additionally, a fee schedule will provide the Client with an understanding of what hourly costs look like for bug fixes and RFCs.

One thing to note. It is perfectly acceptable to a Provider to build in margin for development because there are always unknowns—it doesn't matter how long someone has been developing applications or building infrastructures. Things always happen. Acceptable margins are 15-25%, with certain limitations. However, Clients should never be expected to pay 50% margins. In this case, either the Provider is trying to float developers, or they don't know how to scope an SOW accurately. Either way, the Client should run.

~ 64. What are the overtime and emergency rates?

Believe it or not, developers have lives too. They don't just sit around in the dark and eat pizza all day (okay, some do). Clients should not expect Providers to be available 24/7. Honestly, Providers will never care as much about a Client's project as the Client does.

With that said, Providers should clearly state their business hours and when Clients can expect responses. This information is typically in the MSA because the office hours don't change. The base hourly rate applies to the developer's time during normal business hours. For overtime and emergency situations, those rates differ.

So, what's the difference between the two? Overtime is usually a pre-discussed set of hours that the developer is working. This is typically an on-call or support situation (after hours or weekends). Not only are these hours predetermined, but they are written in the SOW as they are different for each Client. Emergency hours are just that—hours that are not prearranged, but the developer is called in to address an emergency situation (for example, the system has crashed). Emergency hours are usually a lot more expensive than standard overtime, and both are usually multiple of the base pay stated on the fee schedule (ex., overtime is 1.5x the base rate, and emergencies are 2.5x the base rate). Regardless, both should be written into the SOW.

That's It

Whew! That's quite a bit. However, again, I'm hopeful this helps somebody out there who is looking at hiring a dev shop for their next project. I've witnessed too many disheartened dreamers who have invested time, energy, emotion, and finances into a dev shop only to be left without anything. Let's stop the madness; let's stop the bleeding.

If you have questions, need an advisor, or want to discuss your next project, send me a message. I'd be happy to connect.

Blessings and best of luck!

- Cover Photo by Elisa Ventur on Unsplash.