I've been googling, but can't seem to get a straight answer. It seems like there's an initial project cost & then maintenance revenue ongoing for the software / app's life. Is that accurate?
Appreciate any insight y'all can provide!
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.
Take advantage of it while you can.
I don't think many care whether it comes from a .edu, or something like a student-appearance twitter account.
Was it secret information or did they spell things out much more clearly for you because there was no assumption that you had prior knowledge? This tends to happen to journalists also, for the same reasons.
See the replies in this thread for examples of people clearly spelling out things step-by-step. It's not secret information. When you take away any assumption of expertise, it may seem that way to someone not involved in the industry.
I think there’s some element of explaining things, especially if you come across as naive and interested in what they are doing.
A student, not so much.
Its not game over of competition finds out but I don't need to hand it to them.
> One of the most powerful assets you have as a student is that .edu email address.
I don't feel an .edu is even needed at all. I have an .edu as an alumni even and I graduated a long long long time ago.
Fwiw I did this also pre internet yes people do reveal all sorts of things to students. Old school though it's a bit more difficult.
* 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.
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.
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.
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.
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.
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.
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!).
Basically, try to find companies who are technical, but are missing the skill your company can provide, and then provide that.
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.
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).
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.
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).
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.
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.
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?
The advantage is that you have clearly defined goals, but the client can still change direction of they need to (by adjusting the next sprint).
For short projects (weeks), usually a percentage before and a percentage afterwards, maybe a percentage in the middle. It's all negotiable, welcome to consulting!
For long projects (years), you will need to agree on a billing schedule from the moment you draft and sign the contract up to the delivery. There should be periodic billings and milestones. Definitely do not work a whole year for free :D
Unlike the comment above (anti pattern!), you don't want to redefine the goals every week and make payment contingency on the goals (it's too much time drafting formal agreements and it allows the client to not pay you by arguing the goal is not reached). What you usually prefer is to bill for the time spent on the project (weekly or monthly) irrelevant of any goals.
There's a fundamental struggle in consulting: you should get regular feedback and make sure you're building something the client is happy with... while you need to make sure you get paid, irrelevant of what exactly was completed and of the shifting will of the client... while you can't waste all the time doing paperwork/contracts to cover your ass. Long story short you always end up billing by time, except for some short specialized work you're very confident you can handle.
Or the other end of the spectrum, where you're talking about year-plus projects with year-plus-sized price tags, and it may be worth the overheads for both sides to agree a starting spec, timescales and milestones up-front. You do need to make sure you also have a clear change management process in place, including a shared understanding that any changes are subject to approval by the developer and will increase the bill and timescales.
Do you estimate there will be X hours of bug fixing and add that to the price of billable hours?
How do you take into account client requests after a billing period is complete or during a billing period?
IME US agencies wind up billing over $100/hr/dev then still charge for bug fixes.
I’ve learned over the years that I cannot give a per project price and it has to be hourly as requirements shift often or certain tasks run over
These are dumb things that can be easily sorted out.
On the other hand it's super risky because you don't control the environment of the client (dude can't open a firewall port to make the application work, security department needs 3 weeks of ticket to open the firewall). One unlucky client and you will be in a world of pain.
I think the OP is working on small projects of a reasonable nature/domain or he would have learned the hard way to not promise upfront. (Well, it's possible to do and thrive, never getting burned by a dysfunctional client)
Benefits: You can double the project price to factor in the bugfixing/maintenance included. The client is okay with it because it comes as a great deal, project and maintenance guaranteed. The only reason to work per project as a consultant is to bill wayyy more, because you take on more risk, gotta manage the quality the scope and the client tightly.
The most success I have had with per project pricing is having a discovery phase to actually scope out the work.
There is a decent amount of up-front work, but it really ensures everyone is on the same page.
This is usually a series of 4 meetings, anywhere from 30 minutes to an hour.
From there, I can write a spec/contract, I present that, which is another meeting (I don’t just email it).
Then once they agree, 50% up front, and 50% upon completion.
There is language in the contract that any changes to spec/feature, they require an additional contract and do not change existing work/agreement.
The pain comes from vague specs and everybody has a different interpretation, and the feat of not getting paid until satisfying the vague expectations.
So, just don’t do that.
:)
I concur. Also, the discovery phase itself can be flexible on time allotted and billed in time increments, even if the main project won't be. You might well not know up-front whether you need a day, a week or a month to pin down the spec and all the other details, so a self-contained "getting to know you" phase before anyone makes big commitments has a lot of upsides for all parties.
Also, regarding the problem of vague requirements and differing interpretations, getting a complete set of acceptance tests agreed early-on has a lot of upsides for both parties too.
I'll give you an example of particular product I made for a client:
The agreement I had stated that I would support (fix bugs, no feature change) for 3 month. After that it was $X per hour with $XX minimum charge. Alternatively client could always sign for a year of support at $xxx per year.
Currently I have a contract where they simply pay me flat fee per year with the clause that each side can terminate it with 1 month advance notice.
But in my long career I've had all kinds of contracts. Including getting licensing fee while I maintained and own product (I paid for development myself)
Software in internal development, software available in testing, beta deployment on the customer site with real customers/data, go live in production, first user, first thousand users, etc...
For hardware projects (I did a lot of joint software/hardware) hardware design, ready to manufacture, first prototype, second prototype, first production series, first delivery to customers, etc...
Last but not least, the primary use cases are major milestones, the software allows to do A then B then C. Gotta determine the main use cases of the project as early as possible.
Large projects (10+ people over years) are split into components, each component has its own milestones and should stand on its own as a deliverable. Add major milestones for integrations, as soon as any 2 dependent pieces are in a working state, they need to be integrated together and tested.
Everything fell into places. But that was after few month long and expensive exploration phase that along qualified for decent contract.
After I went on my own I handle smaller contracts that are easier to eyeball. Well small is relative as in one case licensing fees alone over a period of time went well into 7 figure territory. But yeah I no longer had to direct 30 people and did not have 20 persons on a client side bugging me every day and being under constant stress ;)
EG A business has a manual process that costs them £2m/year to run. Instead of calculating how long it would take you fix, you price based on what it is worth to the business to fix the issue (obviously this needs to be larger than what you would charge on a time and materials basis).
Brennan Dunn was a big advocate of this, but mainly on a small consultancy scale (https://doubleyourfreelancing.com/rate/).
2) Doing something run-of-the-mill? Improving a process that's already in place? The client may have an idea about its ultimate specs & ROI. Even if they're able to articulate those to you – why would they?
In practice, value-based pricing comes down to "charge as much as they're willing to pay". Which is fine, that's the essence of sales. But more to do with social skills & play-it-by-ear, rather than some objective numbers you might hope to extract from a client.
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.
At that stage, you have the client company over a bit of a barrel. Unless they want to throw the consultancy out and start the bid process again.
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!
Also, what exactly is fishy with Pivotal/Accenture? I mean they're services firms which is why their multiplier is relatively low but not sure what exactly is fishy?
If kickbacks work, but are surreptitious, then the losing bidders might not be aware of kickbacks? I could easily imagine an ecology of vendors where some regularly use kickbacks/bribes for their bids, and some never do. Personally I haven’t seen kickbacks either: but I’m in NZ, and I haven’t been much involved with the sales process.
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.
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.
1) the larger the client, the more it is an intentional practice to leverage any gaps in the contract to extract whatever value the company wants at that moment, regardless of what was agreed to
2) what the client “remembers” the agreement to make is usually whatever they first proposed. While many agencies seek to define agreements as a defense, larger clients happily believe you cannot afford to disappoint them and it’s entirely up to you as to whether you will play that game of chicken. Spoiler alert: you won’t.
Fortune 500s especially are very risky clients on these two points.
Here's some scenarios I've seen:
1) US F500 companies are sending out documents to vendors to allow clawing back payments from your bank account number. So besides stretching out payment terms to monts, they can reverse those payments. Never sign those if you plan to be around next year.
2) Sometimes the staff proposing the project get cold feet in the middle of the approval process, realizing there's career risk if the project fails for any reason. You'll get an email like, "Good news, we signed the deal but you'll be reporting to somebody else. Good luck!." And then you talk o the new guy and he says, "It doesn't matter to me if this project succeeds. We just won't pay if it doesn't." Without a champion, there's a sense of limbo that weighs on the project.
In this case, the former champions became so risk-averse that they said, "Why don't you retain ownership of the product, and we'll just pay you like it was a service instead?" Bizarre, but that level of hands-off made them comfortable, and the product can be sold as-is to other companies.
3) Then there's the "missing key man" who shows up after approval and says, "This project is for my group, but I don't want to meet with you. Just develop it and I'll take a look after you're done and let you know if I like it or not."
4) I've done development on 3 contracts where the big name companies had serious networking or other infrastructure issues that required workarounds.
One manager actually said after I arrived on-site, "It's more valuable to me if you troubleshoot the infra problems than finish the product." It turned out they had email loop problems that lost most internal emails and saturated their switches.
Often you get a reaction of disbelief when you tell people these anecdotes, even in the industry, but those actually happened. All of the projects were finished successfully, but the project risk increased far beyond what was expected for both sides, and relations turned from friendly to hard-nosed solely because of their internal politics.
The best thing you can do is ensure the project is big enough to make it worthwhile despite surprises, and to know exactly who the champions and customers are. Or just get a job at FAANG.
Working with f500 companies is very good business if you have the reputation to push back on their crazy deadlines and actually deliver after they sign you a contract. If you show them professional and reliable work the issues you described typically go away.
I own a software consulting firm and those are problems that I frequently see in projects done by companies that are only looking for the paycheck and then they cut every corner possible and have no real commitment with the project/customer.
In the end the PM says "at least I hired Accenture so this isn't my fault".
It was exactly for those reasons that 15 years ago I decided to start my own company trying to 1) have fun place for devs and 2) deliver on budget and on time in every single project. For 15 years I didn't have to hire a single sales person because our reputation kept bringing more projects than we could handle.
Software consulting can be very fulfilling and rewarding if you have the passion and nails the deliveries. If you build, they'll come.
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.
This is sort of revenue sharing -- more customers, more statements (though not more services per same customer) means more billings
One problem is that clients hate it, even when success was very measurable. I suspect due to our natural tendency for zero-sum thinking. Note that usually the projects were limited to ones where there was a directly measurable outcome to drive the metrics for the payments.
Wierdly enough you would think that such a business could pivot to developing its own product. Why is it that custom software dev houses hardly ever manage to pivot to developing a successful product?
1) They generally don't make enough profit to save up and then cover the investment period of developing new unproven software (which can be years).
2) If it's too similar to work they've done, former customers may be able to claim some ownership and eliminate the profit.
3) If it's too dissimilar to work they've done, then it's just a shitty startup with no funding.
4) Even if all that worked out, it's wildly impractical to work on client projects and your own projects with the same staff at the same time. So you either need to do one or the other.
I've seen this personally as well. Especially with non-Software clients, the psychology you're battling seems to be that "they're ripping us off" since most of the work you're doing isn't happening while you're earning money.
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.
Twitter Bootstrap was a great example for a few years. Clients got “custom” apps/websites and front-end devs could stitch together libraries pretty fast.
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
- [0]: https://twitter.com/jugurthahadjar/status/131066829330549965...
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.)
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.
Start with a small increment of a day or two and gradually increase the billing increments to a week or two. Don't continue work until you have gone over deliverables with the person who is "writing the checks" at the end of each stage (every few days at first). Agree on a fee for that upcoming period after discussing the work for that time frame. Make sure they are comfortable and if not stay with the smaller periods.
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 and the contractor side over my career, the main thing I've learned is that I'd rather avoid it, as the incentives can so easily produce perverse outcomes.
[1] https://www.glassdoor.com/Salary/Accenture-Entry-Level-Softw...
The only way to maybe make it work is to sell to people who know what they are doing, but that gets dangerously close to the "I could have done that myself easily" territory.
The funny thing is: I started my software engineer career working for a large consulting firm and my frustration with the whole game was exactly my motivation 15 years ago to start my own business. I wanted to create a company that was 1) fun place to work for devs and 2) that was able to deliver on time and on budget on every single project (I'm obsessed about customer satisfaction).
15 years later and many many projects later I think I have definitely succeeded in my goal. So I think I have proof that software consulting doesn't really have to be that way. I can be fun, profitable and beneficial to all parties involved. We never had to hire a single sales person until 2020 because word of mouth kept us going.
By the way, we work at much better margins than those listed in here (I'm too shy to say the number though).
I think a lot has to do with passion and dedication. Knowing when to say no to customers and when to call bs on their deadlines.
I have definitely lost deals to other companies with a not-so-good value proposition but in the end those same customer come back calling us once they project melt in front of their eyes. I lost count how many times that happened. At least 30% of our project are a re-do of other companies fuck-ups.
The only other model I've seen is to offer a canned solution that's customized for each customer, then charge an initial 'customization' fee and a monthly/yearly maintenance fee.
There's a lot of theory about professional services, and almost all of it applies to software dev firms.
You can search for 'how to find new and available RFPs' and the search results will explain services you can pay to get this information.
Free - Hustle and reach out to businesses
Paid - Directories of open RFPs
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.
Then you keep one of employees, later maybe more, on that SaaS and slowly change your revenue mix. Then you still might get some additional projects but you always have something to spend your FTE time on. In the end you change the company profile where you chase different things than just having butts in the seats.
But that might mean you are not getting any salary for months because you have to reinvest in your SaaS idea. Of course having a viable product idea is another very important point.
Upside on the other hand is that selling viable SaaS business will be easier than selling dev shop, because dev shop only has developers. When developers quit dev shop value goes immediately to 0, with SaaS you still might have IP and paying customers.
One Michigan company was doing CRUD apps on contract, wrote a nice code generator, then swiched over to using the code generator internally (not for sale) to scale up to state government contracts.
In Asia (China, Indonesia), it's common for unfunded startups to start an internet cafe for revenue/office space, then once that's operating do product or contract software development.
(Internet cafes require constant staffing, so any "profit" is mostly paid out in salaries to the owners and family.)
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.
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