Why is it so difficult to scale a software house, and what can you do about it

A software house is a very common type of business in my part of the world. It is a company employing engineers to work on software products, and sells the IP created in its entirety (or almost) to the customer. In Poland these are usually small to medium operations (5 to 300 employees). They keep their hiring bar pretty high, salaries are decent, and they tend to focus on things like the higher-end aspects of web/mobile, Digital Signal Processing, or Deep Learning. So, we are not talking about big outsourcing centers, hiring thousands of people (these are also interesting, but not something I know a lot about).

I’ve been interested in software houses for a long time. I’ve observed how my friends went into this business, and how their companies grew. 10clouds, Rebased — I remember them when they could still fit their whole teams around one restaurant table. Netguru started a bit earlier, so when I met them it was 2 or 3 tables. Tooploox — they were still a product company when I met them in the Bay Area. Finally, in early 2017 I joined MicroscopeIT as CTO/co-founder. I drove its reincarnation as a consulting company specializing in AI and Computer Vision (the name is still a dead giveaway of the company’s product origins), and built the team from 3 engineers to 20. I’ve spent a lot of time thinking about strategy for this sort of company.

Photo by Kamil Gliwiński on Unsplash
A software house is a great way for engineers and other technically minded people to start building a real company, especially in capital starved parts of the world like Central and Eastern Europe (Poland, Romania, Ukraine, Bulgaria…). However, the most common business model is flawed, and imposes serious constraints on growth — especially when you want a more valuable company, not just one employing more engineers. I have a few ideas about what can be done about that.

Origin stories
The software houses I know most of came to life mainly in 2 ways. The first is what I call The Merry Devs of Sherwood, the second is We Used to Be a Startup.

The Merry Devs of Sherwood
If you are a freelancing programmer who is good at her job, you can have the good life. The money is great, you can take a holiday almost whenever you feel like it. If you don’t like your project, you can easily find a different job.

There are downsides too, though. Depending on how good is your customer’s contractor game, you may end up working with great people, or with a sad bunch of idiots. The latter is a downer, so in order to avoid it you can bring your friends to work on your contracts. This is wonderful news for the customer, as finding good developers is hard. A strong developer vouching for another dev is usually a very strong indicator of quality.

With time it becomes clear that someone in the team has a knack for finding new gigs, talking to customers, and organizing work, all things which a lot of engineers despise. Soon there’s more work than the initial team can handle, so they hire new people. A software house is born. The founders are usually great engineers, and hiring is easy because they know how to make devs happy.

Photo by Sergei Akulich on Unsplash
We Used to Be a Startup
You are a startup founder with a technical background. You have an idea, maybe a little bit of seed investment money. You start building a great technical team, and work frantically on your product. However, with time it becomes more and more clear to you that maybe your product-market fit isn’t ideal. You are not getting the traction you hoped for. Your runway becomes shorter and shorter. Soon, you get little panic attacks thinking of your bank account.

But then, a little miracle happens. You meet someone who maybe doesn’t want to buy your product, but they’d love for you to build something for them. And pay you sweet, cold cash. This is not an ideal scenario — you were supposed to be doing something else. But it beats going broke and having to let go this amazing team you built. You take the contract, and the customer is happy. Unlike many other contractors, you “get it.” After all you were trying to build your own product just a moment ago, so you are great at prioritizing. Then another contract follows, and another. You are not building your product at all, but then, on the other hand, you are not desperate anymore. Being cash flow positive, and this matters a great deal. Maybe you keep doing some vestigial work on your original idea, but now it’s more a PR thing, as you’ll always take billable hours if available.

My guesstimate is that there’s more Merry Bands than We Used To Be A Startups. Both types of software house have their stronger sides, at least initially. We Used to Be a Startup may have stronger product skills, while the Merry Devs of Sherwood may be slightly better at engineering and project management. However, with time both types of organizations end up well rounded, and this initial preference ends up being just part of the company’s history.

