3 ms·
So, if it's very hard to start a software company based on paying contractors for software development -- which seems true to me -- there's another warning here
by jrochkind1 4y ago
So, if it's very hard to start a software company based on paying contractors for software development -- which seems true to me -- there's another warning here for software contractors/consultants.
If someone is paying you, as contracting engineering talent for hire on a consulting/hourly/iteration basis, to develop an app or product they hope will be the foundation of a new business -- chances are high this won't actually work out for them (despite your competence and best efforts), and chances are high they will end up angry at you for taking so much of their money to develop something that didn't end up developing the business they wanted, with possibly legal action to try to claw back some of those funds.
I have some personal observation of this. Even doing work agilely with review every two weeks and the client only paying once they've reviewed and approved the work in that two week period, and approved your work plan for the next two week period, even with all that -- after a year or two they can still threaten or carry out legal action to try to claw back of some or all of the money they've paid you.
So, these can be very dangerous clients. And that you are trying to do your best and give them a quality product -- you aren't trying to exploit them or take advantage of them, you think you were delivering what they asked for (if they asked for the wrong things is that on you? turns out, they may think it is) -- will not necessarily keep you out of these difficulties.
- rwallace 4y agoIn general of course you're right, and this is a very good point. > Even doing work agilely with review every two weeks and the client only paying once they've reviewed and approved the work in that two week period, and approved your work plan for the next two week period, even with all that -- after a year or two they can still threaten or carry out legal action to try to claw back of some or all of the money they've paid you. But I would've thought that way of doing things, sounded pretty ironclad. If in every fortnightly review of progress so far, they thought things were going well, how did they end up retroactively changing their mind after a year? Can you go into a little more detail about how things went wrong? Was it a case of 'they were a startup selling waterproof teabags, you built them an online store, turns out there is no market for waterproof teabags, and they were looking for someone to blame'?
- wing-_-nuts 4y agoOT, but I thought I'd ask, since you seem to have experience with this sort of work... In your experience, is it possible to negotiate work at a rate where one would only be working 2d / wk? I'd imagine it's hard to negotiate such an agreement with a company because they want work done on a faster timeline?
- jrochkind1 4y agoSure, probably. I worked briefly for a small (2-5 engineer, plus designers, and administrative) consultancy that did web app development; we had multiple clients at once, some clients got two FTE days a week of our time or less, sure. So I don't see why it shouldn't be possible. (Whether you can charge enough to live off of 2 days a week of work, I don't know, and depends on your living standard and location!) But there's a lot of work that isn't your hourly billable that goes into running such a business too, administrative overhead, client relationship management/development, etc. I personally ultimately decided this kind of consultancy was not work I found rewarding. I also was not one of the owners/principals, and was not there very long, so I'm not really an expert in this kind of business, and probably there are people who might be better to give you advice. But since you asked.
- ghaff 4y agoFor contract work in general, both technical and non-technical, the answer really is "it depends." Sometimes a company really does need something yesterday and you're the bottleneck in getting something released/getting revenue/etc. Bit I've also taken on writing and video projects for example that were components of a marketing campaign that was scheduled to launch some months down the road so it was a pretty part-time thing. Mostly I've worked on internal projects but the same principle applies.
- turdprincess 4y agoMaintenance work can easily be negotiated at this schedule. For example, you can launch a project, and then stay on "retainer" for 5 hours a week for bug fixes. If you find a few projects like this it could meet your criteria. With new feature development it would be harder. But you could negotiate a weekly fee based on a 4 day work week, and then get so good and efficient that you do the work in 3 days.
- sbilstein 4y agoOh absolutely. Twice I made the mistake of coming onto a startup to fix the “mess” the previous dev shop had made. Both times the founders had developed an incredibly negative relationship with their dev shop. Hell, the company with the Series A was withholding payments, the preseed company at least paid their bills. I naively thought “of course they hate working with a dev shop, the incentives are wrong. I’m FTE with percentage points equity. I’ll fix it.” Of course, things got better, but growth stalled or never happened, blame gets shifted, suddenly that founder who was excited to hire top tier talent is very disappointed in the very equity and salary expensive engineer you are. You end up being the new target of their animosity. You start to empathize with the folks in India, China, Ukraine or Argentina whose history lingers in the git blame. They’re not stupid, the incentives were just wrong! The thing is…the CEO who failed to find a technical co-founder, retain them, or replace them with the same equity agreement has already demonstrated their inability to work with technical people. If they are coming from tech, the fact that they couldn’t convince a former colleague to work with them means they’ll be a terrible manager. If they come from finance, as many founders do, you are a line item. At the end of this, hopefully sooner than later, you’ll quit, you’ll get fired, or you’ll collect paychecks while looking for the next better thing. As an engineer, stay away from mediocre CEOs.
- flashgordon 4y agoGreat advice. Any guidance on asking the right questions as a way if filtering out these traits/behaviors in CEOs?
- sbilstein 4y agoBe nice but remember you have objective skills and you need to suss out the CEOs objective skills. 1) Can they raise money? Proof is good here. Sometimes someone will say "I want you as my co-founder to go and raise my seed round" and you can condition leaving your current job on getting at least some checks in. Remember, this founder _knows_ you can deliver the goods, you are an employed software engineer. Can they? 2) Can they recruit? The process might be a mess but are they treating your time and concerns with respect? 3) Do they view you as an equal partner? Make sure you nail down exactly what they want. If they want a true co-founder, ask for 50%. If they don't, make sure you understand what it means to be an employee to a non-technical founding team.
- turdprincess 4y agoWhat is the better kind of client / project then, out of curiosity?
- jrochkind1 4y agoSo I'm no expert, I only worked in this area briefly and not as the business owner. And don't work in consulting anymore because I didn't appreciate the kind of work it was, so I'm biased. And I didn't say it was a "bad" kind of client/project, I said it was dangerous. But other kinds of clients include: * An existing successful business which needs more development or a new project * An enterprise which needs things for internal use * Universities, or non-profits * Government contracting If you are going to be developing for a software startup, being aware of the risk may help you manage it. Do _you_ think they have a possibly successful business, does it make sense to you? Of course, maybe you can't judge that, it's not like you're in the business of judging startup potential and it's not like that's easy. But does the founder seem to know what they are doing? Again, you may not be able to judge, but if you get a bad feeling it may not be worth it -- or if you get a bad feeling while in the middle, you may want to find a way to fire your client. (Even though it's hard to give up the money). Will they be the kind of client that wants to tell you exactly what to implement and have you do exactly what they say? Or will it be a partnership where they identify requirements but trust you to work out some details? Either can be risky, but it turns out "we implemented exactly what you told us to implement" isn't always enough to stop them from blaming you for their failure, and I think in some cases can paradoxically make it worse.