How we build software

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.

Overview

A high-level overview of the process can be described in a couple of phases:

1. Understand what the client actually needs.
   • Requirements are never enough
   • Designs and wireframes
2. Agree if we can work together or not.
3. Discovery phase.
4. Decide if we can work together or not.
5. Start the software development process.
   • Establish a communication channel.
   • Establish core work tools.
   • Establish staging / test environment.
   • Establish rhythm & trust.

We’ll dive deeper into each of those phases.

Understand what the client actually needs.

A client reaches out to us. That client wants a piece of software to be developed.

Here is where the journey begins.

Requirements are never enough

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:

1. Estimate on time - How long will it take?
2. Estimate on price - How much will it cost?

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:

1. Why do you want to build this?
2. Why do you want to build it now?
3. Who are the users of the product?
4. What’s the most important feature / set of features for your product?
5. Aside from you, who are the stakeholders?
6. Do you have a specific deadline in mind?
7. Do you have a specific budget to work with?

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 and 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.

Agree 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:

1. Do we have the technology expertise for this particular problem?
2. Does the client budget match some rough ranges on our end?
3. Do we feel like we can stick to our values, while working with the client?

If we pass the vibe check, the discovery phase is what usually follows.

Discovery phase

We send an offer for a discovery phase, with few simple, but important goals:

1. Given 2 weeks.
2. We are going to iterate through requirements, wireframes & designs.
3. And actively communicate with the client.
4. In order to figure out what the real needs & priorities are.
5. And what the work at hand is going to be.

At the end of the discovery phase, we usually have:

1. A better structured requirements / documentation with technical details.
2. Diagrams.
3. Wireframes and/or some basic designs.
4. In some cases - a proof of concept for a particular feature.

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.

Decide if we can work together or not.

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.

Start the software development process.

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.

Establish a communication channel

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.

Establish core work tools

This is where we establish the core tools that we use.

Things like:

1. A place to keep the code (for example - GitHub, GitLab, Bitbucket)
2. A place to keep the wireframes and designs (for example - Figma, InVision, Adobe XD)
3. A place to keep the documentation / written knowledge (for example - Whimsical, Google Docs, Notion, Confluence)
4. A place to keep the visual diagrams (for example - Whimsical, Diagrams.net)
5. A place to keep the tasks / work at hand (for example - Trello, Jira, ClickUp)

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.

Establish staging / test environment.

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:

1. Deploy daily so everything new is there.
2. Give access to the client.

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.

Establish rhythm & trust

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:

1. Properly communicate priorities with the client and the development team.
2. Negotiate on what can be done and when it can be released.
3. Push back, if needed.

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.

A best case scenario

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:

1. The client gives us an initial credit of trust, right from the start.
2. So we can start working on the product, right from the start.
3. While agreeing on budget and timeline.

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