Economics of a software house
Central and Eastern Europe is a hub for software houses. There’s no shortage of technical talent (in Poland universities may suck at research, but they are amazing at producing well rounded engineers). What Poland desperately lacks, however, is easy access to capital. Even if getting access to VC money is becoming easier (and London and Berlin are very close to Warsaw), you still need to spend a few months working on the project to get to the point where a reputable VC will reply to your emails. The proverbial “friends, fools, and family” that would fund a startup during that time are much more risk averse and strapped for cash than in Western Europe or the US — so it sometimes never happens.

On the other hand, a software house, unlike a product startup, needs almost zero working capital. You don’t need an office, a coffee shop will do. Everyone brings their own computer. You pay people when the customer pays you. Everyone (the owner included) is hired as independent contractors, so you if you run into a contract glut you can just close the operation.

During the crucial bootstrapping period you are afforded a surprisingly carefree financial existence.

An typical thing in a software house is that most (or all contracts) are Time & Materials. This is important, as estimating how long a software project will take is very hard (and even worse if you do R&D). What is more, if you are doing agile (as you should!), the requirements are constantly changing — and the overhead of having to constantly adjust the price would be horrible. So, T&M significantly reduces the risk for the developer.

However, T&M also creates the biggest problem with running a software house: it’s really hard to scale. Like any agency business, at its core you are selling people’s time to a customer (with the code being a useful artifact). There’s only a set number of hours in the day. So, if you grow from 10 to 20 developers, you can double your revenue, at most. Actually, worse than that, because every employee carries an overhead. With 20 employees, you need to spend some energy on managing them. This doesn’t mean you have to hire a manager — you can as well try to empower your current employees to take on more responsibilities — but whatever you do, time spent managing an organization is not time spent building stuff for your customers. Your revenue will be growing sublinearly with respect to your number of employees.

So, employee salaries, which in a product company are an operational cost, in a software house are the main contributor to your COGS (cost of goods sold) and will be the key influence on your gross margins. Not realizing that is a common source of mistakes of people with a product background coming to an agency (this was a mistake I made initially). For example, in a product company, hiring the best, most amazing programmers is a no brainer. You are in a race to bring a product to market, and if you have to pay people double to win — so be it. In a software house, you will make your customers very happy, but it will not move the needle when it comes to your revenue. In fact, it may hurt it— your team will finish more quickly, resulting in less billable hours.

What is more, with more people on board a lot of things that used to be easy start being hard. Maintaining a consistently high bar for new hires? It comes natural when you are 5 people, requires a lot of thinking at 20 people. Low operational costs? Hey, but you don’t want to be working in a coffee shop forever. You actually crave that nice office, with fast Internet and a kitchenette full of fancy soda. Independent contractors? Sorry, it turns out most people prefer to receive a regular salary.

The latter is especially dangerous, as it can throw you into the dreaded wet-season/dry season cycle. You are selling people’s time, so the hours you cannot bill become, essentially, your inventory, and has a cost. If you have more people than contracts (dry season) your profits disappear. If you have more contracts than people, you are leaving money on the table, and the customer gets annoyed (they are not getting their product fast enough!). To make things worse, hiring is a process with a lot of momentum, it takes time to find good people and onboard them. You are always either dying of thirst, or drowning.

Scaling ideas
Here’s some ideas on how to scale a software house. However, they are no silver bullets — all of them involve some risk and are not without serious drawbacks. Some of them aren’t even good ideas..

Not really scaling: higher hourly prices
This list gets off a bumpy start: a really awful idea for scaling. However, it’s not an obviously bad idea (I fell into this trap myself), and that makes it dangerous. So, let’s get it out of the way quickly.

The fallacy goes like this:

By hiring incredibly smart people, who are capable of great feats of engineering in difficult specializations, we’ll be able to command really high prices for a premium service. Our revenue will still linearly depend on the number of employees, but that won’t matter that much, because our gross margins will be high enough.

Why is this a trap? Very high margins make you a target for your competitors, your customer, and… well, technical progress.

Other software houses will notice you have great margins, and try to copy your business, but offering slightly lower prices.

