My small custom software development agency
5 min read

My small custom software development agency

I want Dev to Agency to be a place where software developers who are interested in starting a software development agency (or have already), can learn from some practical examples around how I started, ran, and ultimately sold my agency after 8 successful years.

Perhaps I am secretly writing this for my younger self, as this something I found hard to find good information on when starting out in 2012.

To get slightly side-tracked for a second, I kind of hate the word "agency". I prefer to call my business a "software development consultancy", but that was really me just not liking the word agency. At the end of we did client service work for businesses and individuals - and that's an agency. That is kind of not related to this post - but I just wanted to get it off my chest. Now let's move on.

An "agency" can take many different forms, on one end of the spectrum we might have a 150 employee full-service digital agency offering everything from communication and branding, web development, to SEO optimisation, and then  on the other end of the spectrum we may have one single person who does "Wordpress" (that is, they configure various plugins) - so I want to give an overview of the software development agency I built, so you can then ascertain if these words can benefit you.

I feel compelled to write this post as I don't want to be misconstrued as someone who can "Turn your small software agency into a billion dollar money printing making business in 14-days!" - that's very much not me, and very much the type of content I was wary of when starting out. Instead I want to talk about the key-values and strengths that I focused on at my agency - values which I believe helped my business succeed.

1. Small

My natural instinct is to be small and stay lean. These traits are not mutually exclusive, however to me they are cornerstones of the business I built. On average we were 5 people, this number went up and down, but for the majority of years it was 5 people - all full-stack software developers, and in the later years one dedicated account & project manager. Small can mean a lot of things, but to me it means the entire team working closely together, and as a leader - having time to truely understand and support each team member on each individual level. Compared to larger businesses, a reduced monthly payroll can allow you to only take projects that play to your strengths, and having a smaller number of staff to pay - may actually mean you can pay higher wages than the industry standard. Being small helped stay lean, and thinking lean helped zoom in and ignore things that are extraneous or unneeded. This can mean not spending money on the new shiny SaaS tools of the month, and it can mean working out of a small(er) shared space, as opposed to a large office that perhaps could seem more impressive to clients. Whilst I have no experience building a large agency with many teams and departments, I do have experience building a small cross-functional team, producing high output at high quality.

2. Custom software

My business did not build websites or software you could buy or download off-the-shelf, but we created tailor-made software - designed, architected, developed and deployed to meet the exact needs of the client. Possible categories of custom software include business-to-business software for businesses to sell on to other businesses (B2B), business-to-consumer software for a business to sell to the general public (B2C) - and another category is internal software, that is software that the businesses need to run themselves internally. It's the last category (internal software) that interested me the most, as all businesses end up with complex processes and workflows that are in need of automation, and they don't need to be billion dollar businesses to realise a small improvement to the process can return large results. I use the term "boring businesses" to describe my ideal client, and where this type of software can work well. For example, a 30-year family owned company called "H&R Widgets" that make and deliver "widgets" for other boring businesses. You would never hear of or notice this company in your day-to-day life, but they can be making millions per year in profit, and using a highly manual internal process using hundreds of paper based forms, shared spreadsheets with many macros and flaky integrations the owners cousin built in "VB script" in 1997. This is a perfect client.

3. Long-term client relationships

I feel it is a misconception that most important step in building custom software is the software itself (the end result) - where I feel it is instead really understanding the business and the specific problem area the solution is addressing. Without a strong understanding of the problem and business goals, you risk wasting time, money, and reputation building the wrong thing. These client relationships need to  be built on a foundation of "a partner in problem solving" rather than just "a vendor that will deliver the new widget workflow software". This starts before the project begins, and continues long past the project is delivered. Being a partner and not just a vendor allows you to understand other areas of the business, which will often lead to further conversations and opportunities. After you have delivered a bespoke solution for a client, no-one else on earth knows this exact software better than your team. Even though thorough documentation is paramount for training and up-skilling new hires - this fact puts your business in a good position, and whilst you should not take advantage of this responsibility - it does mean that it's in the best interest of "H&R Widgets" to keep a good ongoing relationship with you also.

4. Quality

As the custom software is integral to the client's business - it cannot just "go down" every couple of weeks, and as the technical partner & problem solver it is your responsibility to ensure the checks and balances in place for high quality in all areas. Quality in all areas starts with making sure you have a thorough understanding of the business and the problem area to guarantee the quality of the project goals, that the software you write is high-quality and built to last to ensure quality of the code, and that the project management and delivery processes that you put in place (including user testing and sign-off) are clearly understood and formalised - to ensure the overall project quality. All of these points are hard in their own way, but as you are building relationships and software that will be sticking with you for the long term, by not focusing on quality, you are shooting yourself in the foot by paving a tough road ahead. Over the 8 years I ran my agency our quality was the most common praise we received from clients, and often amazement that a small team can produce such results.

5. Staff happiness

Small can also be hard, people are not replaceable without losing a lot of knowledge, and working on custom software often requires deep understanding of complex business rules. I'm confident that if my staff had of left after just one or two years, then I would have really struggled to keep my business running - and could not have achieved the same level of success. There is always the random "Bus Factor" that needs to be taken into account (a team member being hit by a bus), but otherwise I believe the main focus should be on happiness of employees and making certain they are getting everything they need to be as happy as they can be at work. For me this meant building a very close team, a team that had fun, but a team that worked hard. Staff that understand the values of your business, and understand that in a small team they will have a large impact. It's not always glamorous working on projects for boring businesses, but the happiness and purpose does not need to come from the project itself - but from creating great code with teammates, always learning, and knowing you are not on your own - that people will always have your back when you need it.

This post covers a lot of points I plan on digging deeper into in the future, unpacking each of these points in more detail and some more examples. If this is something that interests you simply subscribe below, and you will recieve all new posts by email.

Enjoying these posts? Subscribe for more