[gharman]

I founded, grew, and sold a boutique software services co. Here's the skinny:

* The core revenue model is charge customers a certain amount for doing work, and to have a lower internal cost. (duh)

* Typically you're looking for a 30% margin or thereabouts; after cost of sales, consultant bench time (yeah you gotta pay that even when folks are idle, if they're employees), etc. you have maybe a 10% profit margin when you're at decent utilization.

* Hourly and fixed bid are the primary structures - and I've seen plenty of both. This is simply a question of who will take on the risk of overrun. If it's the services shop (i.e. fixed bid), then they pay for that additional risk by padding the price above their best hourly estimate (that padding is what pays for the services if it does overrun, and is the reward for taking the risk if it finishes on time).

* You can lower hourly costs and increase predictability on your resources (an endearing term for employees/people) by hiring them full time, but you take on the risk of paying them for bench time (when you don't have a contract for them, they still get paid). You can avoid this risk for higher hourly rates by using subcontractors. A good practice is to keep a "bench" of folks in your primary areas of expertise and to supplement with subcontractors for speciality tasks.

* Ongoing maintenance revenue - maybe, maybe not. Wise customers will want to learn how to maintain their own software and include training as part of the contract - or even embed their resources in the team. This isn't quite like sales of a big enterprise software platform in that regard.

* A better long-term practice is to utilize the "foot in the door" to spread out and find other, new work within that customer's organization. Of course existing projects will continue as long as there's a need and the customer is happy, but I don't see a lot of "maintenance" contracts per se.

[edanm]

I also founded, grew and sold a boutique software services co., and am now running a new one.

I agree with all of the above.

The only major note I'd add is: some of the above really depends on who your clients are.

For example, we work with mostly technical customers, taking on things that are not their core strength. But only customers who already have internal dev teams. The way we phrase is internally is "we want our deliverable to be a git repo, and only work with clients who know what to do with that".

This implies a bunch of stuff - for example, ongoing server maintenance etc. is seldom a problem, since our clients already have their own devops teams.

Other dev shops can target the other way - non technical clients, for whom the dev shop becomes their entire technical staff. Those contracts are often quite different, and just to continue with the example above, often will include some kind of ongoing devops work (which may be more of a profit generator than the actual project itself!).

[mipmap04]

I've started doing this as well too. I don't want to be someone's hosting provider or CSP. Too many headaches and building the thing is a lot more fun than watching it run and making sure you've in compliance with the 1000 governance documents the company has regarding production environments. There are a lot of good companies that already provide purely that service and, to your point, many companies have those teams already.

[oneelectron]

I also founded, grew, but have not yet sold a boutique software services co.

I see on your profile you sold to a client. We have had that option before but the multiple on our earnings was too low to actually consider it. Curious what your revenue/earnings multiple was on the acquisition. Also curious about the handcuff terms. Giving up autonomy over my daily life is hard to swallow without 8 figures.

[edanm]

I can't get into exact details. It was a fairly typical multiple, a bit higher than normal after some negotiation. That's smaller than a startup, obviously, as there was no IP, just a team. However, since we were bootstrapped, all of the money went to us, none to investors.

It ended up being fairly profitable to sell, though we were by no means dependent on this - we could have just as easily continued and possibly gotten more money in the long run by not selling (with a greater risk, of course).

[tixocloud]

How do you get started with a custom dev shop? What type of technical companies would you focus on?

[edanm]

Depends on the field. We tend to try to offer complimentary services - e.g. if you do web, typical clients might be companies that do embedded, and need a web UI. Or who do mobile usually but now need some web expertise, etc. Or who focus on building security products, and now need a web interface to them.

Basically, try to find companies who are technical, but are missing the skill your company can provide, and then provide that.

[pmiller2]

Funny you should mention that 30% number. That seems to be a kind of magic number where, for gross margins below that, you probably don't have a viable (small) business, in general.

For example, I've had discussions with people in one of my hobbies about this. It's a collecting hobby, so, being involved on the dealer side consists of obtaining inventory, marketing it to collectors, and selling for a profit. I've been told that you should always have at least a 30% gross margin on inventory, unless it's stuff you want to blow out because it's been sitting too long. In practice, what this means is you buy at somewhere between 60-75% of retail, normally (you can afford a smaller margin when you already have a client lined up to buy the exact thing you have, but that's not the typical case for a lot of dealers).

