In my work as a software engineer I have to evaluate lots of projects before I start work on any. Clients’ main concern is how much it will cost them for our team to implement their ideas and this is entirely normal. They want to know exactly what they will receive and when so they can plan accordingly and find the resources necessary. At Camplight we often find out that clients actually don’t always know what they want or are not transparent enough in sharing their plans and expectations. This is why I always ask a set of questions to make sure we are on the same page and are a good match for each other.
- Can you describe your idea in elevator pitch format?
- What is your business model?
- In what category does your project fall into – start up, proof of concept, MVP, SAAS, redesign, rewrite, etc?
- What are the functionalities you want implemented first? What can you go without?
- If you can choose 2 out of 3 from – ‘good’, ‘fast’ and ‘cheap’ – which would you choose?
- Do you have any requirements or preferences regarding the technology stack being used for your project? Can you elaborate more on that?
- Tell us more about your team and your partners for this project. Who are we going to communicate and work with? Who is going to be the decision maker?
- Do you have an approximate budget? Who are your investors?
- What is your project’s deadline and start date? Can you describe the project’s stages and timeline?
- Who are your competitors? Can you show us similar products that you think are doing it right?
Of course those are general questions and may vary between projects. However if you don’t have an answer to some of these questions then you might not be ready to speak with developers just yet and ask for a price. We are here to help you figure it out so no worries!
But why even go for a ‘fixed price’? In my experience almost no project (except for those that are really simple) can be properly evaluated and there are always changes, design switches, decisions taken in the course of work, unexpected bugs, business logic changes, market research changes, etc – all of that adds time and money on top of projects. This is why we always prefer having transparent and honest relations with clients and bill them for the actual work done using a time tracking platform like Toggl. This agile way of doing work allows both sides to have managed expectations and offers a more precise evaluation of the amount of work that can be done in the next development sprint. On the other end where we have fixed scope, budget and timeline we tend to end up in situations where time and money has run out and there are more things to do on the project or at least ‘polish’ it and remove any technical debt we might have accumulated. Basically we start throwing blame at each other and waste valuable time arguing over features and changes instead of doing what we should – a great software product.
So what is the recommended solution here? Of course clients want to know at least a price range for our services. And this is exactly what we give them – a best/worst case scenario estimate plus our hourly rate. But, and this is a big BUT, we always make sure we are on the same page and everyone knows exactly what they are going to receive and when. This is actually the only way to ensure everyone is be happy and do business honestly.
I would like to leave you with some food for thought – as is with love so is with business – the fact that you can take on a project does not mean this is the right project for you to take on. Be very selective with your clients and clients – be very selective with who you hire to do work on your business because as is with love feelings get hurt if expectations are not aligned.
My questions are something along the lines of:
0. Have you validated your idea?
1. what’s your go-to-market strategy with this tech product?
2. What’s your general use case? Your most important feature…
3. Who’re your target customers with this product?
4. What’s the market cap?
5. What’s the barrier to entry for competition? What’s your competition?
6. Are you aware of what infrastructure do you need?
7. What relevant domain experience does the team have?
8. What risks can you foresee?
9. What problem the product is solving and is it worthy?
10. Do you have a roadmap