12 ms·

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

• llimos 6y ago
  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.
• piyushdinde 6y ago
  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.)
• zdragnar 6y ago
  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.
  • gadders 6y ago
    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.
    • zdragnar 6y ago
      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.
• deleted 6y ago
  [deleted]
• winkelwagen 6y ago
  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
• user5994461 6y ago
  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?
  • Aaargh20318 6y ago
    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).
    • Nbox9 6y ago
      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.
    • user5994461 6y ago
      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.
• jvilalta 6y ago
  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.
  • Nbox9 6y ago
    I’ve seen equity as part of the compensation deal, but never revenue sharing.
    • TuringNYC 6y ago
      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
  • robocat 6y ago
    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?
    • larrik 6y ago
      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.
• sesuximo 6y ago
  You might get better answers by calling a few firms and asking directly
  • lifeisstillgood 6y ago
    He just asked hundreds of workers in the tech industry directly. He should get some pretty good ideas
• wpietri 6y ago
  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-Software-Engineer-Salaries-E4138_DAO.htm?filter.jobTitleExact=Entry-Level+Software+Engineer https://www.glassdoor.com/Salary/Accenture-Entry-Level-Softw...
• collin128 6y ago
  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.
  • apkallum 6y ago
    How can I DM you?
• tootie 6y ago
  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.
  • sirspacey 6y ago
    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.
• BookingNinjas 6y ago
  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/ 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.
• Jugurtha 6y ago
  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/1310668293305499653 https://twitter.com/jugurthahadjar/status/131066829330549965...
• deleted 6y ago
  [deleted]
• ozten 6y ago
  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.
  • christopherwang 6y ago
    Is there a better place to find new and available RFPs than a blanket google/duckduckgo search?
    • ozten 6y ago
      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
      • christopherwang 6y ago
        Makes sense. Thank you!
• an_opabinia 6y ago
  > 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!
  • atlasunshrugged 6y ago
    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?
    • deleted 6y ago
      [deleted]
    • robocat 6y ago
      > 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.
• karaterobot 6y ago
  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.
  • ozim 6y ago
• gharman 6y ago
  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.
  • HeyLaughingBoy 6y ago
    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.
    • 6y ago
• PopeDotNinja 6y ago
  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.
  • sirspacey 6y ago
    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.
• atlasunshrugged 6y ago
  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
• chairmanwow1 6y ago
  >> “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.
  • Cancan82 6y ago
    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.
    • larrik 6y ago
      Mostly because salespeople will use the same tricks to sell you stuff after you open up.
  • elevenoh 6y ago
    >that .edu email address. I don't think many care whether it comes from a .edu, or something like a student-appearance twitter account.
  • ctvo 6y ago
    > 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.
    • chairmanwow1 6y ago
      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.
• ryanmarsh 6y ago
  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.
• pearjuice 6y ago
  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.
• 01100011 6y ago
  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.
• xwdv 6y ago
  How much cash should someone accumulate before they have a decent runway to start a software dev firm with full time employees?
  • roel_v 6y ago
    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".
    • xwdv 6y ago
      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.
      • roel_v 6y ago
        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).
• edanm 6y ago
  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.
• femto113 6y ago
  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).
• ilaksh 6y ago
  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.
• stakkur 6y ago
  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.