This article is a follow-up of How to build a product as a non-tech founder, so you can check that out too!
For the untrained eye, software development might look like a very exotic ritual. Most of the time, it seems like nothing’s really happening.
From the client’s point of view, questions like “When is this going to be ready?”, “Why is this taking so long?” and “How much is this going to cost?” never seem to have a satisfactory answer.
At HackSoft, our day-to-day job is to build software, but what we actually sell to our clients is adequacy and competency.
That’s why we want to shine a light on the entire process & explain what’s actually happening, when you want to build a software product. From the initial conversation to the end result.
Hopefully, we’ll address common misconceptions and make the process more clear.
A high-level overview of the process can be described in a couple of phases:
We’ll dive deeper into each of those phases.
A client reaches out to us. That client wants a piece of software to be developed.
Here is where the journey begins.
Usually, the first thing that the client sends is a set of requirements for the desired software.
Alongside those requirements, there are the usual questions about:
At this point, we cannot give any meaningful estimate either on time or price.
We cannot give meaningful estimates for one simple reason - requirements are never enough.
The final product will look almost nothing like what’s described in the initial requirements. And that’s OK. That’s part of the process.
At this point, we try to ask simple questions like:
Those questions will give us a better understanding of the actual needs, but still, it’s not going to be enough.
So how do we proceed?
The next step usually is to talk about designs & wireframes.
Designs & wireframes are a must-have for any project. And we are not talking about high-fidelity designs - we are talking about the minimum amount of visuals that outlines what the product is going to be about.
If we have designs and/or wireframes with the initial requirements - this can greatly help us understand what the client actually needs.
If not, then, creating some form of designs and/or wireframes are going to be part of the discovery phase.
And before we start talking about the discovery phase, we need to figure out if we can work together or not.
During our initial assessment, we try to figure out if we are a good fit for our client.
We look for 3 key things:
If we pass the vibe check, the discovery phase is what usually follows.
We send an offer for a discovery phase, with few simple, but important goals:
At the end of the discovery phase, we usually have:
The good thing about the discovery phase is that the end result is universal.
The client is not locked with us, can take the learnings & proceed with a different software development partner.
Now that we have a better understanding of what the client needs, we are in a position to make an offer about the development.
There are plenty of options to structure the process and usually, there are negotiations taking place.
If everything goes well - we are ready to start the actual software development.
This is where the fun begins.
We are now in a position to start active development. The first couple of days are all about setup and establishment.
If we haven’t done that in one of the previous steps, we do this with the highest priority.
Our preferred communication channel is Slack.
Once the communication channel is established, we start communicating daily and that’s important.
We don’t want to stay silent for the majority of the time. We also don’t want to just send an email report at the end of each week.
Communication is key.
We’ll communicate what’s happening, ask questions and discuss priorities on a daily basis.
This is where we establish the core tools that we use.
Things like:
All of this is to help us do our job better, to keep track of progress & to visualize everything that needs to be visualized.
There are projects & cases, where more tools are required. We have the expertise to figure this out.
A product running in a local development environment is of no use for the client.
That’s why one of our first priorities is to establish a staging / test environment. The goals here are simple:
This way, the client can actually use the product and return meaningful feedback.
In some cases, we even do a production environment right away, so we can give the users the features they want.
The quicker we get to production, the better. End users are the oxygen for all software.
Usually our clients are quite pleased with the process & they want things to get fixed or shipped quickly. If we can release everything this week, it’d be great!
That’s why, aside from doing the actual software development, we have 3 additional key responsibilities:
It’s a delicate dance between us & the client.
If we do our job right, work will flow smoothly. If we don’t - we assess & adjust.
From here on - it’s a non-stop iteration of agreeing on priorities, development, feedback, adjustment.
Once rhythm is established, trust will be the next to follow. And if we manage to establish trust, great results will be achieved.
You can read more about the concept of rhythm here.
During the initial phase, we often ask our clients what a “best case scenario” looks like for them.
This is a great question & reveals a lot.
So if we ask ourselves that same question - “What’s the best case scenario when starting a new project?”, the answer would be:
Given our best case scenario, we can start delivering on day 1.
Of course, in the real world, this is not so easy to achieve. That’s why we have the process outlined above.
If you find this interesting and want to chat more, hit me up on LinkedIn or send an email to radorado@hacksoft.io