How I build software for clients

In this post, I want to describe my software development process for small and medium-sized projects. I hope this helps people who want to start their own agencies.

I'm convinced that building software is deeply linked to interpersonal interaction and communication because the goal of building software is always to solve a problem for the client. Without a deep understanding of the problem, you can't build a fitting solution. This is my personal approach for a specific type of projects and is not meant to be seen as a one size fits all because that doesn't exist.

This approach is not suitable for big projects. In those projects, we use agile methods and sprints that last for 2 weeks each. But the focus on clear communication and leading your clients through a strict process of tackling problems and developing solutions remains the same.

It always follows this structure:

1. First Meeting: Understanding the client
2. Problem analysis: Brainstorming solutions
3. Second Meeting: Present possible solutions and let the client decide
4. Technical analysis: Search for possible problems and edge cases
5. Third Meeting: Talk about technical challenges and inform the client about different solutions
6. Prototyping: Build a first prototype
7. Feedback: Demonstrate it and gather new information
8. Build the product: Now, the final solution can be built
9. Testing, delivery and maintenance

First Meeting

At the first meeting, the problem is laid out by the client. Most of the time the clients don't know what the best solution for them is or how it could look like, but they definitely know what pain points they have with their current solution. So the first step is to listen.
It can be a very emotional conversation if the problem is a major one for the client, so the software engineer in mind should stop thinking about technical solutions and focus on those emotions. Understanding what causes this mood in the current solution is the best way to identify improvements.
Good consulting is providing a service and not only a technical solution - the problem being solved should be seen in this context.

The next thing should be to echo the pain points and describe the current process and how things work today to make sure that you share the same mindscape. If the client responds in a negative way, ask for clarification. You have to be sure to understand the problem on a superficial level after the first talk so you're able to vaguely define the scope and complexity of the project.

Problem analysis

Now back in the office I sketch out the problem, define abstract concepts, and creatively think about the problem, in short: brainstorm. It's not possible or reasonable to think about data structures and business logic at this point. It only matters that you've got a good picture of the problem and try to think out of the box to solve the pain points that you've extracted in the first talk.
Prefer the easiest solution and think about ways to reduce this specific problem to already solved problems, but don't get trapped in details at this point.

Second Meeting

Show your ideas that you've brainstormed. They don't have to be elaborate or complex (although they should not be completely out of touch with the problem being solved), but it will show the client that you've thought about the problem and are motivated to solve it in creative ways. This talk is also very good to motivate the client to think about possible solutions, although they should not think about implementation details - e.g. they've heard about Angular and insist on it despite the fact that they haven't communicated it as a requirement and don't really know what it is - the focus should be shifted towards problem-solving, not towards engineering.

If the problem is well-defined, prepare a list of possible solutions and what advantages and disadvantages they have. List all possible solutions with a small description and pros and cons and finish with a conclusion that favors a specific solution in a reasonable way.
Most of the time a CEO doesn't care about the details, they have a problem with some requirements, a deadline, and a budget (also known as the project management triangle). Giving them a simple and effective way to make a decision is part of the consulting service.

Technical analysis

After I've found a common ground with the client, the first diagrams can be drawn and the use cases can be defined. In this step it is essential to understand the problem profoundly because the technical analysis should find edge cases that the client is not aware of e.g. do their employees have IDs that identify them without ambiguity or can two guys named "Jon Snow" with the same birthday cause a problem?
Write down any problems that could occur and assess their relevance and contact with reality. Some problems are just theoretically relevant but can come up at later stages of the product. Try to list all possible solutions for these problems and their advantages and disadvantages - this is relevant for the third talk. Colloquial language is preferred so there is no terminology barrier. I've seen it too many times that computer scientists use words in a normal conversation that their dialog partner doesn't and simply can't know. This doesn't help the customer and should be discouraged.

If there is data provided by the client, make sure that everything is clearly structured and there are no inconsistencies. If an error happens here, this can multiply the time efforts of the project.

Third Meeting

In this meeting, you're the one who's mainly talking and asking questions. Describe all problems using colloquial language and sketch solutions. The important part is that the client has to choose which solutions for those technical obstacles should be preferred and he should be well-informed about the trade-offs. This is important if you ever encounter a problem due to technical limitations of the chosen solution in the future, so make sure that you've explained all the disadvantages in great detail - communication is important to seed understanding of every step for both sides.

Silent implicit expectations can be real conflict points in the future, so use this last talk before any code gets written to make sure that there are no hidden hopes and "obviousnesses", especially how a certain feature behaves in detail. It's not always one's own fault, but you will be blamed because people are not as rational and objective as desired, so it's in your interest to minimize and eliminate those hidden conflict detonators.

Prototyping

Now it's time to build a small prototype that shouldn't get confused with an MVP (minimum viable product). You can build some interactions that outline how the users or the client can interact and solve their business problems.

In order to minimize confusion, try to use the design specification if the corporate design of the client-defined UI elements without investing too much time styling the prototype. This prototype is important to further verify that you've understood the problem and have a working solution in a PoC-manner.

Feedback

Demonstrate the prototype. Most of the prototype should be nothing more than a click dummy, so be sure to fill the demonstration with vivid verbal explanations of what would happen in the final product.

Don't get caught up in the details and make sure that the client is not pedantically searching for inconsistencies in the prototype and explain the purpose of the demonstration.

At this point, the client decides if he likes the solution that was chosen in the first conversations, so it's important to listen to criticism carefully. The good thing about building a prototype is that your pride can't be offended, because you've not given 100% yet - getting emotional due to criticism is unprofessional, but unfortunately not too uncommon, so it can be good to have this bumper first.
From a professional perspective, this prototype can be compared to a mockup used in architecture or other fields of engineering and is possibly the best way to show the final product without wasting resources.

Build the product

Now it's time to git init and start the project. I don't want to tell you too much here, because this is big enough for a bunch of other blog posts and people far smarter than me already talked extensively about this topic. — tl;dr there are software engineering techniques that can and should be applied for professional software development.

The important part is that you get feedback for every iteration, regardless of the used method e.g. agile, waterfall, etc. and use this feedback. Unit tests and building reusable components and following best practices and taking security into account is taken for granted and should be accounted for in the budget because they take time without getting visible features for the client.

Testing the final product

Give the client the product with a guide that explains any interaction and elements (e.g. using screenshots) and demonstrate the software and the features. This can be seen as the final handover. If all expectations are met, both parties will be happy.
Due to time constraints and budget limits, there'll be definitely bugs in it, so calculate some time for the warranty and explain to the client that the bug fixing time is normal, and reassure that you'll handle all incoming bugs in the first weeks or months.
After this time you can negotiate to support them with a price tag.