Show HN: Software Freelancers Contract Template
sopimusgeneraattori.ohjelmistofriikit.fiIn the USA, if some big and usually "non tech" company like McDonalds or T-Mobile wants to staff a whole project with programmers, they will usually have a relationship with someone like Infosys, Tata, Slalom, perhaps even Hitachi or Tech Mahindra or Accenture/Deloitte. These companies all pay you like a regular employee so you don't need your own drafted employment contract or business entity.
If you howver have a github/youtube channel/website where you make and release your own software, and someone contacts you saying "hello we want to pay you to add more features and or fix some problem for us", then you will need a contract and usually a business entity unless you don't mind being personally sued into the ground.
Such reachouts are very very rare unless your software has gone viral in the right circles, but I personally know at least 20 people who make a full time living this way. It seems pretty unenviable, and corporations whose email domain you would recognize routinely pull support or play egregious games with the definition of done. No cure for life, I guess :)
But with the amount of accountant overhead and government fees you have to pay per year (including to shut down your entity when you are done), it becomes a bit pointless and there aren't really magical tax savings to achieve that I know of unless you are like, really good at deducting things and surviving IRS audits. In any case, it is rare for corporations to even offer it, but maybe in some super niche areas I'm not aware of, there could be good advantages.
Still I think the hardest part is making and maintaining quality connections with people who value your skills :)
Another anecdote. I had job offers coming out of my ears while I was posting videos of my indiegame on twitter. Only one video had substantial reach -- near the end of my time actively twittering. I think what helps is doing something as well as you can, and be persistently visible.
I've also found it's pedagogically helpful to have two versions of each contract, a consultant-favored and consultee-favored. This way you can understand how each clause may be tweaked to benefit each party. For example, this book does this (US-based): https://www.amazon.com/Consultant-Independent-Contractor-Agr...
Or, even better, instead of having only two versions of a contract, we can offer this choice on individual clauses within the contract. On some clauses the parties may choose to go with consultant-favored option whereas on some other clauses the parties may choose to go with client-favored option. This is what we ended up doing with the generator :)
It should probably be clearer that this is only useful for Finns.
1) See how many steps there is in total.
2) Some "info" about the boxes - for example, what does "reference rights" mean?
3) Downloadable examples to see what is being generated in the first place.
4) Dispute resolution should also have a "Other" option that allows the user to manually input a custom value.
Otherwise it seems a like a fantastic thing! And thanks for making it free!
2) You can tell you worked for ClientCompany on SpecificProjec
3) Downloadable examples to see what is being generated: sample output links are already on the landing page. You can ctrl+f to "The PDF might look like this."
2) You can look at sample output to get more information about what the boxes mean. We made a design choice to avoid legalese text in the UI. Reference rights mean: The Supplier has the right to reference The Client in marketing as The Supplier’s customer.
4) Possible choices for dispute resolution are courts in Finland and arbitration. Before the summer we discussed internally whether we should include arbitration as a choice. We ended up deciding that we won't allow our users to choose arbitration. Since there are no further valid options for dispute resolution, we won't add an "other" option.
Thank you for the feedback!
There’s an hours version but it’s based on weekly hours, not total hours.
There’s one based on date but not taking into account hours.
Perhaps you mean that you want to lock down an exact, specific number of hours, rather than allowing any sort of flexibility on the total number of hours? This would be better suited for the "project based billing" option, but as you said, that one doesn't have the option to set a completion date. The reason why it doesn't have the possibility to set a completion date is that it would create an ugly contractual situation in the case where the deliverables are not completed by the agreed-upon date.
I've been told that if I don't have clear dates, my contracts could get nullified in court.
Source: IANAL.
Good job! I think this could be a valuable service, but the differences between legal systems could be a blocker.
As technical advisor to the project, I bill my hours, for a set amount of time, my deliverable is my knowledge and support and my rating is the outcome of the project.
> This contract was created using ohjelmistofriikit.fi contract template.
Very good. Consider having some kind of version information, such as a date (more human readable) git commit id (unambiguous), or just 1.0.0.
Assuming your contract becomes popular, it's easy to just see that "oh, this is the ohjelmistofriikit contract version 2" instead of reading every word.
Alternatively, one can step through the web UI flow to see what all the options are without the legalese.
You'll "get it" once you start bringing in open-source libraries in a project where the lawyers need to screen them.
Often, the lawyers will says, "these licenses are good, these are bad." Then you pretty much know what you can grab because most projects just pick from a set of well-known open-source liscenses.
What makes it complicated is if you try to grab an open-source project that writes its own license (or otherwise uses one that isn't well known.) Then the lawyers need to read the whole thing.
---
So, assuming your contract becomes common, people will say things like, "We're working with the 2025 ohjelmistofriikit.fi at XX an hour, open commitment, ....", and not have to read the actual contract, because it's so common that everyone already knows what it means.
(Kinda like releasing open-source software and saying, "I'm using MIT" or "I'm using GPL" and everyone knows what you're talking about.)
Make sense?
> Consider having some kind of version information, such as a date (more human readable) git commit id (unambiguous), or just 1.0.0.
Remember, the point is to make it easy for people who are familiar with the generator.
Kind of like the six different variants of Creative Commons licenses: CC-BY, CC-BY-SA, CC-BY-NC, CC-BY-NC-SA, CC BY-ND, CC BY-NC-ND.
I started reading the contract they sent me, and it didn't make sense. It stipulated that I carry liability insurance, which doesn't make any sense when writing software.
I decided to Google a phrase or two out of the contract, and I found nolo's ("No Lawyer's") template contract for hiring a contractor to do work on a home.
I decided the guy wasn't savvy enough to work for and thus I walked away.
As an European I ain't bothering suing you in the US over few thousands of $, a lawyer would be more expensive than letting it go.
On the other hand I take my obligations quite seriously.
Have to say, never had one bad experience in my life, worst that happened was getting paid 10/14 days late.
Getting customers that mean business is the hardest part, lunatics think I am applying for a full time position and making me go through 2/3 rounds of interviews and asking me to implement Levehnstein distance or something to do QA and write E2Es at their scaleup are out of their mind.
One example: does the counterparty start with a one-day NDA or a mutual NDA template.
These are not just for consulting, but covers also other IT related topics (depending of type of deal you decide which parts to include).
1 more comments available on Hacker News