[aconsult1]

I run a successful software consulting company and failed miserably when tried to sell it about 3 years ago. Can you share any insights on how that process worked out for you? Any tips on how to find potential buyers?

[mooreds]

> Ongoing maintenance revenue - maybe, maybe not. Wise customers will want to learn how to maintain their own software and include training as part of the contract - or even embed their resources in the team. This isn't quite like sales of a big enterprise software platform in that regard.

I've seen several services businesses seek scalable, recurring revenue. Depending on what you deliver, hosting is a great one, as long as you have employees with the skillset and willing to have a pager.

Productized consulting is one I've read about but not yet seen delivered.

[HeyLaughingBoy]

I'm with an engineering services co and we just started getting into Web work: until now we've primarily done embedded systems and mobile apps.

How did you typically manage the server/ops end? i.e., do you turn that over to the client and say "here are all the credentials, SaaS licenses and everything you need to run this, good luck" or did you offer Operations & server management as part of your package?

It's something I'm not finding good information on from the web. Real-world insight would be helpful, if you can.

[qz2]

Been 15 years since I did this myself. Got fed up with trying to get people to pay their bills.

Trick is to keep your costs as low as possible and charge them as much as possible for the privilege. I'd probably throw it all at AWS, probably Elastic Beanstalk now and charge them whatever that is plus 30% with a minimum retainer amount. If they want it handed over, there's an exit and handover fee and an ongoing support contract that needs to be set up.

[01100011]

At my old company we handed it to the client. I don't think any of our clients would have wanted to pay our rates to maintain the servers for them.

[rovr138]

In a past job, we'd do the same.

As part of completing, there's a transfer phase. Usually we move everything to their in house/managed servers unless we built it there. In that case, we'd make sure that they disable logins and lock down our accesses.

Regarding OP's question about license and accounts, we'd usually build things with their accesses and keys. It's easier that way.

Regarding small clients, if we took them on there was probably something else in the relationship so we might have kept hosting it for them.

[HeyLaughingBoy]

> Regarding OP's question about license and accounts, we'd usually build things with their accesses and keys. It's easier that way.

Good to hear that. It's what we've done so far (transitioning from our own keys, etc. as the project gets closer to finished). It has sometimes been difficult with non-technical clients to, e.g., walk them through the process of getting their own certificates.

When we're integrating with a client who has their own engineering staff, it's pretty much a non-issue.

[krab]

In my experience, it is usually passed to the client with some training. Often, the client wants to order the servers and any saas by himself, you only specify what to order or you get an account within their cloud provider.

[aeyes]

For many years I worked at a random big corp software development company. Hosting & Ops is where the big profits rolled in, usually with sweet long term contracts.

I certainly would recommend looking into providing this service. Why would you turn down guaranteed monthly paychecks? Also, you wrote the software so you will be the most competent in operating it.

[alexdowad]

> 30% margin

I know of firms which hire offshore programmers for $15/hr and bill the client $90/hr. (500% margin!) Of course, it helps if the client has plenty of money.

[willnz]

Unless this is true staff augmentation it NEVER works out to that sort of margin. Overhead creeps in if you want to grow (and you want the quality to be maintained).

I'm guessing an established firm that hires and bills at those rates would end up having 40-50% margin at the end of the day.

[xwdv]

Is that 10% profit margin per project? What is the yearly profit margin for a software dev firm?

[gharman]

It’s percent of revenue over whatever period of time you care to measure it.