Nice job! As a US-based consultant, I've found it's always best if you immediately suggest a contract. This way you can ensure it starts with terms favorable for you.
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...
> helpful to have two versions of each contract, a consultant-favored and consultee-favored
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 :)
(In the US), right when I was out of college, an entrepreneur tried to hire me as a consultant to write software for a device they wanted to sell.
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.
FWIW professional liability insurance absolutely can make sense, even be necessary when writing software, depending on the nature of the contract and your overall responsibilities.
Nolo is a part of the Latin legal term "Nolo Contendre" ie, "I do not wish to contend". I would recommend you seek an attorney's help when reviewing any contract, even if it was a templatized one to avoid such linguistic mistakes in the future.
As a freelancer I consider contracts little more than good intentions on client side, especially as soon as you cross borders.
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.
In general, contracts often are a good leading indicator of how a counterparty thinks and is likely to behave. Do they start with egregious terms and conditions, do they flex on some of those are all good signals.
One example: does the counterparty start with a one-day NDA or a mutual NDA template.
I presume you meant one way NDA, your overall point is a really good one. Contracts are very useful as a leading indicator of how the counterparty thinks about the relationship.
If you go interview at a Facebook office, you'll be asked to sign one before they let you in. Basically - "we'll tell you stuff. That's confidential. You tell us stuff. That's not confidential".
"IT 2022" [1] the mentioned "gold standard". The benefit is that these are in general well known in the market, so they might not require that much review from the lawyers.
These are not just for consulting, but covers also other IT related topics (depending of type of deal you decide which parts to include).
> 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.
Hmmh. We have to also keep in mind that there are various customization options in the form. So even though someone might see "oh, this is ohjelmistofriikit contract", they should read through, because the customization options change the contents of the contract significantly. We can't solve this by adding git commit info or similar versioning.
I don't know exactly what you're asking of me. We already released the GoogleDoc that has all the options. It's linked on the landing page. It's the most concise way of expressing all the possible options in the generated contract. We don't want the generated contract to look like that, as that would defeat the whole purpose of the web generator.
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.)
Okay, I understand the analogy. You imagine a world where there would be a "standard contract" that could be referenced by its name, just like the MIT license can be referenced by its name without having to read it every time. Would that be nice? Sure. But we didn't create anything like that. Our contract-generator can output many different kinds of contracts depending on the inputs. This was a design choice that we made early on: we wanted to support many different kinds of needs, as opposed to just creating a singular one-size-fits-all contract template. The whole point of having a web generator for the contract is that it gives you easy access to tweak all the different clauses. If it was just a one-size-fits-all contract template, why would there be any "generator" in the first place? So... I'm back wondering what it is you're asking me to do exactly.
So, suppose you have 2 different contracts. One is extremely favorable to the freelancer, whereas the other one is extremely favorable to the client. And they both have the same git commit id. What does the git commit id help in this situation? What would somebody gain from seeing it?
1) There's approximately 10 steps. The specific number of steps depends on input choices you make. For example, if you choose project-based billing, there will be fewer steps than if you choose hourly billing. As soon as you begin filling the form, there is a progress indicator visible at the bottom, giving you a rough percentage of how much work you still have to do.
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.
What type of contract is most common with software freelancers in Finnland? In Germany we usually differentiate between getting booked by the hour or goal based contracts. I think in the last decade(s) the trend has drifted towards the former. Note that I'm probably using the wrong English terms to describe this
Could you clarify what you mean by "weekly hours, not total hours"? If you input weekly hours and a completion date, doesn't that achieve exactly what you want? The contract will be valid until the date that you specify, and during the time that the contract is valid, you can charge approximately the amount of weekly hours specified. For example, if you have agreed to charge 40 hours per week for 4 weeks, then that is the same thing as agreeing to 160 hours in total. The wording in the generated contract is such that you don't have to work the exact same amount of hours each week, you can work more during one week and less during another week.
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.
Welcome to Enterprise Consulting in the US. Where you live or die by the SOW.
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.
The big text below the title says "Legally sound contract for direct assignment between freelancer and end client in Finland". I also explained the connection to Finland in OP and explained in OP why it might be useful for persons outside of Finland.
Freelancers mostly work intermediated assignments rather than direct assignments. These intermediators have put up what are essentially job boards. If you are well connected, you can get direct assignments via your contacts, or by reaching out like traditional sales work. If there are some avenues to get leads for direct assignments, I would be really interested to find out!
In 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 :)
Large consultancies like Tata also operate in Finland + we also have a bunch of our own consultancies that operate in this manner (their consultants are regular employees of the consultancy). Earlier when I mentioned job boards for freelancers, it is particularly these large consultancies that subcontract down to freelancers via job boards (they try to fill positions from their bench, and when they are unable, they subcontract to other consultancies or freelancers).
Nice! In the US that still happens a fair amount too but I think as the industry has developed it has become much more rare than before. Athe keyword would be "corp to corp" employment, where you as the programmer either have an LLC, s-corp, or c-corp.
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 :)
> Such reachouts are very very rare unless your software has gone viral in the right circles
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.
Bitkom, the leading German digital industry association, offers general terms and conditions templates (https://bitkom-consult.de/muster-agb) and a guide for service contracts: https://www.bitkom.org/sites/main/files/2021-02/praxishilfe-...
Nice job! As a US-based consultant, I've found it's always best if you immediately suggest a contract. This way you can ensure it starts with terms favorable for you.
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...
> helpful to have two versions of each contract, a consultant-favored and consultee-favored
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 :)
(In the US), right when I was out of college, an entrepreneur tried to hire me as a consultant to write software for a device they wanted to sell.
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.
FWIW professional liability insurance absolutely can make sense, even be necessary when writing software, depending on the nature of the contract and your overall responsibilities.
Sure. But the point in parent post was that someone copypasted a home contractor template to use for a software contractor.
Nolo is a part of the Latin legal term "Nolo Contendre" ie, "I do not wish to contend". I would recommend you seek an attorney's help when reviewing any contract, even if it was a templatized one to avoid such linguistic mistakes in the future.
As a freelancer I consider contracts little more than good intentions on client side, especially as soon as you cross borders.
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.
In general, contracts often are a good leading indicator of how a counterparty thinks and is likely to behave. Do they start with egregious terms and conditions, do they flex on some of those are all good signals.
One example: does the counterparty start with a one-day NDA or a mutual NDA template.
I presume you meant one way NDA, your overall point is a really good one. Contracts are very useful as a leading indicator of how the counterparty thinks about the relationship.
I've never seen or even heard of one way NDAs.
If you go interview at a Facebook office, you'll be asked to sign one before they let you in. Basically - "we'll tell you stuff. That's confidential. You tell us stuff. That's not confidential".
"IT 2022" [1] the mentioned "gold standard". The benefit is that these are in general well known in the market, so they might not require that much review from the lawyers.
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] https://it-ehdot.fi/briefly-in-english/
I looked at the sample:
> 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.
Hmmh. We have to also keep in mind that there are various customization options in the form. So even though someone might see "oh, this is ohjelmistofriikit contract", they should read through, because the customization options change the contents of the contract significantly. We can't solve this by adding git commit info or similar versioning.
Then you can list all the options in a concise manner.
I don't know exactly what you're asking of me. We already released the GoogleDoc that has all the options. It's linked on the landing page. It's the most concise way of expressing all the possible options in the generated contract. We don't want the generated contract to look like that, as that would defeat the whole purpose of the web generator.
Alternatively, one can step through the web UI flow to see what all the options are without the legalese.
> I don't know exactly what you're asking of me.
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?
Okay, I understand the analogy. You imagine a world where there would be a "standard contract" that could be referenced by its name, just like the MIT license can be referenced by its name without having to read it every time. Would that be nice? Sure. But we didn't create anything like that. Our contract-generator can output many different kinds of contracts depending on the inputs. This was a design choice that we made early on: we wanted to support many different kinds of needs, as opposed to just creating a singular one-size-fits-all contract template. The whole point of having a web generator for the contract is that it gives you easy access to tweak all the different clauses. If it was just a one-size-fits-all contract template, why would there be any "generator" in the first place? So... I'm back wondering what it is you're asking me to do exactly.
This:
> 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.
So, suppose you have 2 different contracts. One is extremely favorable to the freelancer, whereas the other one is extremely favorable to the client. And they both have the same git commit id. What does the git commit id help in this situation? What would somebody gain from seeing it?
Gpl and mit licenses dont have multiple parameters
Would love these points fulfilled:
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!
1) There's approximately 10 steps. The specific number of steps depends on input choices you make. For example, if you choose project-based billing, there will be fewer steps than if you choose hourly billing. As soon as you begin filling the form, there is a progress indicator visible at the bottom, giving you a rough percentage of how much work you still have to do.
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!
Thanks for the reply, it seems that I was glancing too quick on the site then. And the reasoning for avoiding legalese makes sense.
Not OP but
2) You can tell you worked for ClientCompany on SpecificProjec
Oh - thanks for the info!
Very well done. Since this is open source, it can be customized further to make it country specific with contributions.
What type of contract is most common with software freelancers in Finnland? In Germany we usually differentiate between getting booked by the hour or goal based contracts. I think in the last decade(s) the trend has drifted towards the former. Note that I'm probably using the wrong English terms to describe this
Hour based contracts are by far more common than goal based contracts in Finland. Both types are supported in our template.
I’m gonna do it I’m afraid and plug my own UK based one (it is paid though): https://davzie.com/products/contracts
It’s missing another option. Contract for a date, for a set amount of hours, until a completion date.
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.
Could you clarify what you mean by "weekly hours, not total hours"? If you input weekly hours and a completion date, doesn't that achieve exactly what you want? The contract will be valid until the date that you specify, and during the time that the contract is valid, you can charge approximately the amount of weekly hours specified. For example, if you have agreed to charge 40 hours per week for 4 weeks, then that is the same thing as agreeing to 160 hours in total. The wording in the generated contract is such that you don't have to work the exact same amount of hours each week, you can work more during one week and less during another week.
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.
In the US, dates are quite important on all contracts.
I've been told that if I don't have clear dates, my contracts could get nullified in court.
Sounds like this is a difference between legal systems in Finland vs US. In Finland it's okay to sign a contract that remains in force indefinitely.
I'll bet there's ways to do that in the US, too, but I guess it needs some "secret sauce" to make it work.
Source: IANAL.
Good job! I think this could be a valuable service, but the differences between legal systems could be a blocker.
Welcome to Enterprise Consulting in the US. Where you live or die by the SOW.
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 is designed only for Finland. The jurisdiction popup lists only Finnish options.
It should probably be clearer that this is only useful for Finns.
The big text below the title says "Legally sound contract for direct assignment between freelancer and end client in Finland". I also explained the connection to Finland in OP and explained in OP why it might be useful for persons outside of Finland.
How does one get inbound/outbound leads for hourly or project work from companies that aren't scammers or tirekickers?
Freelancers mostly work intermediated assignments rather than direct assignments. These intermediators have put up what are essentially job boards. If you are well connected, you can get direct assignments via your contacts, or by reaching out like traditional sales work. If there are some avenues to get leads for direct assignments, I would be really interested to find out!
Thanks for your feedback on this :)
In 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 :)
Large consultancies like Tata also operate in Finland + we also have a bunch of our own consultancies that operate in this manner (their consultants are regular employees of the consultancy). Earlier when I mentioned job boards for freelancers, it is particularly these large consultancies that subcontract down to freelancers via job boards (they try to fill positions from their bench, and when they are unable, they subcontract to other consultancies or freelancers).
Nice! In the US that still happens a fair amount too but I think as the industry has developed it has become much more rare than before. Athe keyword would be "corp to corp" employment, where you as the programmer either have an LLC, s-corp, or c-corp.
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 :)
> Such reachouts are very very rare unless your software has gone viral in the right circles
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.
Charge by the day. Offer a 10% discount on your hourly rate to sweeten the deal.
That's very helpful! Do you have any plans to open-source this?
Everything is open-sourced: https://github.com/Ohjelmistofriikit/contract-generator
Pretty useful actually!
That’s a useful thing.