You’ve got this idea for an app, or maybe it’s a web platform, but you aren’t techy. You’re not a developer and you know you need to work with one to make your idea come to life. Working with a developer is a big investment, it’s time consuming and very often it is not cheap! Making sure you go into the development stage of building your startup prepared means you’ll get maximum value for minimum cost. In order to make the process much smoother I’ve come up with a list of the 6 questions you need to have answered before you spend a penny with a developer.
Who is your user?
Your users are going to be the ones that use what the developer is creating at the end of the day. A clear picture of who they are, what motivates them and what’s holding them back will set you up for success. This knowledge means you’ll be able to design and develop a product that they really want. All groups of people have quirks and you want to focus on designing a product that really speaks to them specifically.
When you start working with a developer without knowing who your users are going to be, there’s a big chance that the product you’re creating will have to be reworked (guess what reworking means… more £££)
What is your budget for the build?
On the subject of money, before you speak to a developer you need to figure out how much you can realistically afford to pay them. It’s hard to say how much building a product will cost, but knowing your budget will change who you approach to do the work. Frequently working with a freelancer is cheaper than working with an agency for example. The other side to consider is that the more things your users can do on your product, the more it will cost to build. So if you’ve got a smaller budget, it might mean that you can’t build everything you want right away.
What’s your longer term budget?
Sorry to be the bearer of bad news but the cost of technology doesn’t stop once your development stops. Making your product available to your users costs money and to keep it available also costs money. Figuring out how much you can afford monthly might change what you create as adding different features to your product will cost different amounts. Top tip: Once you start talking to a developer, make sure you ask them about their predictions for long-term costs.
What exactly do you want to build? What is the dream situation?
Everything your user can do on your product is called a feature. You need this long list of features for two reasons: Firstly you’ll get clear on exactly what you want your product to be. Secondly a developer will be able to understand step by step exactly what you are asking them to do. Use a list of dream features as a conversation starter. Another reason you need crystal clear clarity is that different developers build different types of products. So for example if you know you want an app built, you know you need to specifically find an app developer, it’s a waste of time to speak to a developer who can’t build what you want built.
Have you drawn a version of your product?
Ok maybe this sounds a little silly to get out the pen and paper and draw out your idea, but this actually counts as a prototype! The process of drawing out your product will help you answer exactly what you want to build. It will help you dig into the details of your idea. You will also probably want to get a professional involved to design your product. Unfortunately this is another cost, but it’s needed. Developers are also usually not designers and this is commonly where I see projects fall down, because they can do a lot of jazzy things, but they are hard to use because a designer wasn’t involved. If you approach a developer without a visual, the likelihood of there being misunderstandings of what should be built is greater.
Why are you building this project?
Are you building a quick and dirty version so that you can get it out and in front of customers to get some feedback fast? Or are you going big bang, building the whole thing? Why this version of the product? Answering why you are building now will allow you to focus on what features to build and how much money you put into it. You’ll also be able to plan for how you’ll determine if this product is a success or not. Understanding the motivations behind the specific version you want to build will help you answer all the other questions.
Your answers to these questions are all intertwined. They all work in tandem, what you want built and why you are building it will inform your budget. In turn your budget will also inform what you actually end up having built.
These aren’t questions that are easy to answer. There will always be tradeoffs and the Product Management Triangle can help us to understand these.. It says that there are three key points, good, cheap and fast. Your build can be two of these things, but never all three. That means you’ll be in one of these situations:
Good + cheap = You won’t see the outcome for a while.
If we’re in this camp, we ease it by making sure we invest heavily in planning up front so that our plans don’t have to change, which slows things down even more.
Good + fast = Be prepared to part with some cash.
Here, in order to bring the costs down you’ll need to have a crystal clear plan about what you want, and use that to have open conversations about ways your developer might suggest making it cheaper.
Cheap + fast = It’s not going to be the best quality.
You can mitigate this by working through all the intricacies of your product before working with a developer. Small uncertainties and lack of plans early on make projects very messy and rapidly reduce the quality.
Do you see a theme? The upfront planning is the way to mitigate those tradeoffs, and move you towards an amazing product as fast and cheaply as possible.
If I could leave you with one thing, it’s that having a clear answer to all of those questions is the best way to set your tech build up for success. Having answers to these questions means you can confidently begin building a product that your users want and will grow your business.
Where you can find me:
About your author
Sophie is a two time founder, CTO & Software Developer. She is currently building Techniclarity which develops female founders by teaching them just enough tech to lead a startup to success. She is working towards closing the gender gap in entrepreneurship and in technology and believes education is the way to do that. Check out her work as a developer at sophieheb.com and her work with Techniclarity at techniclarity.co. You can also start your own journey to level up in tech by following her on Instagram.
Our founder Lara Sheldrake has been interviewing a range of founders and community experts for our ‘Community 101’ Clubhouse series and here are a few of our key takeaways…
First of all, let me start this post by acknowledging how much of a dirty word ‘sales’ is. Most of us associate sales with sleazy, pushy suit-and-tie people trying to scam innocent customers of their money
Every week we co-host a Clubhouse room called ‘Collaboration Studio’ with Julie Fedele, Founder of Two Feet In and Phoebe Dodds, founder of Buro 155 and Live Wellby. This week we talked all things procrastination, what it is and how to beat it.