Ask HN: How do custom software dev firms make money?

Pretty much.

There's also often a clause giving the company rights to use bits of the software in future projects (but not to sell them standalone.) That way future projects can be much faster to develop, there's a lot of overlap in these things.

Yes, you are right.

There is no fixed model to this but largely what you said is what the standard is!

Some upfront cost is always taken from the customer before starting the project and then paid in full once project is delivered.

Post that it depends what customer wants. They can keep paying you to maintain it regularly and fix bugs. Also you can charge them for some additional feature development. (This is called account expansion revenue in business terms.)

There are two common cost structures: estimated time and fixed bid.

Fixed bid is relatively simple: company says project will cost X dollars, and takes on the risk of that amount ending up being too low. As a consequence, these projects tend to be very rigid; if a client wants any changes made to the plan or outcome, typically that involves another charge (unless certain revisions were allowed for up front).

Estimated cost is just that- firm offers a guesstimate of the total project cost, but only actually charges for the total number of human-hours worked. These contracts can be a bit more flexible- sales may tweak the hourly rate to keep clients happy, changes can be incorporated if the client is willing to sign off on a new estimate, etc.

One newer and slightly less common variation during initial development is capacity based- again, a very rough outline for project timeline may be put together up front (businesses like plans) but the company bills a flat rate to provide hours per week, rather than progress towards a dedicated plan. This allows for a more "agile" workflow, and is also happens to be a common arrangement for maintenance phases where a client may choose whether to add new features or work out existing kinks without needing to sign a new agreement for every little feature. It offers the most flexibility for clients while also putting most of the risk on them as the development shop hasnt agreed to any specific outcomes.

Disclaimer, I’m not sales. And I’m not completely sure if this is the scenario you had in mind.

There were different types of revenue streams.

First are open projects for multiple companies to apply for, convince the clients they are the best party for x amount of money. These project’s are large, and requires also quite a bit of investments for the company competing for the project.

These are usually fixed price fixed scope projects. After finishing the project there often are several other contract types. ALM application lifecycle management contracts, these are often x amount of hour to per month. To keep the system’s up to date, Fix bugs that pop up and creating uptime reports and such.

Often there’s also an amount of money per month for on call support. The projects need to be kept running 24/7 so if something breaks in the middle of the night someone needs to wake up and try to fix it.

Other types of revenue are teams/individuals for hire. Imagine the customer having a few engineers and the consulting firm supply a few hands. They can be a range of roles, testers, frontend backend, scrum masters depending on the snake oil they company is selling ;).

There is also projects that happen together with FANG. Google and Microsoft are quite notorious for helping companies like mine to our connect with our customers. Helping them while including the latest whistles and bells of there offerings. That is also why many companies value certificates from Microsoft and Google etc. They get discount of cloud pricing, so they get a cut from what they pay for the infrastructure.

On systems that are in maintenance mode there are also some often RFCs (request for change) as larger changes with the system that is in maintenance mode.

Instead of waterfall projects the alternatives is to sell x amount of sprints or design sprints. But in my experience large companies and agile that it doesn’t really works

1) Clients come to you because they have a painpoint and they wand to build something to help it.

2) You discuss with the clients what's their needs.

3) Figure out what you can do and agree with the client on the billing/project. (how many people? of what skills? how long? what to build? for how much?)

4) Do the work. Projects could be anywhere from weeks to years.

5) Long time goes bye.

6) Done.

There's two ways to handle the billing and making money aspect.

First option. Bill per time. You basically promise to have X people of various skillset working on the project for some period of time. They're each billed $$$ per day so it's simple math.

Second option, harder to manage. Bill per project. You basically promise to deliver a bunch of features or some result that's agreed upon at the start. This one is tricky because you have to define everything at the beginning and clients usually don't know what they want and change their mind.

Now, who wants to have a longer blog post about the difference between contracting and tech companies?

I'll add one more that I have run across. It's a revenue/savings share agreement, where the company writing the software gets an X% of the revenue (or savings) generated by the project.

You might get better answers by calling a few firms and asking directly

I think it depends a lot on the companies involved. From what I've seen, things usually fall along a spectrum from "fixed bid" to "time and materials". With the former, the company that wants the software puts together an explanation of what they want and then asks vendors to submit a price. With the latter, the vendor promises to provide X number of people at a rate of $Y for as long as the project goes. In between you'll find a lot of arrangements with various levels of guarantees for what's done when and for how much.

