Working with a development partner is a long-term decision with huge consequences for your business. Choosing the right partner can help you reach your goals faster and ensure you have a significant competitive advantage. On the other hand‚ working with the wrong partner can cause numerous headaches‚ incur unnecessary costs and grind your business to a halt.
To help you identify and evaluate which partner is right for you‚ we’ve put together a list of the common questions we get asked repeatedly by potential clients‚ alongside some of the questions we would ask if the shoe was on the other foot.
(Feel free to put us through our paces and grill our team on everything below).
The common questions we get asked
How can I protect my idea? Should we sign a non-disclosure agreement?
Understandably the majority of people we speak to want to protect confidential and proprietary information.
Before discussions begin‚ most developers should be comfortable signing a mutual NDA which protects both parties during discussions‚ even if you ultimately don’t decide to work together.
How long does development take? How much will it cost?
This is a difficult question to answer in any detail before a full specification has been developed.
It’s very much dependent on both the complexity of the project‚ the speed at which any supplementary assets (third-party designs‚ copy etc.) can be provided.
It can also be impacted by the quality of any third-party data sources or integrations‚ such as APIs. If these are not well documented or fragile‚ that can add to the build time.
We typically provide development estimates after our Discovery process (see below for further detail on what this entails).
You should always be mindful of a developer that gives an estimate too quickly. They either have not understood the project or are putting so much margin on the project that they simply can’t lose. A better way to gauge this may be to ask for a range of costs and dates‚ allowing the developer to explain the factors around this.
Do I own the intellectual property once the work is completed?
If you are a startup‚ the IP is likely your primary asset and how you will leverage any subsequent raises. Ideally‚ you should have full ownership of all intellectual property after development and upon full payment of the agreed invoice amount.
It is important to check this both verbally in initial discussions and in writing when contracts are signed.
What is your normal technology stack?
When it comes to languages and frameworks‚ there is no “best” stack. Most modern programming languages are well-documented and are able to support an extremely complex feature set. It’s generally considered preferential to build in an established development framework such as Laravel‚ .Net and Vue.JS.
To learn more about our Laravel Development‚ learn more about our Laravel API Development and Laravel CMS Development Services.
A good health check when selecting your developer is to understand what tech stacks they could build the solution in. This helps you understand how specialised they are and equally indicated they are picking the best tech stack rather than the one they are comfortable with.
However‚ it is important to check that your development partner is able to handle the technical requirements of your project. If you are asking them to build an end to end solution‚ check they have both front-end and back-end expertise.
What is the best way of turning this idea into a feasible business model?
Alongside offering purely technical support‚ it’s vital to find a partner who also understands the commercial aspects of building and enhancing digital platforms.
A good way to gauge this is based on their portfolio and your initial point of contact. Are you dealing with a developer that has a very specific niche or has a diverse portfolio? Are you dealing straight away with a developer or a strategist?
With over 10 years of experience across multiple industries‚ we are able to offer advice and strategic consultancy that extends beyond the technical build. While we don’t charge for this expertise‚ we consider it to be a key part of our value to clients but also a metric on which client we should work with.
What does your fee structure look like?
A developer will likely have one of two fee structures: Fixed price which agrees on all costs and scope upfront or Time and expenses where you pay for the developers as they work.
Fixed price is a good option for those looking to get to market with an idea‚ understanding the cost. Note that compromises on both sides will be made and that you may end up paying more than you should have as the developer needs to budget the risk into their calculations
Time and expenses can be based on hours‚ days or sprints. These are all essentially units of time that continue until the object is met. A fair developer should balance the risk of this by offering more attractive terms to those looking to engage in this model.
What does “Discovery” mean and what are the outputs of this process?
Discovery is the pre-build phase of software development which assesses the core goals and objectives of the platform in order to develop a full technical specification.
Discovery processes can vary wildly between developers and wider agencies‚ which is why it’s important to understand exactly what is included in the process.
For example‚ our Discovery team typically consists of business analysts (BA)‚ user experience designers (UX) and user interface designers (UI). Over a four to six week period‚ they work closely with clients to produce:
- Product Requirements Document
- User Personas
- Competitor Analysis
- Process Maps
- User Stories
- Admin Specification and Notifications Document (if applicable)
- Functional Specification
- User Acceptance Testing Plan
- Wireframes and concept designs‚ which lead to full designs
The additional questions you should ask
These are the questions we get asked much less frequently‚ but the questions we would ask if we were engaging with a developer!
How many customers do you have?
If a developer is busy‚ that’s usually a good sign of their expertise and ability to deliver. A quiet developer that can take on projects immediately might have no work on for good reason.
You should also ask for client references and reviews. We generally point people in the direction of our Clutch page‚ as this contains detailed reviews from multiple clients that have been independently verified by a third-party.
Who would be working on this project? What does your usual team structure look like?
While you may not be able to get a concrete answer in the early stages‚ this question is a great way of scoping out what your working relationship might look like and the different skills and knowledge you will have access to throughout the project lifecycle.
It’s also worth asking who your day-to-day point of contact will be‚ e.g. whether this is an Account Manager or Project Manager‚ and how frequently you should expect to receive project updates.
A good tip here is to think about how you will manage the relationship.
What is the development partner expecting from you? How often will you be able to engage? Do you need to assign someone to help with the day-to-day management on the project?
Do I get a copy of the code and how will I access this?
We believe that all clients should have complete access and ownership of their codebase after project completion. You’ve paid for it.
However‚ be mindful that there may be good reasons why an agency may restrict this. A warranty period may be affected if another party can damage the codebase or may affect how well the developer can perform on-going maintenance and support.
A good compromise is to ask for regular backups‚ this allows you to own your asset and allows the developer to protect their own processes in your best interests. Again‚ this is important to clarify both verbally during initial discussions and contractually before any work is undertaken.
How do you take on an existing codebase?
Developers should always be wary of taking on another person’s work. You wouldn’t ask a builder to quote for finishing a house before they had seen the work done before. The same should be true of development.
It’s always useful to get an understanding of how their process works from the offset and what is required at each stage‚ both in terms of commercial agreements and access to assets such as existing codebases.
hedgehog lab operates a policy of code review prior to any contract being in place. This is in both parties interests‚ we all want to ensure that any objectives set are achievable.
Do you outsource any of your work to other developers and would this be the case on any aspect of our project?
While outsourcing isn’t necessarily an issue‚ it’s important to clarify whether your project will be worked on directly by the development partner you are speaking to‚ or outsourced to a third-party.
What is your process for managing out of scope work and overrunning schedules?
This is linked to discussions around costs‚ estimates and what will be included in the Discovery and build phases.
Ideally‚ you want to understand how the development partner will ensure both parties are on the same page when it comes to deciding whether the work is within or outside the project scope. hedgehog lab advises setting a delivery window rather than a date‚ the expectation should be somewhere in the middle.
Understandably business requirements or critical changes can occur during projects‚ e.g. changes in regulation. It’s important to understand the process for accommodating these changes and how these changes will be priced.
We’d also advise that clients avoid the delivery date as business-critical. Don’t set you big first marketing spend for the next day after delivery‚ anything could happen. Give yourself room to breathe‚ seeing the platform in a live environment and then capitalising on a well-executed plan.
Do you do any security or penetration testing before release?
With the increasing importance of cybersecurity and compliance‚ it’s vital to understand the process for identifying security weaknesses and stress-testing the system before it is deployed.
A thorough penetration testing process will mimic the techniques used by hackers without causing damage. These tests help you ensure compliance with regulations such as the PCI DSS (Payment Card Industry Data Security Standard) or the EU GDPR (General Data Protection Regulation).
Note that this may not always be necessary‚ work with your agency to understand their limits‚ avoid them marking their own homework and understand how this affects your project. Remember‚ you can never remove all risk from a project and it’s your responsibility to balance this.
What’s included in a fixed-price specification?
If Discovery is being offered at a fixed price‚ understand the scope of this process and what the outcomes will be.
From the development side‚ you need to understand how bugs will be dealt with‚ whether the price includes QA and testing.
If your budget can’t cover an exhaustive process‚ it’s reasonable to drop certain elements and scale back the final deliverables. Ultimately you get what you pay for‚ but getting a decent MVP build over an all-singing all-dancing solution might get you where you’re going.
What are my on-going support options? What is the cost of maintenance and support?
You should consider two aspects of support.
Firstly there is the resource required to ensure the software is correctly maintained and updated. This on-going work is proactive and can be planned in advance.
If you require maintenance support‚ ask how maintenance is scheduled‚ what the on-going costs will be and how this is charged for (e.g. hourly).
The second type of support is the reactive type which comes into play when you raise a support request as the result of a bug or issue on the platform. This support should be outlined in a Service-Level Agreement (SLA).
What does your SLA cover?
Linked to the question above‚ it’s vital to discuss what is included as part of the SLA and how bugs are categorised and dealt with. For example‚ when it comes to platform critical bugs (e.g. server failure)‚ is there minimum response time and is support available 24/7?
What is the warranty period‚ what does this include?
Most developers include a warranty period as standard.
It’s important to understand what this actually covers and when the warranty comes into effect. For example‚ if you delay your app launch due to marketing delays‚ does your warranty kick-in when you’re ready to launch or when the app is completed by the developer?
Will I be able to see time reports?
If you’re entering into a time and estimates based contract‚ you should feel empowered to ask for assurances on how this is going to be utilised and whether you can see a breakdown of how your hours are spent.
A developer not doing this is either not logging their time or not sharing it. Neither is a good answer.
How would you work alongside an existing development team?
An external development team should look to complement your existing process as much as possible‚ but be mindful that they have had access to a lot of different styles of working. Take recommendation onboard and assess them critically‚ it may be that they can enhance your own internal processes.
It is equally important to remember that the agency will always need internal time to manage the project. This is in everyone’s interests‚ as you want developers coding as much as possible. Project management should look to coordinate responses and questions effectively ensuring they get the best out of their team.
How do you manage testing and QA before release? What is your process for this?
A business with its own internal QA function should be in a good position to test the outputs of an external provider. This is a great way of benchmarking third parties against your own team. Be clear on the responsibility here and who should be managing each aspect of the process.
Equally‚ if you are wholly reliant on external QA ensure that you understand the criteria they are testing against. Most agencies will provide a user acceptance test (UAT) criteria that explains when a project is deemed complete.
Want to put us to the test and chat through these questions with a member of our team?
Get in touch now via email or phone for a no-obligation discussion about your requirements
