flex hours may be challenging, however if she still remembers the basics there are still not so sexy jobs maintaining legacy software in languages that did not change that much in the past two decades.
16 karma · joined July 14, 2015
2. I understand you're in USA.
- By going into eastern europe, or Vietnam, or India you would not stop competing with Google and likes. Even when they do not have direct offices in the country, their suppliers do.
- in most hot tech hubs competition for talent is fierce.
- you would have a very hard time finding senior developers. they would typically not join an unknown company for a non-permanent position.
- it won't be easy to communicate; timezone is a major issue for communication.
- soft skills are very different from what you would expect from US.
- in the past year, it became extremely complicated to get a first job or step up, as everyone is now working remotely, and only want senior developers. There is very little competition for juniors. Try to build around your domain expertise so that if you can build a pipeline of more or less technologically similar work, so that you could employ a high numbers of junior to mid level personnel to do work according to your blueprints.
- tax wise, its easy: from USA perspective, you're tax witholding agent, and as such you just need collect W8-BEN (for individuals) and W8-BEN-E for corporations to establish that other party is not a US person / corporation, plus it establishes the tax withholding rate - for most countries USA has tax treaties with, its zero. The other party in principle should obtain ITIN (for individuals) or EIN (for corporations) and file a very simple annual return with IRS - but it's not your responsibility (and in reality, almost nobody does it, as there are no taxes to be refunded).
- labour law wise, your relationship with a remote contractor may be classified as employment based on certain criteria such as clocking particular hours a day within certain period, you provide an equipment, pay for internet etc; your exposure is really to the country where your contractor resides. You should structure your contract in such a way that it would not be deemed an employment contract and confirm your counter-party actually pays mandatory deductions in her country. This is a very low risk you shouldn't really worry about. Remember that prosecuting you would require international litigation, and you have to have hundreds of employees in a certain country to make it worth it.
- remember I'm not a lawyer, just speaking out of my past experience ;-)
3. Probably doing full-stack development is worth expanding to. Cloud migration from legacy apps is still a good business. Devops is #1 in unfilled positions I hear from some my former colleagues.
Note that service business gets most profits by employing large amounts of averagely paid personnel doing standardized jobs, not because you've got 5 ninjas you try to charge a fortune for.
4. Direct connections and regular business development. In-depth blogs, open source participation are known long-term strategies. Cold emails don't really work. At that stage, try to find a sales person who would work strictly commission-wise. Avoid "fractional sales persons" who would charge you few K/month (just like another 10 clients) and they would effectively just recycle their rolodex - you'll have many leads and meetings and but likely no contracts.
WGAMES is a mobile games startup looking for Senior Unity/C# Engineer to develop core frameworks our current and future titles use.
We are looking for people with experience shipping games and apps on mobile platforms, declarative frameworks such as React and solid CS backgrounds.
Please apply here: https://wgames.bamboohr.com/jobs/view.php?id=48
developing under such constraints is radically different from environments with high iteration velocity - i.e. browser or scripting.
that said, in many modern environments whiteboarding is completely irrelevant, as modern application level programmer productivity is often ability to do plumbing-and wiring- work between many components and quickly assess why something is going wrong, rather then creating a highly performant or memory-efficient algorithm implementation.