The essential problem is risk. From the client perspective, they don't know what's legitimately hard or how good the devs are. From the vendor perspective, clients never know what they want and may not pay even if you give it to them. And software projects frequently blow up; according to HBR, 1 in 6 have a 200% cost overrun and a 70% schedule overrun. Frequently expected business benefits don't materialize for reasons that are hard to determine. When that happens, neither side wants to be left holding the bag.

This is complicated by the fact that dev firms generally have fixed expenses (salary, rent, overhead) and variable income. They need to get maximum dollars out of every programmer hour if they want to make a profit.

The opaqueness leaves a lot of room for bad behavior on both sides. For example, I heard of one Accenture software project for a company that had a bunch of very fixed deadlines with their customers. Accenture sent in some very smart, senior people who produced a very pretty bid with lots of text and diagrams, and their skilled salespeople sold the work for $5 million. How would it be charged? I forget the exact numbers, bu roughly: the very smart, senior people would be $4k/day, and the junior people would be $2k/day. But Accenture sold them on a "blended rate" where they'd forget about nickel-and-diming the client and just send in the right people at the right times for a mere $3k/day. Of course, Accenture then flooded the project with younglings (who Glassdoor is saying get paid $50-$60k [1] these days). As you might guess, the project then fell behind the initial rosy predictions. Once the client was starting to sweat their hard contractual deadlines, Accenture then said, "Oops, the $5 million is all spent. Nothing works and we're going to go. But if you'd like we'll stay and actually finish it for another $5 million." The client didn't have any choice, so they paid up.

And there's plenty of bad behavior on the client side as well. I've heard of plenty of projects where the client asks for X, and when you deliver X, they say, "Well that's not what we wanted." Which is surely true, in that people often don't ask for the exact thing they end up wanting. So the client suddenly refuses to pay a dime until they get what they do want. For a dev shop that has been paying salaries to a bunch of programmers, that can be anywhere from scary to disastrous, because they're legally obliged to keep paying salaries no matter what the client does.

So I don't think there's a simple answer here. Honestly, the revenue model of some dev shops are things like "underbid and then bleed them out on change fees" or "promise geniuses and then load projects up with the cheapest goofs you can find" or "invest heavily in sales, overpromise wildly, and egregiously overwork your devs" or "underbid on the initial work, produce a snarl of spaghetti code that only your devs can maintain, and overcharge for years of ongoing maintenance".

I've known a number of reasonable, honest, conscientious devs who have tried setting up software development firms. They just wanted to do good work for clients, treat their people decently, and make reasonable profit. All of them have struggled, losing out on deals to people who were much better at gaming the system to make money.

Having been on both the hiring side an...

Here's a different angle for you.

Most of these dev agencies total revenue size is naturally capped at the networks of the founders and referrals from previous clients. I've seen anywhere from $1m - $10m.

Source - people turn to my company to help them grow. General web dev clients find it hard to differentiate enough to cost effectively scale up customer acquisition.

DM me if you want to see the formulas I've worked out that represent the above idea. Not real math, I'm a sales guy haha, just representations of these ideas formatted like a Google sheet formula.

I was a director for digital agencies for a long time. There's no real fixed model for any of it. Like others have said, contract-wise you can bill as fixed fee, time and materials or some hybrid. Customers are more apt to sign a fixed fee, but it's a huge risk to put a fixed scope, budget and timing unless you know exactly what you're doing. Any level of ambiguity could lead to costly overruns and missed expectations.

In terms of what kind of work you do for them, it's up to you to sell whatever you're comfortable with so long as every expectation is explicitly documented in the contract/SOW. Companies can hire technology services to do almost anything up and down the value chain. From strategy and user experience design, marketing, content production, system architecture, development to operations and maintenance. The bottom tier is something like staff augmentation where you just rent out warm bodies to do IT work. The agency model is more like landing a complete self-organizing, product development team who take business objectives and translate them into a working product.

Stuff like operations and maintenance is stuff I would typically avoid because it can be open-ended and difficult to make money doing. I usually stipulate that clients have to own infrastructure even if we do the setup and add some specific warranty language on how long we will answer bug reports, what qualifies as a bug and what kind of turnaround time we'd need to resolve them. Especially at small scale, clients will search for any excuse to drag out their contract to get more work out of you or find a reason to not pay so you need enforceable language.

Doing good work and building trust can lead to future work. You need to toe a line between aggressively managing scope to not get taken advantage of while still staying flexible enough to be seen as a good partner. It's really common for a client to have a big vision and no idea what it costs, so we sell an MVP that does maybe 1/4 of their dreams to get a product to market within their budget, but there's still a lot of meat on the bone for future work. Sometimes it leads to a long relationship and sometimes they just fold.

