What Questions Should You Ask a Software Development Company?
Choosing a Software Development Company without asking the correct questions can cause severe losses. A low quotation could lead to high expenses if the requirements were not researched properly, product owners and developers leave the project right after the sales meeting, QA testing is conducted close to the deadline, rules of ownership of the work are unclear, or the system is not ready for the workload it was supposed to handle. The buyer must define before entering a contract:
- Which company is going to develop the product
- how the requirements are going to be verified
- how the progress is going to be monitored
- how the quality assurance is going to be carried out
- how the ownership is going to be transferred after the release
Such replies provide much more information about the developer than the stunning portfolio.
An assessment should determine a few things:
- Who will actually work on the project?
- How will the company turn your business requirements into technical requirements?
- What similar systems has the team delivered?
- How will progress, risks, costs, and changes be reported?
- How does testing happen before production?
- What happens when something goes wrong after launch?
- Who owns the source code, documentation, designs, and other project assets?
- How does the pricing model work?
- What happens if the first proposed architecture proves unsuitable?
These questions are not meant to showcase technical knowledge of the buyer; they rather seek to find out if the company has a systematic approach to software delivery.
Why the First Question Should Be About the People Building Your Software
An easy-to-make mistake is to inquire about the number of developers a given company has instead of asking about which people will actually build your system.
A firm may advertise to have hundreds of engineers, yet still assign your project to a small team whose experience may not fully meet your needs. This situation cannot be used to disqualify a company. The important factor is whether the team engaged in your project is capable of performing the required engineering work, and whether it is possible to talk to the individuals making technical decisions.
You should ask:
"Who will actually work on my project, and what will each person be responsible for?"
A good answer should cover the roles one should expect.
In the case of a considerable platform, one might see a project manager, solution architect, frontend developer, backend developer, database expert, QA engineer, DevOps professional, and UX specialist.
At KernDev, we provide dedicated in-house teams because continuity matters. Our company employs more than 750 IT specialists, including more than 500 software engineers and 45 dedicated project managers. This structure aims to provide many specialists. The purpose of that structure is not simply to present a large number. It allows the right technical roles to be assigned based on the project's actual requirements.
Our Software Development Services cover the development lifecycle from technical planning through deployment and continued support.
What should you ask about technical experience?
Avoid vague statements like "We have experience with React",
"We have experience with AWS", or
"We have developed mobile applications".
You should always demand clarifications on how those technologies were used.
E.g., "Have you built a system with similar transaction volume, integrations, security requirements, or user roles?"
This question is much more relevant than just verifying the technologies mentioned on the company's web page.
The development team should be able to explain all architectural choices in simple terms.
If your company is running a financial platform, you need to implement strict access control, accountability, data protection, as well as payment compliance, encrypted data, and reliable transaction processing.
If your business is a marketplace, your system needs to support account types for buyers and sellers, comprehensive search, payment processing, messaging, moderation, and other functionalities like search, payments, messaging, moderation, analytics, notifications, and third-party integrations.
Technology should accommodate business needs, rather than business adapting to technology.
How Will You Turn My Business Idea Into Technical Requirements?
This is one of the inquiries that we consider worth far more inquiry.
A founder may give a 20-page specification to the team.
Why does it happen?
It is due to the fact that requirements describe the product features without delivering an explanation of the business rules behind the features.
For instance:
"Clients can cancel their order".
It sounds easy.
But what if the order is already shipped?
Secondly, what if the payment has already been charged?
Besides, what if it is possible to cancel only part of the order?
What will happen to the stocks?
Who will get the refund?
What will happen if a shipping agency creates a shipment label?
Good development teams will come up with the above questions before the project starts.
At KernDev, we examine the project in terms of business goals and objectives, needed processes and technologies, possible risks, feasibility of each scheme, and any other issues.
At KernDev, at the outset of each project, we conduct an evaluation of business goals, processes, technical specifications, dependencies, risks, and other considerations that need to be taken into account prior to implementation. This is one of the key motives behind starting our work with market analysis and project planning instead of directly allocating tickets to developers.
For organizations that need broader technical assessment, our IT Consulting Services can be used to examine architecture, technology choices, modernization requirements, integration needs, and technical risks.
Ask The Company To Show You Its Discovery Process
A serious vendor should be able to explain what happens after the sales call.
Ask:
"What you do before development begins?"
A Reputed answer should also include tasks such as:
- Requirements gathering
- Business workflow analysis
- Technical feasibility assessment
- Architecture planning
- User journey analysis
- Database planning
- Integration assessment
- Security requirements
- Testing requirements
- Project estimation
- Delivery milestones
Be careful if the company gives you a quote after knowing just a couple of sentences of your idea. Quick quotations may seem to suit you perfectly, but software pricing without thorough discovery results in problems in the future.
What Similar Projects Have You Actually Delivered?
A portfolio must not be viewed as a gallery. It should be seen as proof.
You should ask: "Could you give me an example of a project which is of a similar nature to mine and name the challenges that came across?" It is the second part of the inquiry where the conversation starts to take shape.
Most companies can name what they did.
However, a professional engineer should also be able to explain why some things went wrong, what changes were introduced, which technological decision was important, and what he would do differently. This is what the consumers should pay attention to.
For instance, suppose you are looking for a CRM that interacts with an ERP, email solution, payment application, customer portal, and reporting system.
Independently of what your organization is doing with data, you need to have a clear understanding of the following:
- How customer data moved between systems
- How duplicate records were handled
- How permissions were managed
- How failures were detected
- How integrations were tested
- How reporting was generated
- How the system handled increased usage
This is also where a Custom Application Services discussion can become more useful than a generic "we build apps" conversation because the assessment should focus on the actual workflows your application must support.
What Does Your Development Process Look Like?
It is important to ask the company to help you understand the entire development process of the project and its implementation. Getting a vague answer about the use of Agile will not give you what you need to know, as Agile is just an approach to development and does not explain the project management method.
Ask:
"What will happen during the first 30 days?"
Then ask:
"What will I receive at the end of that period?"
Make sure to ask about the deliverables, for example, requirements documentation, architecture, wireframes, a prototype, a database, technical specifications, development milestones, test plans, or something else.
KernDev's approach to development involves different stages like business assessment, UX, architecture, MVP stage if any, iterative development, and launch support.
It makes this approach sound credible because it gives the clients a chance to see how progress is achieved in development instead of just hearing about it from the manager.
How Do You Handle Design Before Development?
A software project might contain code that functions well technically but may still fail due to difficulties the users experience in using the software.
The pertinent question here is: "Who validates the user experience before development begins?"
For any customer-oriented software program, this question will help to avoid serious rewrites in systems.
Proper development of interface design requires consideration of:
- User journeys
- Navigation structure
- Mobile and desktop behavior
- Accessibility
- Forms and validation
- Error states
- Empty states
- Permissions
- Conversion paths
- Information hierarchy
Our Design and User Experience services involve research, information architecture, wireframes, prototypes, testing, and interface design before the final development cycle.
Thus, we recommend asking this question earlier during the work on the project instead of waiting until development is finished to find out that the final result is not successful for the users.
The clickable prototype will provide valuable insight into usability long before the production code is released.
What Happens When Requirements Change?
Changes in requirements are not necessarily a failure of the project.
A company might learn something new from its customers, come across a regulation, change the way it does business, or find out that some functionality is not needed anymore.
Change is not the most important problem.
The biggest problem is uncontrolled change.
The company must be asked,
"What happens if I request a new feature halfway through development?"
The company should explain:
- How the request is documented.
- How technical impact is assessed.
- How additional time is estimated.
- How additional cost is calculated.
- Whether another feature must move to a later milestone.
- Who approves the change.
- How the project plan is updated.
At KernDev, clients are shown what will happen in case they approve additional implementation so that they are protected along with developers.
That protects both sides.
A client knows what the request will cost.
The development team knows what has actually been approved.
What Should You Ask About QA and Testing?
Refrain from solely asking:
"Are QA services offered?"
Inquire instead:
"When do you start testing?"
If they answer "testing starts after the development process," you can also inquire:
"How are defects detected during the development process?"
The testing function must not be taken as a final step before the launch of the product.
The software may require various types of tests, including functional testing, integration testing, performance testing, security testing, regression testing, mobile testing, browser testing and user acceptance testing, etc., depending on what is needed.
Our Quality Assurance Services are integrated into the development lifecycle rather than being treated as a final activity.
Think of the situation when there is a fault in the payment workflow.
If the defect is encountered during the development process, the programmers have the opportunity to fix it before the product hits the market.
If the matter is not discovered in time and the affected product is put into operation, it can lead to failed transactions, requests for help, complaints from users, refunds, loss of credibility, and an enormous amount of repairs required.
That is why our engineers do not evaluate the quality of the project based on the information that functions have been implemented.
A KernDev Experience: When the Right Questions Changed the Project
Recently, we received a new client requiring our team's services to develop a business platform integrating accounting functions like customer record-keeping, internal workflows, reporting, and third-party services.
The client was positive that it was appropriate to start the development process of the system right away and went ahead with coding & development.
Our specialists, however, realized during the analysis phase that the risk didn't lie in developing many features but rather in the workflow being proposed.
The workflow provided for multiple systems with some areas of overlap in keeping information about the customers and, therefore, results from the use of different systems were ambiguous information-wise.
Then, we separated the task of the project into milestones. The first milestone is breaking down the tasks into specifications and the architecture.
The second milestone pertains to the overall procedure and the data structures involved in the project.
The third milestone includes the integration as well as internal reporting.
The fourth milestone is around testing, user acceptance testing, preparation for deployment, and transfer of knowledge.
The leadership of the customer wished to come up with some extra features in the initial release, but we discouraged them from having all of the features in the first project, as they were not so important in validating the core process of the business.
The conversation was significant. We were not just answering yes to every demanded function. We were talking about the priorities of the work in the project and the reasons for such decisions.
The project manager used to prepare reports on the project throughout the whole process of working on the project so that the client would be aware of the stage of completion, current priorities, challenges, and milestones of the project. The engineering team was capable of solving integration problems during testing rather than waiting for them.
The client's management team proposed to incorporate some features in the first version; we provided our recommendation not to include all of them in the first version at that point due to the fact that not all of them were necessary to check if the main business process is operating.
It was important to have that conversation because we did not simply agree to all features. We explained the order of work and the reasons for it.
The project manager performed regular reporting during the whole engagement so that the client could see the completed work, the current priority issues, and upcoming milestones.
The engineering team worked out the integration issues during the testing phase rather than waiting for them to come up in production.
As a result, the project went from a vague set of features to a clearly defined product structure, along with milestones and a plan for future releases.
The lesson from that project is a lesson that we always share with our potential clients:
The right software development company should question your requirements when doing so protects the project.
A vendor that agrees with every request may feel easier to work with during a sales call.
An engineering partner should sometimes tell you that a requested feature belongs later, that an assumption needs validation, or that an architecture decision could create problems.
That is part of responsible software development.
A development contract should not simply conclude with "the app is live."
One should ask the question:
"Who is responsible for bug fixing, upgrades, security updates, infrastructure problems, and future improvements post-launch?"
Post-launch maintenance is crucial after software is deployed.
- Libraries change.
- Cloud services change.
- Browsers change.
- OS Operating systems change.
- Security threats change.
- Business needs change.
Using a company that develops software but does not support it after launch can incapacitate you when you need assistance the most.
KernDev provides IT Support Maintenance Services for ongoing issue management, updates, bug resolution, feature work, performance refinement, and technology upgrades.
That post-launch relationship can also give the original engineering team useful context when future requirements arise because they already understand the system's architecture and history.
How Is Software Development Agency Pricing Calculated?
The technical team is just one aspect of selecting a Software Development Company. A project can have skilled specialists and be very complicated due to ambiguous pricing, unclear ownership of the source code, unclear division of responsibilities in terms of security between different parties, or people presented during the sales stage are not the ones working on the project. You need to ask about how the company manages funds, intellectual property, security, personnel, communication, and responsibilities after the project is finished before you sign a contract.
The questions that must be answered are as follows:
- What exactly is included in the quoted price?
- How does the company handle additional work?
- Who owns the source code and project assets?
- What happens if the relationship ends?
- Which engineers will have access to production systems?
- How are credentials and sensitive information protected?
- Can the client interview the proposed development team?
- How frequently will progress be reported?
- Who makes technical decisions?
- What happens if a milestone is delayed?
- What support remains available after deployment?
If you want to be a good buyer, you should not hesitate to ask the above-mentioned questions, the answers to them will help avoid disputes.
Price is one of the first questions buyers ask, but simply asking, "How much is my software going to cost?" is quite seldom helpful.
A better question would be: "What are the elements you are estimating the price with?"
A veritable development company can explain how the requirements, the complexity, the needed integrations, the composition of the team, the timeline, the testing, the infrastructure, the security requirements, and the post-launch support will determine the estimate.
The term software development agency price can mean quite different business models.
There are several ways to charge a client:
The main options:
- A fixed project fee
- Time and materials
- A monthly development arrangement
- A dedicated team fee
- A hybrid arrangement
- A milestone-based structure
None is inherently correct or incorrect.
The most suitable option will depend on the level of clarity of the needs and possible changes in their nature.
Company A quotes $80,000 while Company B suggests the price of $130,000.
Initially, Company A looks like a better option.
However, later it becomes clear that the quote from Company A does not include QA, cloud configuration, post-launch support, some of the integrations, documentation, and other verbally discussed requirements.
The situation has changed.
The core question here is not:
"Whose prices are lower?"
It poses the following question:
"What actually do I get for the price?"
With the help of KernDev, we can estimate costs based on the delivery requirements and technical complexity of the project. We answer the question of How Much Does Custom Software Development Actually Cost in detail. We make sure we define the details of the scope of the project, assumptions, priorities, risks, and deliverables provided to the customer.
We think that someone who buys software should ask about the assumptions that accompany the quote.
For instance:
- "How many environments does the quote cover?"
- "Is the price for testing?"
- "Are third-party integrations included?"
- "Who has to pay for cloud infrastructure?"
- "What happens if a requirement changes?"
- "Is there post-launch support?"
Should You Ask for a Dedicated Software Development Team?
If your project involves ongoing development instead of one short delivery, inquire about the team arrangement.
A dedicated software development team is a good choice when the product will go through changes, the specifications will evolve, or the company needs to be in contact with the engineers throughout the process.
However, it is not sufficient to know only this information.
Ask: "Who are the members of the team, what are they responsible for, and how much time will they spend on my project?"
You should also unveil the "plan B" regarding the team member's unavailability. For instance, if your entire backend knowledge relies on one developer only, this exposes you to a certain risk.
A successful project delivery is possible only when one does not depend on a single person's memory.
At KernDev, we make sure that we put together dedicated teams based on the project's technical needs and requirements.
They may involve project management, architecture, frontend/backend engineering, QA, DevOps, databases, and UX specialists.
The main point is not the number of individuals. It is whether the individuals involved in the project can together execute the project as intended. Check if the senior individuals still participate in the process. Another question to consider is: "Will senior engineers involved in evaluating and pricing my project stay in the picture throughout its delivery?"
One common concern among clients is that a highly skilled professional would take part only in sales discussions and would disappear once the deal is signed.
Find out who is responsible for making architectural decisions.
Find out who carries out financial reviews of significant technical work.
Find out who solves harder production problems.
Find out who is involved in approving a decision.
One should know the answer to this question before proceeding with development.
The question to ask is:
"When the project is completed, who owns the source code, designs, documentation, database structure, and other project assets?"
Do not settle on mere verbal confirmation. You need to read the contract.
There should be a clear description of the ownership rights and licensing in the document.
This fact is especially significant if the software project is unique and incorporates some special logic that can give a competitive advantage to a client's business.
Thus, you should get the answers to the following questions:
- Who owns the custom source code
- When ownership transfers
- Whether third-party libraries have separate licenses
- Who owns design files
- Who controls cloud accounts
- Who controls domain and infrastructure credentials
- What documentation will be delivered
- What happens if the contract ends
Besides, it is important to ask: "Will my in-house specialists be able to maintain and run the software in the future?"
A good partner will not create unnecessary dependencies in the collaboration.
What Security Questions Should You Ask Before Giving a Development Company Access?
Before any credentials, customer data, access to production, or sensitive information of the business is handed over to the development team, the issue of security must be tackled.
To begin with, you are to ask the following questions:
"How do you protect my data and systems?"
Then follow this up with the second question:
"Who has access to production data?"
In order to make it possible to engage in a conversation about security, one should talk about authentication, authorization, encryption, secrets management, logging, environment separation, code review, dependency management, vulnerability management, and incident management.
The relevant security requirements will depend on the type of application.
Hence, the security requirements of a marketing web page are completely different from those of a financial platform with payment information.
In the case of healthcare applications, there might be some necessary compliance requirements affecting the architecture of the system and access control, auditing, and information processing.
KernDev is ready to deal with security requirements proper for any area or industry. Our experience is related to PCI-DSS compliance and best practices based on ISO/IEC 27001 regulations.
Our Cybersecurity Services address security assessment and protection requirements as part of the wider technology environment.
Security should not be implemented just prior to deployment.
The question is:
"How do you spot security issues while the software is constructed?"
For instance, the team might do code reviews, run some automated tests, check dependencies, enforce access controls, carry out appropriate testing, and provide security testing services.
The answer must explain actual actions, not just say: "We care about security."
This is nothing anybody cannot say.
While creating any applications, a software firm may have to deal with very confidential data.
That includes client records, monetary information, employee information, operational procedures, logos,
or trade secrets.
Now, ask the question:
"Do you need production data to create and test the application?"
Developers can often use sanitized, anonymized, synthetic, or limited datasets for application development,
instead of unrestricted production data.
You should also ask the following:
"How do we remove access after someone leaves the project?"
An effective process should have a proper access management lifecycle.
Access needs to be granted based on a person's responsibilities and revoked once there's no use for their access to the system.
This question is more than just technical.
This is about governance.
Your software development company needs to provide you with full information about who has access to what, and the reasons behind it.
How Do You Handle APIs and Third-Party Integrations?
Several software projects fail to consider external systems adequately. You may have to deal with payment providers, delivery services, financial software, CRM software, identity services, maps, messaging services, analytics, or other external APIs.
You can inquire, "What integrations do you have experience with that are similar to mine?" Follow it with "What happens if the external service is not available anymore?"
This particular question makes one aware of failures in architecture.
If the software relies on a payment system,
What are the consequences in case of a timeout?
Does the customer receive an error?
Does the system retry?
Could the transaction accidentally be processed twice?
Does the order remain pending?
Does an administrator receive an alert?
All the situations and their possibilities are to be accounted for at the stage of architecture creation.
KernDev has the ability to work with API-first systems, using RESTful APIs, modular services, and integration patterns.
Our API Development Services address applications that need internal or external APIs as part of their architecture.
The question is not whether a company utilizes APIs. You should ask how they are managing failure, authentication, versioning, monitoring, rate limitations, retry process, and ensuring data consistency.
What Happens If My Existing Software Is Outdated?
Sometimes, existing applications have viable business logic and can be upgraded rather than completely replaced.
In which case, ask:
"Would you suggest a full system replacement, or would you recommend upgrading my current system?"
In cases like this, you'll be relying on expertise.
A legacy system may have any of the following:
- Old programming languages
- Outdated dependencies
- Poor documentation
- Database limitations
- Security weaknesses
- Slow response times
- Difficult deployment procedures
- Manual operational processes
- Tight coupling between unrelated functions
Replacing all the elements in one go might not be the best course of action.
In fact, a gradual approach might be better under certain circumstances, with our development team analyzing the existing program first before making recommendations.
Our engineers might recommend refactoring, breaking the functions down into separate services, moving to the cloud, changing the database format, developing new APIs, or implementing a smaller service-based system instead of a monolithic one.
The right answer depends on the system being used.
How Will You Handle Cloud Infrastructure?
Whenever utilizing a software solution in the cloud, you should ask yourself:
"Who is going to design, configure, operate, and maintain the server?"
Then ask:
"Which cloud provider do you suggest, and what is the reason behind your decision?"
A proper answer should demonstrate how a particular solution corresponds to your workload and business goals.
KernDev collaborates with AWS, Microsoft Azure, and Google Cloud.
Our Cloud and DevOps services cover cloud migration, cloud-native architecture, CI/CD pipelines, containerization, infrastructure as code, monitoring, performance management, and security hardening.
The real question should not be whether a company has a cloud badge.
You need to get an answer regarding the costs associated with different levels of service deployment. For instance, a system having 1,000 users may operate very differently than one with 500,000 users.
Request the development company to answer:
- Expected infrastructure requirements
- Environment structure
- Deployment process
- Monitoring
- Backup approach
- Recovery procedures
- Access controls
- Estimated operating costs
The charges incurred in using the cloud services are part of the actual expenses.
They should not be considered casually.
How Often Will I Hear From Your Team?
Communication issues are seldom born out of one single catastrophic event.
communication.
A deadline passes.
There are no updates for a client.
A query goes unanswered.
An important technical decision is made with a lack of justification.
The result is that the client soon learns that something has gone wrong with the timeline.
The question must be:
"How will communication take place?"
Then make inquiries about specific details.
- Who is my primary contact?
- How often are meetings held?
- How are decisions documented?
- How are blockers reported?
- How are scope changes communicated?
- How can I review completed work?
- How can I raise concerns?
- What information appears in project reports?
At KernDev, each project has a dedicated project manager who coordinates
the communications and deliveries. In addition to that, we provide clients with personalized project reporting dashboards which help to keep track of the projects throughout their lifecycle, including project delivery, scope, and business results.
The goal of reporting is not to fill in Excel tables but rather to make sure that the information
about the project is easily comprehensible for anybody who is in charge of the business.
This is one inquiry that buyers often overlook.
Inquire:
"What do you do if a milestone is postponed?"
Don't settle for:
"Our delivery will always be timely."
Query what occurs in the eventuality of something unforeseen happening.
Software development projects are involved with numerous dependencies.
A third-party API may be subject to change.
Requirements may turn out to be harder to accomplish than anticipated.
A security issue may cause the need for extra work.
It may take longer to get third-party approval.
The crucial question is whether a vendor has a system in place to catch any possible issues right away.
At KernDev, we track delivery risks from the planning stage onwards. When a risk comes up, our staff considers its impact on scope, time, resources, and technical dependencies.
Customers shouldn't find out about a delay after the deadline has already passed.
A project manager must address the problem before there is no chance to act.
Should You Ask for a Trial Period?
For companies that are hesitant to make a long-term commitment, a trial period can eliminate concerns related to taking a leap of faith. At KernDev, we never charge for the trial period. Clients can sample our services for a month and decide if they want to continue working with us after that. This is a win-win situation because both parties can gauge the nature of their relationship.
The client is able to appreciate:
- Communication
- Engineering quality
- Reporting
- Responsiveness
- Technical decision-making
- Delivery discipline
- Team compatibility
Likewise, the vendor gets a chance to learn about the customer's business processes, decision-making procedures, technical setup, and expectations.
Naturally, a month cannot prove anything about the multi-year partnership. Nevertheless, it can tell if the parties are compatible enough for a cooperative working relationship.
What Should a Software Development Company Be Willing to Tell You?
One of the most notable characteristics of a proficient development partner is the ability to tell the client the truth, even if the client doesn't want to hear it.
For example, the customer may demand a function that doesn't support the business purpose.
The architecture can be too intricate for its purpose.
The deadline appearing in the request can be unrealistic.
The technology specified in the requirements can be incompatible with the demands.
A total rebuild can be avoided.
The experienced engineering company should be able to indicate those problem areas instead of accepting all requests from the client.
After making use of the above 30 years of combined software engineering experience and completing 500+ projects, our position at KernDev is clear: good software work starts with good decisions, not simply more development hours.
That principle affects how our engineers approach discovery, architecture, UX, testing, deployment, and post-launch support.
A client should feel comfortable asking:
"If this were your company, what would you do?"
That question can reveal more than a sales presentation.
The Questions That Reveal a Real Technology Partner
Conduct a review of the answers after a conversation with a development company and bypass evaluating the presentation.
You must be capable of understanding the following:
- Who will build the system
- Why the proposed architecture fits the requirements
- How requirements will be validated
- How the project will be priced
- What is included and excluded
- How changes will be handled
- Who owns the resulting work
- How security will be managed
- How testing will be performed
- How progress will be reported
- What happens when something goes wrong
- Who supports the application after launch
It is advisable to think before signing if any answers are not clear.
A well-designed website, good-looking portfolio, and a low price will not make up for unclear accountability.
The most effective development partnership is the one in which both sides know what they are building, the reason behind it, who is responsible for the parts, how they will track progress, and what to do in case the execution does not go according to the project.
This is the standard we pursue at KernDev.
We are an American software development company that helps startups, midsize companies, corporations, and government institutions by providing them with engineering talent.
We cover software development, application development, UX, cloud technologies, quality assurance, security, CRM, rest API, and databases.
But the most important question is: How do you know whether the company you are interviewing will still be accountable after you sign the contract?
For that, you should carefully analyze the contracts, the milestones, the technical ownership of the project, the commitment to support, and the people responsible for building your product.
The Ultimate Queries to Consider Before Signing Your Contract
Searching for a Software Development Company shouldn't be limited to finding a team with coding capabilities. Before signing the contract, you must have enough information to evaluate whether that company would ensure budget security, protect rights, provide documentation for its work, deal with technical risks, assist in application maintenance post-launch, and take responsibility in case the project becomes more complicated than anticipated. The last meeting should help you achieve one goal: if something goes wrong six months from now, will this company have the people, processes, documentation, and responsibility needed to help you fix it?
A client should come out of the last meeting with an understanding of:
- What will be delivered
- Who will deliver it
- How milestones will be measured
- How payment will work
- What happens when requirements change
- Who owns the work
- How technical decisions are documented
- How security and testing are handled
- How the system will be maintained
- How the company will support future development
These questions become especially important for organizations whose software directly affects customers, employees, revenue, compliance, or internal operations.
A proposal may be considered thorough, but significant responsibilities might remain ambiguous.
A question to pose to the party is:
"Can you show me exactly what the contract says we will receive?"
A proposal should help in understanding the deliverables.
Deliverables may include the following:
- Software functionality
- UI designs
- Source code
- Database structures
- APIs
- Documentation
- Testing
- Deployment
- Cloud configuration
- Training
- Knowledge transfer
- Warranty or post-launch support
It is equally important to evaluate what is excluded from the project and deliveries.
Knowing what is not covered is extremely important because miscommunication is possible when different points of view are present.
For instance, the customer might be led to think that deliveries include deployment, monitoring, training, and production if those points were discussed during sales negotiations, while the developer may think about them as separate tasks.
Both parties lose in this situation.
In KernDev Company, we are very particular about documentation and make sure everything is clearly defined and outlined before the process starts.
A milestone needs to represent something that can be evaluated.
You should be curious: "What exactly will help determine that a milestone has been achieved?"
A poor example of a milestone would be:
"Backend development has been completed."
It does not tell the client the actual deliverable.
A good milestone would specify a certain business capability, for instance:
"Customer registration, authentication, role permission, profile administration, and the related testing conducted and ready for acceptance by the client."
The second definition provides both parties with the evaluation criteria.
You need to ask what occurs at the moment of a milestone approval. Additionally, you need to ask:
"What will happen if I refuse to approve the milestone"?
The agreement should state how feedback will be given, how defects are corrected, and how acceptance is documented.
This protects a client from being forced to approve unfinished work.
It protects the development team from constantly changing project tasks.
How Will You Document Technical Decisions?
It is common practice to overlook the importance of documentation throughout the software development process since so much emphasis is being placed on the implementation of functionalities. Nevertheless, this can lead to some serious issues later on.
One question that should be asked is, "What documentation will be received once the project is finished?" There are some examples of good documentation, including:
- System architecture
- Database structure
- API documentation
- Deployment procedures
- Environment information
- Configuration details
- User permissions
- Technical dependencies
- Testing information
- Operational procedures
- Known limitations
- Maintenance instructions
Having documentation becomes vital when the client company recruits an internal technology team afterward. Moreover, it mitigates dependence on certain specialists.
KernDev finds technical and functional documentation integral parts of its delivery approach. We also offer knowledge transfer so that the client can comprehend how the system works.
What Database Questions Should You Ask?
After many years of loading information into the application, changing the database
typically becomes one of the hardest parts of the project.
Ask: "What made you decide on this particular database layout?"
There should be a good answer other than its popularity.
The right option will depend on the data structure of the application, its transactions and reporting, how it requires reading and writing data, availability, integrations, and estimated workload.
KernDev's database development team will use SQL technologies such as PostgreSQL, MySQL, and Microsoft SQL Server as well as NoSQL technologies such as MongoDB, Redis, and Firebase.
Our Database Development Services address database architecture, development, data management, and performance requirements according to the application's needs.
Ask how the database will behave as the business grows
Be sure to ask how the database will react to the growth of your company. A good question is: "What will happen to this database when we have ten times more data?"
It does not mean the database development team is going to predict the exact amount of future workload.
This implies that the architecture must provide for anticipated growth in a rational manner. The next questions you should ask include:
- Indexing
- Query performance
- Data relationships
- Backup procedures
- Recovery
- Replication where appropriate
- Data retention
- Access control
- Monitoring
- Migration procedures
A database issue seen when dealing with hundreds of millions of records can be much more difficult to handle than a design issue uncovered in the planning.
Do We Need a Full Product or an MVP First?
A number of startup creators think that the product must have all the required features before defining it.
However, that can cost them a lot without knowing whether customers want new technology.
Ask: "What features are truly necessary to test the business concept?"
With an MVP, a startup can get a chance to validate the main value proposition of their product.
KernDev provides MVP Development Services for startups and innovation-led initiatives where early validation can reduce unnecessary development work.
Nevertheless, a product with an MVP does not mean that the software shall be of lower quality.
Reducing scope does not equate to lowering engineering standards.
Take, for instance, a marketplace that includes the following:
- User registration
- Seller profiles
- Product listings
- Search
- Messaging
- Payments
- Reviews
- Recommendation features
- Advanced analytics
- Loyalty programs
- Multiple administrative tools
The first version of the app would not necessarily include all of the above features.
The first version of the app would be able to demonstrate that buyers and sellers can complete their transactions.
That decision can save development time while producing useful information about user behavior.
In answering this question, a firm should understand that:
To clarify this question, ask the development company: "What features will you discard from the first version of the app and why?"
A professional company is able to understand the difference between:
- Features required for the core workflow
- Features required for compliance
- Features required for security
- Features that improve usability
- Features that can wait
- Features that should be validated before development
If the company automatically agrees with all your ideas, it may harm your budget.
Can You Build for Enterprise Requirements?
Making engineering choices for an enterprise platform differs widely compared to a small application.
Companies that have large data sets, complexity in permissions, and multiple integrations and have very high compliance requirements should be constantly asking themselves:
"How would you design this differently for enterprise use?"
Enterprise architecture could include a need for appropriate design so that issues related to role-based access, audits, participation in operations, disaster recovery, performance testing, and other elements of architecture are addressed appropriately.
KernDev collaborates with companies in several fields such as healthcare, finance, education, government, and others.
When companies are searching for a web development company for enterprise, they should not just think about the look of their future application but ask about:
- Identity and access management
- Department-level permissions
- Auditability
- Integration architecture
- Data governance
- Monitoring
- Business continuity
- Disaster recovery
- Performance under load
- Deployment controls
- Environment separation
The company should be able to explain these subjects without hiding behind technical terminology.
How Do You Handle CRM Requirements?
A company can have a working CRM but struggle with disunited systems, redundancy of records, manual updates of information, deficiencies in reporting, and processes that are inconsistent with the practices of the company.
Ask:
"Do we need to replace our CRM, customize it, integrate it, or build something specific?"
The answer arises from the company's workflow.
A company shouldn't suggest a custom solution just because it is capable of developing software.
A company also shouldn't apply a ready-made solution to a situation when custom software is a must.
KernDev's CRM Development Services cover custom CRM platforms, integrations, customer data management, sales pipelines, workflow automation, reporting, role-based access, and application-to-application data synchronization.
An effective CRM evaluation needs to analyze how the information passes through the organization.
For instance, when a lead is generated from a website, it is then qualified by the marketing department. The sales department is then assigned the lead for follow-up.
The steps are as follows:
A lead is created.
An inquiry is made.
The marketing team qualifies the lead.
The sales department follows up.
A proposal is presented.
The client agrees.
Executives set up an account.
Operations begin the delivery.
Customer gains support services.
If every division keeps its own records, the company may spend several hours fixing data that should have been received automatically.
Instead of asking "Can you design the CRM for us?", one should ask a question of a more practical nature:
"Where does our current customer workflow break, and what should the software change?"
What Should You Ask About Public-Sector Software?
Government and educational initiatives might impose requirements that differ from those of commercial software. Companies involved in public activities may require procurement, accessibility, security measures, documents, reports, integration with previously running systems, and unflinching governance.
Questions:
"What knowledge do you have regarding technology requirements in the public sector?"
KernDev operates as a SLED Public Sector Engineering & Delivery Partner for state, local government, and education environments.
A public-sector client should learn about:
- Procurement requirements
- Security controls
- Accessibility
- Data handling
- System integration
- Documentation
- Testing
- Deployment procedures
- Support
- Knowledge transfer
The right engineering approach should emphasize the environment where the organization operates instead of treating public initiatives as regular commercial applications.
Can You Provide Client References?
References are a great source of information, but it is best to ask more clever questions. Instead of asking, "Do you have references?" say instead, "May I talk to a client who had work similar to mine?"
In case the answer is positive, don't be shy to ask the reference the following questions:
- Was the project delivered close to the agreed schedule?
- Did the scope change?
- How did the company handle disagreements?
- Was communication consistent?
- Did the technical team understand the business?
- How did the company respond to defects?
- What happened after launch?
- Would you hire the company again?
- What would you have clarified before signing?
The last question, however, should be treated specially.
If a client answers with something like, "I wish we had defined X earlier," such information can help you significantly improve your contract.
What Warning Signs Should Make You Pause?
Some warning signs are clear.
Other signs can seem appealing during the sales process.
Keep your eyes open if a company:
Guarantees you a fixed price before the requirements are known.
A quote without proper discovery can be untrue.
Has only salespeople doing technical discussions.
At some point, you must meet people who can talk about architecture, requirements, testing, security, and delivery.
Does not let you know who will be building the system.
It is important to know who will be doing the work.
Considers QA something to be done just before release.
Testing should continue during the entire project based on its risks and requirements.
Cannot specify source code ownership.
Ownership has to be specified in the contract.
Lacks a clear procedure for requests for changes.
A lack of control over scope changes may lead to conflicts regarding money and timing.
Can not describe post-launch support.
Once the software is launched, it requires upkeep.
Utilizes technical language instead of providing a proper response.
An efficient engineer should be able to explain technical matters in terms that business managers are able to comprehend.
Pushing you to sign documents right away.
A large investment in software needs to be properly considered.
What Should You Ask Yourself After the Final Meeting?
There exists another criterion that is frequently ignored
Instead of merely asking the question if the organization won your respect, ask:
"Did I grasp what they communicated to me?"
You should be able to explain the solution in plain language.
You should know the cause of the recommendation for the solution.
You should know the people who work on that project.
You should realize the relationship between the project modifications and expenses.
You should know the consequences of a milestone delay.
You should know the right of ownership over the created product.
You should know how the solution will be validated.
You should know who provides services after the solution is installed.
If you cannot answer those questions, be sure that you have insufficient information to sign the prepared application.
A Second KernDev Experience: When a Client Needed Answers Before Code
Our team recently encountered a client who presented us with a well-defined business objective but an unclear technical scheme. The company desired to consolidate multiple isolated operating processes with one application, and at first, it believed our developers would get down to work at once.
The task appeared uncomplicated at first.
The client had a very clear list of requirements for us: a unified database, centralized access to the information by various users, reporting options, workflow automation, and connectivity with already existing systems.
However, during our analysis, we learned that the problem is bigger than just creating an application.
Many departments interpreted even such basic data as customers differently.
The reporting unit was responsible for manual extraction of data.
Some employees had access rights much broader than required by their work tasks.
Many existing applications stored redundant data.
The client also assumed that our app would allow for future expansion into other sectors.
Our engineers were not rushing into development, as they were busy designing the data workflow instead.
Step two is taking note of the Technical Plan
Put forth the question:
How will my requirements be verified before development?
Next step is:
Which architecture would be the most suitable in this case and the reason for such ideas?
Explain this with a link between technical solutions and business goals.
Step three is getting a grasp of the pricing.
Make inquiries about:
What are the elements of the offer?
The next question would be:
How will the making of modifications be billed?
Questions to find out about the costs apart from the development charge.
Step four is getting to know the Ownership.
Ask:
Who has the ownership of both source code and project gains?
The second question should be:
What documentation will I be given, and what about knowledge transfer?
It is better to find the answers sooner rather than afterward in case of clashes. For the fifth step, know the Quality.
Posing the question:
What are the testing options of the software?
The next question is:
What should be done in case of an issue?
Reliable information will outline the testing process and responsibility for its correction.
Stage six: Ensure Security is taken care of
Ask:
In what way will you safeguard our system?
Then ask:
Who will have access to our production?
The answer must be precise.
Stage seven: The relationship after the launch
Ask:
Who will support the application post-launch?
Then:
How are modifications made in the future?
Software products are never truly finished; it is always necessary to make updates after the final version has been released.
Your organization will continue evolving.
Users will want improvements.
Some external services will change.
Security requirements will change.
The application may need more power than anticipated.
Make sure that the firm you choose can talk about these aspects.
The Difference Between a Vendor and a Technology Partner
A vendor may concentrate on carrying out the task given direction on the subject.
A technology partner must challenge assumptions that might cause a negative impact on the project.
This differentiation can influence your budget, schedule, quality of the software,
and partnership with the development team.
If you say
"We require this function."
The vendor may make estimates.
However, an experienced engineering team usually asks
"What problem does this function solve?"
Such a question doesn't mean to resist.
It means to analyze the case.
It is possible that the function you require is necessary.
It is also possible that the same problem can be solved more easily.
Or the function turns out to be dependent on other systems.
It creates a security threat.
People don't need it for some time.
A better decision is a decision based on good reasoning behind the requirement, which is why at KernDev we start all the projects with business assessment and technical discovery.
What a Strong Development Company Should Leave You With
When you reach a decision, you should have no confusion at all about the project.
Some things you need to know are:
The problem: what the software will actually resolve.
The users: who will be using it and what their needs are.
The requirements: what needs to be present in the first release.
The architecture: how the key components interact with one another.
The team: who is accountable for providing the service.
The schedule: what milestones are there and how to assess progress.
The budget: what the price includes and what is beyond it.
The ownership: who owns the software.
The quality process: how problems and quality issues are detected.
The security process: how access and sensitive data will be protected.
The support plan: who is responsible for support after releasing the software.
In case the company fails to clarify these points, you should keep asking questions before making your mind.
Why KernDev Takes a Different Approach to the First Conversation
At KernDev, we view the first discussion less as a race towards a quotation and more as an opportunity to understand the challenges faced by the business.
We examine the requirements.
We check the processes.
We consider technical feasibility.
We analyze dependencies.
We choose the architecture.
We assess the risks.
We clarify what to build first.
After that, we create a plan of delivery based on real requirements.
At KernDev, our teams work with startups, mid-market companies, global corporations, and public authorities in fields like financial services, HealthTech, e-commerce, and logistics.
We also have a one-month period for our clients to try out our services without any obligations.
The agreement shows an essential belief:
The client should be able to assess the experience from the actual
service rendered, rather than solely relying on verbal assurances given at the sales meeting.
The Questions Matter More Than the Sales Presentation
A relevant company for development will not be the one that has the longest list of technologies or the lowest bid.
Explore the company whose position is justifiable.
Ask why a particular architecture is chosen.
Ask who implements this software application.
Ask what can go wrong.
Ask what will happen if demands change.
Ask who owns this work.
Ask how they secure the product.
Ask how testing is performed.
Ask what happens after going live with your project.
Ask what the company would take out of the prototype if there were limitations on budget.
Ask what it would do in a different way if it were its own project.
These answers are what reveal the attitude of the company.
Our practice of completing more than 500 projects in KernDev proves that it is not hard to develop software because of the team's lack of ability to write code. The challenge is to make the right decisions before, during, and after coding.
The type of development cooperation is expected to provide more than a simple application.
It has to provide your organization with a clear technical vision, clear ownership, documented architectures, clear communication, controlled expenses, and a team that is accountable for anything that happens outside the original description.
That is the evaluation of buyers' questions for the question, "Which Software Development Company should we hire?"
A better question is:
"Which team presents the confidence that I can trust them to handle the business issue behind the software?"
This is the question that must be answered before signing the contract.
Share this Post
Blog Categories
No categories assigned to this post.