Second, from your customer’s point of view a substitute for your services is a team of their own. They have to pay for finding and hiring those people, and their salaries. And actually, they can play your game and try to hire people in your market, directly. It’s going to take them a nontrivial amount of work, yes, but it will allow them to decrease their costs, and increase their own value by getting the IP generating talent in-house.

Third, there’s a strong trend for commoditizing important technologies, especially if they are complementary to a big player’s core business (see what Joel Spolsky wrote about it in 2002). In 2010 web development was hard and rather annoying, and thus lucrative. The skill to write an interesting JS app without a complexity that would melt your brain was rare. These days, with React and Angular it’s mostly a solved problem. A similar process is taking place right in front of our eyes, with Deep Learning, except at a higher pace. Things that 3 years ago took a week of hard work in TensorFlow are now a beginner tutorial in Keras, taking just a handful of lines of code.

By the way, not everyone needs the premium service — most software work is pretty standard. If you specialize too much, not only your potential market will be significantly smaller, but you’ll also have a much harder time getting to those customers who actually need your services.

Switch to fixed price contracts
This one is really scary, and goes against the custom. Negotiating such a contract is much harder, and the stakes are higher. If you mess up on the estimation, you may end up losing money on a contract, which is virtually impossible with T&M.

However, a fixed price has some significant benefits, and you should consider it.

First, stop deluding yourself that there’s no estimation necessary in a T&M contract — it’s just that you make it someone else’s problem. After all, the client needs to budget for the project! What is more, if a client needs a software house, in most cases engineering is not part of their core competency. This means that, as a company, you are throwing away one of your important comparative advantages — after all, you are supposed to be good at building software.

Second, a fixed price allows you to actually innovate to grow your margins. Your cost is a function of the time you spend developing the product. Remember those amazing engineers that you hired? If they are actually amazing, they will find a way to get it done faster. Are your people agile fanatics? This can help you manage the risk of delays. Are your devs great at test driven development? Fantastic, you’ll have less defects to deal with. In a T&M contract, hiring the best people will at most boost your reputation. In a fixed price situation having those people will directly increase your profits.

Third, a fixed price contract destroys a perverse incentive baked into T&M. Your customer really, really wants the product to be ready as quickly as possible. They are investing a lot of money into it, after all. The more quickly that happens the better. You shouldn’t get a rewarded for busywork, and you shouldn’t be penalized for doing the right thing and delivering quickly.

Stay small
Yeah, I feel awkward for proposing “don’t scale” as an idea here. However, growth for the sake of growth is rarely worth it. If your company is 5 people, you can keep running it like a pirate ship. Everyone is a partner, everyone is a great engineer. You don’t have to worry about cash flow that much, and you’ll probably keep being able to coding. And if you manage to establish a reputation you’ll have plenty of money. Rates for companies are customarily higher than for individuals, and here you won’t be giving anyone a cut of it.

Photo by Ricky Kharawala on Unsplash

Do a product
If you realize that people keep asking you to work on the same thing over and over, that may be the indication that there’s a market that it’s not being appropriately served. After all, people are paying you a lot of money to make a custom version just for them. You built it several times, so you have a decent idea on how to make it work. And if you have a product, you are escaping the service company hell, and your payroll is merely an operational cost again.

Pulling this off is not trivial, however. First, the price point for the product will be much lower than of the bespoke version (for which you give all the IP to the client). You’ll need significantly more customers, and that may require a very different marketing strategy than what you’ve been doing as a service company. You should also prepare for a lower revenue for a few quarters, so better have a rainy day fund.

For a more in-depth discussion of this strategy and some case studies, I recommend The Customer-Funded Business.

Conclusion
A software house requires a very low capital investment, making it a great business idea for countries that are capital starved yet have plenty of technical talent. However, T&M pricing makes scaling a software house a total pain in the neck. I proposed a few ideas, of which switching to a fixed price model is one I think has most potential.

Judul Situs

Why is it so difficult to scale a software house, and what can you do about it

Tinggalkan komentar Batalkan balasan

Why is it so difficult to scale a software house, and what can you do about it

Bagikan ini:

Tinggalkan komentar Batalkan balasan