It's a risky business, but there's also a huge market that only seems to be expanding. If you make a name for yourself and build up a few nice portfolio pieces, clients will come to you after not too long.

Each software development company gets income in different ways. There are companies that develop software for each client individually and their income is the calculated development cost, which includes a large number of factors: the complexity of the project, what specialists were involved, the number of work hours, whether freelance specialists were involved or not, etc. There are companies that develop "tight" specialized software, for example, PMS software for the hospitality industry - https://www.bookingninjas.com/, and sell it at a certain cost to the relevant companies that need it. The option of monthly, annual, or some other subscription can also be used. In addition, many companies add advertisements to their applications (especially often seen in applications for mobile phones). Therefore, this issue is quite complex and extensive. It all depends on many factors.

I tweeted a thread that can be useful on how to deal with enterprise for custom products in the mid six figures ball park that one or two motivated individuals can pull off, contracts, exclusivity, product development, and abstraction[0]. Feel free to ask for more clarifications.

- [0]: https://twitter.com/jugurthahadjar/status/131066829330549965...

To add to other answers, often a business or non-profit will put out a request for proposals (RFP). You read a document or have a meeting to understand what they are trying to accomplish. You then write up a proposal with a budget. They read all the proposals and choose a dev firm to work with.

> the revenue model of custom software dev firms

Taking a cut of the economics of the transaction, just like giant software firms do.

For example, the seller is an HBS grad whose buddy is a PM at Microsoft with permission to pay vendors - the buyer. Seller can't program but he can find young people who can. He knows there's a $400k budget for a Sharepoint search plugin, he pays 3x young people $66k each, pays out $50k in one time deal expenses (legal, kickbacks i.e. "illegal"), and is left with about $150k in profit on that deal. Some of that profit is used to pay back losses on previous projects, so net that year, a $400k project may make about $80k (i.e. 20%) for the seller personally.

Net-of-50, maintenance, etc. - these are just narratives developed for the buyer's processes, to close the sale. You're in school, you should know that the way people come up with names for revenue is a narrative for investors and accountants, it's not a way to talk about economics (models). In this case the buyer has a lot of checkboxes and this shouldn't be conflated with a "model."

Anyway, doesn't scale and that's why custom software dev firms are rarely big.

When you look at stuff that does scale, like Pivotal or Accenture, there's something fishy with their economics. Or it's Red Hat, and they're actually not customizing much at all!

I did this for 13 years. The basics are covered well in this thread already, so I'll just add a couple of points.

The phrases we always used for contracts were "time and materials" versus "fixed price".

We wanted time and materials, which means the client pays us a set rate for each unit of time we work (could be hours, days, sometimes months) plus the cost of any materials we need to do the job (software or SaaS licenses, assets, or special hardware we need for that job). This is a great model for the contractor, but riskier for the client.

Clients always wanted a fixed price. That's when you guess up front how much the whole project will cost. This is obviously riskier for the contractor.

In reality, most contracts we used were kind of a mixture of these. We broke it into sprints, and billed T&M within those sprints. If the client was unhappy with what they were paying for, they had the opportunity every week or two to pull the plug.

The other point I want to bring up is that there's kind of a systematic flaw in how most custom software dev firms make money. I saw the exact same process ruin two different firms.

Let's say you run a custom software dev shop. Every month, you need enough billable hours to pay them, so you find contracts for them to work on. And, at the end of each contract, you need to find the next contract. The problem is that not all your contracts end at the same time, so, you've always got a rotating assortment of employees sitting around waiting for the next project.

Naturally, you've got a pipeline of new contracts, and something always comes up. The problem is, it's almost impossible to consistently find contracts that perfectly match the exact group of people you happen to have sitting around waiting for work.

What most firms do in this situation is hire more people so they can take the contract, which increases their payroll, and requires them to look for an even bigger contract next time. The business model now becomes a riskier and riskier series of bets, as the business balloons.

Meanwhile the quality of employees is dropping, because you just need butts in seats at a faster and faster rate. Your ability to succeed on contracts is put at risk, not to mention your company culture and morale.

Eventually, you either lose a client due to incompetence, or you can't find a big enough contract to meet your expanded monthly nut, and the whole thing topples over.

After living this for over a decade, I came around to the position that custom dev shops can't exist forever. They're unstable systems that will all eventually break apart into smaller custom dev shops, which then recapitulate the same unstable cycle.

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.

