How to integrate AI into your business: use cases, risks and automation
How to integrate AI into your business: start from a specific task, know when a rule is enough, choose between an automation tool and custom software, and know the risks.
Updated on 14 min read
Sébastien Nobour
Founder of DEVEDANOS
Do you have a product idea, and perhaps customers already waiting for it? Are you missing someone to build it and to make the technical decisions that will shape your company for years? You may be thinking of a technical co-founder: a partner who takes a stake in the company and develops the product in exchange for shares, and who draws a salary only from the moment you have agreed, after a fundraise or the first revenue.
Paying in shares means no salary to pay. On the other hand, you give up part of your company, you spend time looking for the right person, and you go into business for years with someone you sometimes barely know. In return, this partner shares your risk, which an employee or a contractor does not.
A technical co-founder builds the product: they write the code and make the technical decisions. Later, they hire and lead the technical team.
What sets them apart from an employee is the risk they take with you. Samuel Hayot, a chartered accountant and statutory auditor, describes the co-founder as the person “who shares the risk, who commits without any guarantee of pay”. He adds that a co-founder is not “an employee you pay in shares”. Their future depends on the company’s, just as yours does.
As long as the company earns nothing, they are no drain on your cash flow. For a founder who cannot afford to pay for the development of their product, shares may be the only currency available.
Technical co-founder, CTO co-founder, technical partner: all these words refer to a partner who builds your product. Co-founder is a status: whoever holds it owns part of your company and shares your risk. CTO, or chief technology officer, is a job: the technical partner often carries the title, but an employee can hold it too.
The first place to look is your network: former colleagues, classmates, founders you met in an incubator. Matching platforms exist too.
In France, cofondateur.fr presents itself as “a platform connecting project founders with talent”. On 22 October 2026, it displayed more than 37,000 projects. This total seems to add up every listing published since the site was launched, without separating those still open or those looking for a CTO.
Y Combinator, an American startup accelerator, offers a free service of the same kind. Its page claims more than 100,000 matches. A match means two people have shown an interest in each other: it is a first contact, not yet a partner.
Bpifrance Création, the arm of France’s public investment bank devoted to starting a business, publishes a guide on finding a partner. It warns: “don’t go into partnership for the sake of it!” Before contacting anyone, write down what you expect from your partner: what they will build, what they will decide, how much time they will give to it.
To set a partner’s share, “there is no statutory scale”, Samuel Hayot points out: it is negotiated. For a very early-stage project, a co-founder’s share “could reach 50% of the shares”, writes Licorne Society, a French firm that recruits technical talent.
The simplest split is an equal one. Samuel Hayot nevertheless advises against “a strict 50/50 for comfort’s sake”: each person’s share should reflect what they bring, their time, their skills and the risk they take.
Two entrepreneurship researchers, Thomas Hellmann and Noam Wasserman, studied how equity was divided among 1,476 founders of 511 new ventures. In their data, when the founders split the equity equally, the startup is valued lower at its first funding round. The authors don’t put this down to the equal split itself but to what it reveals: founders who avoid negotiating with each other risk negotiating poorly with investors too. As for the founder who contributes most, accepting an equal split costs them, by their estimate, around 10% of the equity: the extra share they would have secured by negotiating.
Before proposing a percentage, write down what each of you brings, and what each of you will bring in the years ahead.
For his book The Founder’s Dilemmas, published in 2013, Noam Wasserman gathered data on nearly ten thousand founders. His publisher sums up the conclusion: “people problems are the leading cause of failure in startups”. Bpifrance Création’s guide says so too: “The risk of conflict between co-founders is real. It is even one of the main causes of failure for new businesses.”
Another cause of failure, though, comes into play before you even start looking for a partner. The research firm CB Insights analysed 111 startups that had shut down, in a 2021 study reported by the website SmartCompany. No market need is among the reasons cited for 35% of them. The wrong team is cited for 14%.
Finding a partner does not yet tell you whether customers want your product. Check that before offering shares, with an MVP, a minimum viable product. It is not a first version of the product, but the smallest test that checks whether the idea is worth building.
Paying in shares adds a condition to the choice: being able to work for months without a salary, thanks to savings, another job or spare time. In our view, this is the risk specific to this way of paying. It narrows the choice to the people who can afford it, and the skills your product needs are not necessarily among them.
Research on how founding teams form shows a related mechanism. Three American sociologists, Martin Ruef, Howard Aldrich and Nancy Carter, studied 816 founding teams, drawn from a representative sample of business founders in the United States. In their article published in 2003, what most determines a team’s make-up is how alike its members are and the strong ties that already bound them. Teams that bring together different occupations form no more often than chance would predict. Teams therefore form first through proximity, and more rarely through complementary skills. Paying in shares adds a filter of the same kind: availability.
To our knowledge, no study compares technical partners paid in shares with paid developers. This risk therefore rests on reasoning alone, and it comes from the way of paying, not from the people. A partner chosen for what they have already built can be an excellent choice.
Time matters too. Without a salary, nothing obliges the partner to give a set number of hours to the product, except what the shareholders’ agreement says. If they keep a job on the side, your product gets their evenings. And if they drift away, their shares stay with them unless a clause says otherwise: Samuel Hayot presents vesting as the best protection against the “ghost co-founder” who keeps 30% of the equity after disappearing.
What they have built, and kept running. Ask them for a piece of software they put into production, then kept developing over several years. A prototype shows they know how to start a product. Keeping software that people use every day alive takes a different kind of experience.
What the people who worked with them say. Their former colleagues and former clients know how they work when a problem comes up.
A period of working together before any shares. Samuel Hayot advises it: “Before allocating any shares, set up a period of real collaboration.” Y Combinator suggests the same to the founders it matches: a trial project limited in time, with clear expectations and goals. You work together on a real piece of work, for a period agreed in advance. You see whether they keep their word, how they react to a disagreement, and how much time they can really give to the product.
How they decide what gets developed. Ask them how they will choose what to develop first, and what they will do when your first users ask for something other than what was planned. A list of features fixed at the outset is written on the day you know least about how the users of your application will use it.
A written agreement, before day one. “A verbal agreement between co-founders is worth nothing on the day one of them leaves,” writes Samuel Hayot.
The shareholders’ agreement is the contract that governs relations between partners. For a co-founder paid in shares, four points matter.
The vesting schedule. Vesting means the partner acquires their shares gradually, and leaving too early entitles them to nothing. According to Samuel Hayot, the most common arrangement on the French startup market is four years, with a cliff: “an initial period, usually twelve months, during which nothing is acquired”.
In the UK, tax comes into it. HMRC’s manual on employment-related securities states that there is no concept of “founders’ shares” in the legislation: a founder who is a director of the company from the start acquires employment-related securities. The manual also lists the risk of forfeiture, where shares are disposed of for less than their full market value, among the restrictions that make securities “restricted”. Have an adviser check how your vesting scheme is taxed before you sign it. Vesting terms written for French law do not carry over automatically to a UK company.
The leaver clauses, and the price. The agreement distinguishes leaving for a legitimate reason, the good leaver, from leaving for misconduct, the bad leaver. In the first case, the vested shares are kept or bought back at their market value. In the second, they are often bought back at a discount. According to Samuel Hayot, writing about France, “too aggressive a discount may be recharacterised or found disproportionate by a court”.
The time given to the company, and pay. How many hours a week, and from when the partner will be paid: after a funding round, at the first revenue, at a level of income set in advance.
The assignment of rights in the code. It is signed separately, and the next section explains why.
These clauses can be challenged if they are badly drafted: have the agreement drawn up by a lawyer.
In the UK, the author of a work is the first owner of the copyright in it (Copyright, Designs and Patents Act 1988, section 11(1)). The employer is the first owner only where an employee made the work in the course of their employment, and subject to any agreement to the contrary (section 11(2)). A co-founder who works as a shareholder rather than as an employee is generally not covered by that rule, unless they also have an employment contract, so the starting point is that the copyright stays with them. GOV.UK says the same of a person you commission: the first owner is whoever created the work, unless you agree otherwise in writing. An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor (section 90(3)). For the software your partner develops to belong to the company beyond dispute, you therefore need a written assignment, as with a contractor. As with a lone salaried CTO, all the knowledge of the software then rests with your partner.
The agreement settles what happens to the departing partner’s shares. It does not settle what happens to the code. Without a signed assignment, the rights in the software may stay with its author, even after they leave, while your company depends on that software. Have the assignment signed at the start, when everyone sees it as a formality.
Also open the software’s accounts in the company’s name, not the partner’s: the domain name, the hosting provider, and the repository where its source code is kept.
In its FAQ, Y Combinator answers founders who are not technical: “It’s important for the founding team to have the skills to build their product themselves, rather than outsourcing it to someone else. For most businesses, that usually means you need a technical co-founder.”
This advice matters most when your product is first and foremost a technology: a search engine, an analytics tool, software whose technical difficulty is what makes it valuable. There, technical decisions are strategic decisions, and they belong with someone who shares the equity and the risk. In that case, a technical co-founder has a place at your side, and the time spent finding one is time well spent.
When your product first answers a need you know better than anyone, that of your trade or of your customers, the technology serves that need. In our view, you can then have your product built now, with code that belongs to your company, and put it in the hands of your first users. You then choose your technical partner in the light of a product that is already in use, for what they will bring to it.
Shares pay for a partner’s presence over several years. If you can afford to pay for the development of your product, you keep your equity for the partner you choose later, or for your investors. Paying for development today does not stop you from taking on a partner tomorrow.
We make the technical decisions your product calls for, as a technical co-founder would: the technologies, the architecture, how it is tested and put into production. We align them with your goals, and the decisions about your product remain yours.
At DEVEDANOS, we develop your custom software, usable within a month, for a fixed monthly budget, and we adjust it continuously as your business evolves. The budget is built with you, from your figures and your goals: together, we set the amount and the problem your application has to solve. Your application’s users work with it from the first month of development, and how they use it determines the next feature or features.
Our approach is adaptive: it predicts what is predictable, the monthly budget and the development days per month, and does not try to predict what your users will do with a feature before they have it in their hands.
And so that what worked last month still works this month, we apply a zero-regression guarantee: every regression is fixed and covered by an automated test so that it does not come back, at no extra cost.
The source code, infrastructure, deployment pipeline and documentation are your intellectual property once the first monthly invoice is paid. A trial period of up to 15 working days in the first month: no invoice if you do not want the deliverables.
You can terminate the contract in writing at any time, without justification. During the reversibility month, we support your team until they can build, test and deploy without us. If you later take on a CTO as a partner, they find software already in use, with its code, its tests and its documentation. The pipeline keeps protecting every future change, whichever developer makes it.
Among other things, we build marketplaces, business applications and mobile apps.
If you are also weighing up hiring a salaried chief technology officer, see what a CTO costs in France, and when to hire one. If you are thinking instead of having your product built by a freelance developer or an agency, the contract must settle who owns the code, who pays when your needs change, and how to leave. Our guide sets out the questions to ask before signing a quote for the development of your custom tool.
Are you looking for a technical co-founder, or unsure about offering shares? Shall we talk?
How to integrate AI into your business: start from a specific task, know when a rule is enough, choose between an automation tool and custom software, and know the risks.
An Excel file shared between several users, errors, conflicting versions: when the spreadsheet has become an application, and what moving to a business web application changes.
Web application takeover: what to recover before changing software supplier, why tests come before any change, and when a rebuild is needed.