Ask HN: How do custom software dev firms make money?
110 comments
>> “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.
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.
> It was amazing how much secret information people were willing to share.
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.
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.
Absolutely. They gave revenue numbers, they told me how they marketed, how they retained customers, if it was a good deal for the customers.
I think there’s some element of explaining things, especially if you come across as naive and interested in what they are doing.
I think there’s some element of explaining things, especially if you come across as naive and interested in what they are doing.
I dunno, if my competitor emailed me I would be pretty tight lipped.
A student, not so much.
Its not game over of competition finds out but I don't need to hand it to them.
A student, not so much.
Its not game over of competition finds out but I don't need to hand it to them.
This is 100% true. Almost everyone loves the interested student, but the moment you get a work email address the cold phone calls and emails receive less warm receptions.
Take advantage of it while you can.
Take advantage of it while you can.
Mostly because salespeople will use the same tricks to sell you stuff after you open up.
It's also a predictably lazy and obvious way to do this. No creativity at all. I can think of better ways to social engineer the HN community to spend time 'delivering the goods'.
> 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.
> 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.
>that .edu email address.
I don't think many care whether it comes from a .edu, or something like a student-appearance twitter account.
I don't think many care whether it comes from a .edu, or something like a student-appearance twitter account.
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.
* 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.
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!).
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!).
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.
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.
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.
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).
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).
How do you get started with a custom dev shop? What type of technical companies would you focus on?
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.
Basically, try to find companies who are technical, but are missing the skill your company can provide, and then provide that.
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).
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 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?
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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?
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?
A third option is to bill per sprint. You define the goals for a single sprint, which should be relatively easy (compared to defining the entire project) and bill when the sprint is completed.
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).
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).
That's an agency-friendly type of contract and it's really, really hard to sell that way unless you have a sterling reputation and great rapport. Most clients want to know exactly what they're getting and how much it will cost. Experienced tech leaders know estimates are estimates and clients usually can't even articulate what they need clearly enough anyway. It's why client services people get paid so much and why it's so hard to find good ones.
I had projects like this. We define the whole project with the client first and agree on overall price. I then split it into few stages and upon completion of each stage I would sit with the client show the work and client signs off the stage as done and pays for said stage. With this type of work I would also always charge non refundable initial deposit as sometimes the client will have the contractor started and then change their mind. I also specify 3 month "free" bug fixing after final acceptance and then maintenance fee should they desire.
That’s really interesting. I’m coming at this from 2 angles —- I run a small “shop”, me and 1 or 2 other guys part time; I also work for a company who has contracted an agency for creating a design system for us.
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
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
I have done this both ways.
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.
:)
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.
:)
The most success I have had with per project pricing is having a discovery phase to actually scope out the work.
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 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 think you need to think hard what is a bug. Need to update the URL to the outlook API because microsoft is changing it every now and then? Need to send a new icon/logo because reasons and the client doesn't know how to update an icon himself?
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.
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.
I put defect severity definitions right in the contract. Critical, major, minor, cosmetic. Then put like a 24-hour SLA on critical and major only. Maybe 2 business days on a minor or cosmetic. And a max of 30 days post delivery after which we require a change order to address further issues.
>"Do you estimate there will be X hours of bug fixing and add that to the price of billable hours?"
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)
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)
I think it is all in the ‘selling’ of it, it may be a sprint, but it is sold as a ‘milestone’.
I actually meant milestone. I do not do Sprints as in Agile. Normally I design and develop new products from a scratch and there is no use of Agile propaganda in it.
Great response!
Funny because I do product dev from scratch and wouldn't dream of doing it without agile being explicitly bought into by the client. How you do a non-trivial project setting fixed milestones upfront?
Being very experienced product designer/developer after few talks with the client I could fairly accurately split big project in few comprehensible stages with the price for each. I do not remember ever being off by any significant margin. I've done way too many of projects either directly or as a director during the course of my life so it is mostly an autopilot at this stage for me. Also my clients tend to be real business people with real business needs. They do not really like to go into methodology level. they just look at my resume, and check references. They are much more interested in how I can solve their problem on conceptual levels before really engaging.
I concur. Milestones are comically similar from project to project.
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.
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.
I mean, I've worked on plenty 7-8 figure programs for Fortune 50 companies of all kinds and that has not been my experience at all. I've even worked for FAANG clients who didn't know what they wanted until we tell them. The kind of work I did (I am exiting the consulting world as of this week) was very consumer-facing and creative driven. I can estimate tech work as well as anyone, but there's always too many moving parts to a big project to know how everything will fall into place.
I did work on similarly sized contracts but I was at the time a CTO and had like team of 30 on that project under my supervision.
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 ;)
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 ;)
Arf I didn't cover "when" the client is billed.
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.
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.
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.
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.
Every sprint team I’ve been on is loaded with unexpected stories, and this was doubly true when I was working on a sprint team building for a client.
There is also value-based billing. A lot of people talk about it, but never seen in the wild.
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/).
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/).
1) Are you doing something innovative? By definition there's no clear value to baseline against. Clients don't know what's even possible, much less how much $$$ it might bring them. So the value in "value-based" is correlated with some internal strategy / personal / brand politics. Good luck quantifying that as an external SW dev firm.
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.
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.
[deleted]
And don’t forget about retainer based work. You agree on a cost per hour and setup a retainer on that. It’s similar to sprint based but more open ended. Works great for clients wanting lots of design rounds and tweaks.
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.
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.
Normally on a fixed bid project, the consultancy hopes for change requests. That is where they make a lot of their margin.
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.
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.
Smaller consultancies rely on good relationships for recurring projects and / or referrals, so I haven't seen this behavior as much from them. That said, I do not think it is uncommon for a consultancy to try to make up losses on the original fixed bid with higher margins on changes or future work. It really depends on the people running the show, especially on the sales side of things.
> 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!
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've been in and around the custom software dev scene for a long time (on the sales side mostly) and your example of having kickbacks seems incredibly rare and is definitely not part of 99% of projects (also on a 400k project I doubt you're paying anywhere near 50k in legal costs unless you get sued after). Much more likely is that your buddy does you the favor for free because you're friends, because he trusts you to deliver because you have a relationship, and because it's not his money anyways.
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?
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?
[deleted]
> kickbacks seems incredibly rare and is definitely not part of 99% of projects
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.
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.
Yeah, it's possible for sure, but salespeople like to talk and there's lots of turnover between firms so I think there would just be more rumors floating around if there was a lot of bribery going on. That said, good point mentioning location, I'm in the US and have mainly worked in the US and W. EU, no context on bribery and the like outside of there. That said, I'd still be skeptical about someone from a big company based in the U.S. that could be hit by the U.S. govt by fines like Microsoft having a lot of bribery going on anywhere in its operations
Ha ha want to see the look on the teachers face when this answer is handed in!
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.
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.
How can I DM you?
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.
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.
Along these lines it is important to recognize:
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.
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.
This is not my experience at all. If you know what you're doing is relatively easy to avoid the pitfalls you described.
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.
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.
It gets much worse than that. If you're planning to do software development consulting/contracting, definitely read on.
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.
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.
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.
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.
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.
I saw a small company do all their work this way, where their pitch was more a marketing company with software skills. Projects were successful, but it folded a few years later due to other reasons.
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?
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?
>One problem is that clients hate it
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.
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.
My theory:
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.
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 equity as part of the compensation deal, but never revenue sharing.
Depends on how bit the firm is. Very large consultancies with good lawyers who can commit to long-term support can do this and I have seen it. For example, one consultancy I was at charged "several pennies per billing statement" in exchange for re-doing the billing and statement system for a large telco. The consultancy also got a fixed fee upfront for initial investment.
This is sort of revenue sharing -- more customers, more statements (though not more services per same customer) means more billings
This is sort of revenue sharing -- more customers, more statements (though not more services per same customer) means more billings
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.
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.
The profit window is where clients see the work as custom while the implementation is off-the-shelf.
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.
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.
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
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
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...
- [0]: https://twitter.com/jugurthahadjar/status/131066829330549965...
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 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.)
[deleted]
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.
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.
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.
In my experience maintenance is included only reluctantly. Much like any contract organization the owners of the companies make all their money on the margin between what they charge the customer and what they pay their laborers. For the laborers the upside tends to be high paying but comparatively short duration jobs within their chosen specialty. In my firm that largely sorts out to people between "permanent" positions or those who are semi-retired and don't want to work year round. On both sides of this equation you have people who generally prefer concentrated development (say a team of 3-5 people working 40-50 hour weeks for 6 months) than a longer duration but less intense maintenance effort (1-2 people working 10 hours a week for years).
I recommend that you have very clearly defined budgets for the full project but absolutely avoid fixed bids.
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.
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.
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 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 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...
I find your comment very accurate of the status quo when you look at dev consulting companies at large.
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 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.
Congrats! Yes, I should have mentioned that I know some people who have made a successful go of it. And yes, some clients are capable of actually learning lessons. Glad to hear you're finding them.
Can confirm, the "just charge a lot up front for good quality" strategy doesn't work very well. In retrospect it's obvious why, the client will always find other people promising the same results for less. Actually delivering, different story. Having been right doesn't do much for your bottom line, unfortunately.
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 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.
Based on my own work experience with such firms, the revenue model is the same as any other contractor/specialist hired to do work--make a margin on every project you can, and keep searching and optimizing for projects that allow a comfortable margin above costs.
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.
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.
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.
How much cash should someone accumulate before they have a decent runway to start a software dev firm with full time employees?
That's the wrong way around. You start small, part time if possible, and grow (and hire) as you get more steady work. Do not save up 2mm, hire 5 guys, then the next Monday morning say "ok guys let's find some customers".
But at some point you must be saving up profits right? Eventually you will have to hire people that do not have billable hours, you can’t rely on just cash flow from work to cover salary expenses.
The company should be saving up some of its profits for future investment, yes, but the question was (at least that's how I understood it from the way it was phrased) how much to save up before actually starting. My point was that one of the great things that are specific to software is that you don't need large up front investments, or even any investment at all besides some hardware and an internet connection. You just get started and reinvest the earnings, e.g. by hiring people (where the 'investment' is the non-productive ramp up phase of any new hire).
[deleted]
I highly recommend you look into the field called "Professional Services". A custom software dev firm is one example of a professional services firm, but far from the only one. Another common example is a Legal firm.
There's a lot of theory about professional services, and almost all of it applies to software dev firms.
There's a lot of theory about professional services, and almost all of it applies to software dev firms.
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.
Is there a better place to find new and available RFPs than a blanket google/duckduckgo search?
I would pick a very specific niche (landscaping companies for high end architecture firms) or focus on local businesses in a category (architecture firms) and try to answer that question for myself. I'd connect with a few and ask them how they have done RFPs in the past and if they have any current projects open for bid.
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
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
Makes sense. Thank you!
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.
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.
If you would have a SaaS product idea then you could invest in a product that will bring stable income. That is the way back to sanity so instead of going into that madness of chasing bigger contracts you invest time of employees that are on bench into building your own SaaS.
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.
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.
That's a common strategy in the West. Basecamp basically did that, and Slack was a parallel project while developing something else.
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.)
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.)
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.
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.
You might get better answers by calling a few firms and asking directly
He just asked hundreds of workers in the tech industry directly. He should get some pretty good ideas
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
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
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!