One thing to point out is that there are varying degrees of customs. Every client project is custom in the sense that they all have different pics, layouts, colors, et., but the underlying technology may be the same (e.g. Wordpress). The more you can use off the self components and just tweak them, the more predictable a project will be. This type of work tends to be very competitive & you’ll often hear that it’s a race to the bottom. While the quality of Wordpress implementations can vary drastically, it can be difficult for a client to understand those differences, which makes it challenging to sell premium services.

When work is truly custom, and you’re building much of it from scratch (e.g. using Ruby on Rails with extensive amounts of custom design and business logic), this can be much more expensive. It’s quite difficult to find good developers who can help you figure out what you need, come up with a plan that you’re comfortable with, and actually deliver something you’ll be happy with.

One thing not mentioned in many of these threads is using an Uber/Gigster style model where instead of having an internal bench of folks who are FTEs, you keep on a larger bench of contractors who are only paid when they work on a project. There are definitely pros and cons to this approach and I'm happy to dive in depth into them if it's of interest to folks (I was early at Gigster YCS15 and work at a firm, tribeai.com that has a similar model but focused only on ML projects).

But at a high level, this is something to consider if you have a good network of friends/former colleagues who are also solid devs who you can tap for projects to rapidly expand your services offering and capabilities without paying for a bench and taking the risk of having a bunch of people you have to constantly pay

>> “Hey HN, I'm working on a project for school and need to learn a bit more about the revenue model of custom software dev firms.”

I used this trick A LOT in college to get secrets from companies. My friends and I would call some people and tell them we were trying to understand something for a report. It was amazing how much secret information people were willing to share.

One of the most powerful assets you have as a student is that .edu email address.

Buying their employees time at one rate and selling it at a higher one.

It’s that simple.

Most of the questions I see around “how do you start x” seem to be driven from a lack of confidence in ability to sell. That is a learnable skill and, for something as in-demand as custom software dev, it’s not that hard.

Having been in and around that industry for some time now I can tell you that if you can listen to the sales prospect and articulate their need back to them better than they can they’ll assume you can deliver it. Most custom dev shops fail at this simple task and therefore lose out on many easy sales.

Customer has desires which aren't fixable by off-the-shelf solutions OR customer is convinced it isn't fixable by an off-the-shelf solution. Customer is billed for work done either by x * hours or a fixed fee determined upfront (which contains x * hours with a margin for error in giving the estimate of hours upfront). Rinse and repeat.

Most of what I would say has already been covered by other answers.

We billed out Sr devs at around $300/hr. Not sure about normal staff engineers but probably around $175, depending on the client. I believe one of our bigger, long term customers got us down to $125/hr but we hated it and would have dropped them(and occasionally did) when better projects came up. We also provided project managers and would bill them out as well(not sure one the rate). Fixed price happens rarely but with software being so unpredictable that basically never happens. You bill extra for any equipment you need to procure, and it usually goes back to the customer at the end of the project(but often the customer wouldn't ask for it, leading to piles of shit that periodically needed recycling).

You try to seek out larger, long-term, "cash cow" projects. One project had probably 30 people on it for years because we were working with a large, established company with no software expertise who wanted to make software heavy products. We basically became their software team while they tried (and repeatedly failed) to spin one up internally. Some projects are more like "staff augmentation" where we would just provide engineers to work with other companies' teams, fixing bugs and adding features(I did that for about 5 years for one client).

We maintained a core of semi-permanent employees who were hourly W-2 and received benefits. There was also a substantial pool of contractors we would tap into if needed. Compensation for W-2s ranged from, say, $60-120/hr depending on experience. So in my case there was a $50-150 hourly differential between my salary(not counting benefits) and what we billed.

There are some general staff you need to account for, like managers, HR, accounting, clerical, sales and marketing. If you're not careful, sales costs can be significant(especially if you have a salesperson falsifying records like we did...).

In the end the company was sold, sold again, and is now part of a giant, worldwide consulting firm. I think the owner made a decent amount by non-valley standards, but he's definitely not 'FU' rich. Consulting firms are generally about the people and how much you can bill for their time. It doesn't generally scale well. Products, on the other hand, can scale quite well after you recoup your NRE costs. We tried, and failed, a few times over the years to make products and it never worked out for us. Consulting was a stable, albeit less lucrative, source of income.

How much cash should someone accumulate before they have a decent runway to start a software dev firm with full time employees?